GitHub Flow: il ciclo di lavoro
Il GitHub Flow è il flusso di lavoro branch-based che la documentazione ufficiale descrive come sequenza minima per proporre una modifica e farla arrivare nel codice condiviso. Non è un prodotto da attivare né una impostazione del repository: è la convenzione che tiene insieme branch, commit, pull request, review e merge. Conoscerne l’ordine è il modo più rapido per rispondere alle domande che non chiedono “che cos’è un branch” ma “qual è il passo successivo”.
I passi del flusso, in ordine
La sequenza documentata da GitHub è composta da sei passi.
- Create a branch: si crea un branch nel repository. Un nome breve e descrittivo permette ai collaboratori di capire a colpo d’occhio su che cosa si sta lavorando.
- Make changes: sul branch si modificano i file e si registra il lavoro con uno o più commit. Ogni commit ha un messaggio descrittivo, che serve a chi legge la cronologia mesi dopo.
- Create a pull request: si apre una pull request per chiedere ai collaboratori un parere sulle modifiche. Se il lavoro non è finito ma serve un riscontro anticipato, la pull request può essere aperta come draft.
- Address review comments: i revisori lasciano commenti; si continua a fare commit e push sul branch e la pull request si aggiorna automaticamente, senza doverla riaprire.
- Merge your pull request: una volta approvata, il merge porta le modifiche del branch sul default branch.
- Delete your branch: eliminare il branch dopo il merge segnala che quel lavoro è concluso e tiene pulito l’elenco dei branch.
Il punto centrale è il quinto: le modifiche compaiono sul default branch soltanto dopo il merge. Finché si lavora sul proprio branch, il ramo principale resta quello che era, quindi stabile e distribuibile. È per questo che non si lavora direttamente sul default branch. In molte organizzazioni la scelta non è nemmeno lasciata all’educazione della persona: il ramo principale è un protected branch con l’impostazione “Require a pull request before merging”, e un push diretto viene semplicemente rifiutato.
La pull request come luogo di discussione
Una pull request propone il merge delle modifiche di un branch dentro un altro, chiamato base branch. Non è un pulsante: è una pagina di lavoro con schede distinte. In Conversation stanno descrizione, commenti, review e la cronologia delle attività; in Commits si vede come il branch si è evoluto; in Checks compaiono i risultati di test, build e altre verifiche automatiche; in Files changed si legge il diff che i revisori annotano riga per riga. Il merge box in fondo dichiara se la pull request può essere unita o che cosa manca ancora, per esempio le review o i check richiesti.
La review ha tre esiti espliciti: Comment lascia un parere generale senza approvare né chiedere modifiche, Approve approva il merge, Request changes invia un riscontro che va risolto prima di procedere. Quando il repository richiede le approvazioni, “Request changes” diventa vincolante: la pull request non si unisce finché lo stesso revisore non approva. Al momento del merge si sceglie fra Merge pull request, Squash and merge e Rebase and merge, tre modi diversi di scrivere la cronologia risultante.
Quando non hai accesso in scrittura: il fork
Il flusso descritto presuppone di poter creare un branch nel repository, quindi di avere almeno il permesso di scrittura. Chi non lo ha, tipicamente chi contribuisce a un progetto open source altrui, usa un fork: una copia del repository di cui si è proprietari, collegata all’originale, che prende il nome di upstream repository. Fork e upstream condividono la storia, e proprio per questo possono scambiarsi modifiche tramite pull request.
La differenza da tenere ferma è questa: un branch vive dentro un singolo repository, un fork è un repository separato con impostazioni, permessi e spazio di collaborazione propri. Il ciclo non cambia: si crea comunque un branch nel fork, si fanno i commit, si apre la pull request scegliendo come base il repository upstream, e sono i suoi maintainer a decidere se la modifica va accolta.
Che cosa verifica l’esame su questo punto
L’obiettivo ufficiale chiede di spiegare il GitHub Flow per la collaborazione, quindi aspettati domande sull’ordine dei passi e sul ruolo di ciascuno. Le confusioni tipiche sono due. La prima è scambiare fork e branch: se hai accesso in scrittura la risposta corretta è quasi sempre il branch, il fork serve quando l’accesso non c’è. La seconda è pensare che il merge sia un’operazione locale da spingere sul ramo principale: nel GitHub Flow la modifica entra nel default branch attraverso la pull request, che è insieme la proposta, la discussione e il punto di controllo.