Una milestone raggruppa le issue sotto un obiettivo con scadenza (es. “v1.0 — consegna 15 aprile”) e mostra una barra di progresso. È orientata al “per quando”. Un GitHub Project è una board visuale che mostra lo stato di avanzamento di tutte le attività (To Do, In Progress, Done). È orientato al “dove sta ogni cosa adesso”. Si completano: la milestone dice “queste 8 issue devono essere completate entro il 15 aprile”, il Project mostra su quali delle 8 qualcuno sta lavorando in questo momento. Un’issue può avere sia una milestone che essere in un Project.

Un tag è un’etichetta permanente che punta a un commit specifico — una volta creato, non si sposta mai. Un branch è un puntatore che si sposta in avanti ogni volta che fai un nuovo commit. Il tag è come un segnalibro fisso (“questo è il commit della v1.0”), il branch è come un cursore che avanza (“qui è dove sto lavorando”). I tag si usano per marcare le versioni rilasciate, i branch per il lavoro in corso. Entrambi sono puntatori a commit, ma il tag è immutabile e il branch è mobile.

In Semantic Versioning (MAJOR.MINOR.PATCH): 2 è la versione major (ci sono state 2 modifiche incompatibili con le versioni precedenti), 4 è la versione minor (4 aggiunte di funzionalità compatibili dalla major 2), 1 è la patch (1 bugfix dalla minor 4). Quando incrementi MAJOR, azzeri MINOR e PATCH (2.0.0 → 3.0.0). Quando incrementi MINOR, azzeri PATCH (2.4.1 → 2.5.0). PATCH si incrementa solo per bugfix (2.4.1 → 2.4.2).

Perché i tag non vengono pushati automaticamente con git push. Il push normale invia solo i commit e i branch, non i tag. Devi pushare esplicitamente il tag: git push origin v1.0.0 (un tag specifico) o git push origin --tags (tutti i tag). È una delle differenze tra tag e branch: i branch vengono pushati quando fai push del branch, i tag richiedono un push separato. Questo è intenzionale: evita di pushare tag accidentali o temporanei.

Una release è una pagina pubblica su GitHub collegata a un tag. Il tag da solo è un puntatore a un commit — è tecnico e minimale. La release aggiunge: un titolo leggibile, release notes (cosa c’è di nuovo, bug risolti, contributori), file scaricabili allegati (binari, documentazione), e archivi automatici del codice sorgente (.zip e .tar.gz). È il modo professionale di distribuire una versione: il prof o un utente può andare sulla pagina della release, leggere cosa c’è di nuovo e scaricare il codice in un click.

Genera automaticamente le release notes dalla lista delle Pull Request integrate dal tag precedente a quello corrente. Ogni PR diventa un punto nella lista, con il titolo, il numero e l’autore. Se hai usato le PR in modo disciplinato (un titolo chiaro per ogni feature o fix), le note auto-generate sono già un ottimo punto di partenza. Puoi poi modificarle: aggiungere sezioni (Nuove funzionalità, Bug risolti, Contributori), rimuovere PR non rilevanti, o aggiungere contesto. È il modo più veloce per avere release notes complete senza scriverle da zero.