Quando ho iniziato a sviluppare, non conoscevo ancora git.
Poi, con l’università, ho iniziato a usarlo, prima con altri, ma senza capire bene come funzionasse, poi da solo, per progetti personali.
Questo perché mi ha salvato la vita nelle innumerevoli volte in cui mi trovavo a modificare codice senza sapere quale fosse la versione che veramente funzionava, ma questo potrebbe essere un altra storia.
Quando poi ho preso a lavorare, ho iniziato ad approfondire e ha usare qualche strategia di branch, iniziando a vedere i problemi…
Più passaggi, meno flow
E qui, che soprattutto per progetti in cui ci lavori da solo, mi sono trovato con questo giro per ogni feature o fix:
– Apri il branch
– Pubblicalo
– Crea la merge request
– Aggiungi i commit
– Vai online a approvarla e mergiarla
– Ritorna sul codice in locale, cambia il branch, scarica il codice nuovo e rinizia
Questa serie di passaggi mi interrompevano.
Se per la prima parte, quella di aprire, pubblicare e creare la merge request ero riuscito a fare tutto in un singolo passaggio ( un bel altro articolo su anche il makefile ), c’erano comunque molti passaggi che rimanevano lì che interrompevano il flusso.
Quindi, quando potevo, ritornavo a committare tutto sul branch di sviluppo.
Questa idea comunque era avvalorata anche da un mio collega, che, facendomi conoscere il libro Accelerate, mi ha fatto comprendere come è meglio preferire o piccolissime merge request o addirittura non averle.
E come faccio a raggruppare i commit?
Questa era la domanda che mi interessava al me del futuro.
Perché, se poi ogni commit rimane li senza una referenza, mi sarei perso e non avrei capito bene come era collegate le cose.
Mentre indagavo, nel mio caso gitlab, è spuntato questo articolo: gitlab tutorial its all connected.
Qui è stato il flash: Issue + crosslinking nel commit.
In questo modo posso permettermi di raggruppare una serie di commit e capire che cosa ho fatto.
Ovviamente questo va a pari passo con l’utilizzo delle feature flag ( di cui ho già scritto di come le stai usando senza accorgertene qui: Feature flag: le stai già usando senza accorgerti ).
Svantaggi
Uno svantaggio, ma credo che si potrà trovare uno strumento che sopperisca, è vedere le differenze raggruppate come una merge request
Conclusione
Questo approccio non è sempre ottimale, ma per un progetto pagato e con un team di persone in cui tutti hanno la ownership del progetto, è molto più efficace, evitando problemi di merge request quando questi hanno tempi troppo lunghi e potendo tenere un flow continuo si quello che si sta facendo e rispetto a quello che gli altri, in parallelo, hanno sviluppato.