Git entra in gioco dopo che le funzioni sono state sviluppate e aggiunte a una roadmap di prodotto, e il team di sviluppo è pronto. Ma facciamo un passo indietro per un rapido corso accelerato sullo sviluppo delle funzioni Agile: i team di prodotto, progettazione, controllo di qualità e ingegneria conducono un meeting introduttivo sulle funzioni allo scopo di ottenere una comprensione condivisa di quali saranno le caratteristiche di una funzione (cioè i requisiti), l'ambito del progetto e i task in cui la funzione deve essere suddivisa per essere completata. Questi task, noti anche come storie utente, vengono quindi assegnati ai singoli sviluppatori.

Git inizia a inserirsi nel tuo flusso di lavoro Agile in questo punto. In Atlassian, creiamo un nuovo branch per ogni singolo ticket. Che si tratti di una nuova funzione, di una correzione di bug o di un piccolo miglioramento a un codice esistente, ogni modifica del codice ha il proprio branch.

La creazione di branch è intuitiva e consente ai team di collaborare facilmente all'interno di una base del codice centrale. Quando uno sviluppatore crea un branch, dispone effettivamente di una propria versione isolata della base del codice in cui apportare le modifiche. Per un team Agile questo significa che, suddividendo le funzioni in user story e, successivamente, in branch, il team di sviluppo può gestire i task singolarmente e lavorare in modo più efficiente sullo stesso codice, ma in repository diversi; il lavoro non è mai duplicato e, poiché le persone possono concentrarsi su piccoli elementi di lavoro in repository separati rispetto al repository principale, le dipendenze che rallentano il processo di sviluppo non sono molte.

Una volta che i branch sono considerati completati e pronti per le revisioni del codice, Git svolge un altro ruolo chiave in un flusso di lavoro di sviluppo Agile: i team Agile e DevOps efficaci conducono le revisioni del codice e configurano test automatizzati (continuous integration o continuous delivery). Per facilitare le revisioni e i test del codice, gli sviluppatori possono facilmente informare il resto del team che il lavoro del branch è pronto per la revisione e deve essere rivisto tramite una pull request. Più semplicemente, una pull request rappresenta un modo per chiedere a un altro sviluppatore di eseguire il merge di uno dei tuoi branch nel branch principale e di indicare è pronto per i test.

Con gli strumenti giusti, sul server di continuous integration è possibile creare e testare le richieste pull prima di effettuarne il merge. In questo modo hai la certezza che il merge non causerà problemi e, in generale, diventa più facile ridefinire la destinazione delle correzioni di bug e dei conflitti, perché Git conosce la differenza tra il branch e la base del codice principale dal punto in cui i branch si sono ramificati.

La story Git/Agile riguarda l'efficienza, i test, l'automazione e l'agilità generale. Dopo aver eseguito il merge di un branch al branch principale, il flusso di lavoro Agile è terminato. Allo stesso modo, il merge del codice effettuato tramite pull request significa che quando il codice è completato, hai la documentazione necessaria per sapere con certezza che il tuo lavoro è verde, che altri membri del team hanno approvato il codice e che questo è pronto per il rilascio. Ciò consente ai team Agile di agire in modo veloce e sicuro per effettuare rilasci frequenti: la caratteristica che contraddistingue un team Agile eccellente.