Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Git

Migliorare il Workflow di Gruppo Con Git

by
Difficulty:BeginnerLength:ShortLanguages:
Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

Italian (Italiano) translation by Mirko U. Garozzo (you can also view the original English article)

Nonostante sia uno strumento molto utile per lavorare singolarmente, é quando si tratta di lavorare in un team che Git da il meglio di se.

Il punto chiave per avere un robusto workflow in Git sta nella comunicazione. Essendo uno strumento molto flessibile, Git puó accomodare differenti approcci ed usi. Stabilendo un piano di lavoro a priori dall’inizio di un progetto, verrá arginata confusione tra I membri del gruppo. A questo punto possiamo sfruttare Git per migliorare performance e produtitivitá.

Questo tutorial provvede un workflow in un gruppo che usa Git e dove il lavoro viene analizzato da differenti membri del gruppo. Questo tutorial é basato su un workflow creato da Vincent Driessen chiamato Git-Flow, anche se differisce per alcune parti. Sul web son disponibili svariati esempi di workflow, e suggerisco di leggerne il maggior numero possibile cosi ché il vosto gruppo possa adottare quello che si presta meglio al vostro scopo.

Ma andiamo avanti con la spiegazione del nostro workflow!.

Il primo comandamento

Il branch master é sempre deployable (“schierabile”)

Un deployable branch master é importante per diversi motivi. Innanzitutto permette a qualunque membro del team che si unisca a progetto iniziato di poter effettuare Git pull (“aggiorna”) e avere una versione locale aggiornata del progetto e senza nessun problema. Nulla risulta cosi frustante come non essere in grado di ricreare l'ambiente di lavoro di un progetto con cui non si é familiari.

Inoltre master mostra a che punto é la nostra fase di produzione e/o il progetto live. Quando un membro del team deve effettuare una modifica, é sempre chiaro a tutti quale sia il branch di partenza.

Possiamo considerare avere master sempre deployable come un’ancora di salvezza. Tenendo master deployable, possiamo risparmiare preoccupazioni. Le preoccupazioni causano stress, e lo stress causa errori. Fare il possibile per evitarlo é una base fondamentale per qualsiasi progetto.

Strategie di branching

Il branch chiamato develop dovrebbe essere il branch di sviluppo principale del nostro progetto. Qualsiasi altro branch verrá creato e incorporato (“merge”) con develop, che rappresenta la massima espressione del nostro codice (n.b. inteso come una versione aggiornata e priva di bug del nostro codice).

Visto che entrambi i branch master e develop sono permanenti e vengono sempre usati, non si dovrebbe mai lavorare direttamente in questi branch. Tutto il lavoro dovrebbe essere fatto in altri branch, ed ogni volta che si deve creare un nuovo modulo o parte di un progetto un branch parallelo deve essere creato partendo da master. Tutto il lavoro verrá effettuato su questo branch parallelo.

Che nome assegnare ad un branch?

Non esiste nessuna regola da seguire alla lettera riguardo nomi da assegnare ad un branch, specialmente per “feature” branches (branches che esistono generalmente solo nelle repo dei developer, non in origin). Di solito viene incoraggiato a lasciare nomi del tipo “release X.X.X” Come regola generale un branch deve avere un nome che sia descrittivo. E perché no divertente o contenere un gioco di parole!

Tu dici Merge, Io ti rispondo Rebase

Non appena la nuova funzionalitá del progetto é finita, é tempo di ricongiungersi con uno dei branch condivisi (per questo esempio useremo develop). Prima di effettuare l'operazione di merge, assicurati che il branch in cui si stia lavorando sia aggiornato con la versione piú recente di develop, altrimenti potrebbe verificarsi un conflict (un'errore che si genera in Git quando esistono due versioni in conflitto tra loro).

Tutte le risoluzioni ad eventuali conflitti creatisi devono essere effettuate nel tuo feature branch. Se hai creato un feature branch per apportare piccole modifiche ad un progetto e non hai ancora inviato (“push”) il branch a remote, effettua un rebase di develop dentro il tuo feature branch, e poi effettua un merge del tuo feature branch con develop. Invia ad origin e poi elimina il tuo feature branch se hai effettuato tutti I cambiamenti e il branch non dovesse servirti piú.

In caso avessi gia inviato il tuo branch a remote, prima effettua un merge di develop dentro il tuo branch (per risolvere I conflitti) e dopo fai merge del tuo branch dentro develop. Invia ad origin e poi elimina il tuo branch se non dovesse servirti. Una cosa importante da tenere sempre in mente: rebasing é un azione che puó essere pericolosa, quindi bisogna stare molto attenti! Per quanto sia molto utile nel ripulire la cronologia dei commit, non vuoi interferire nel lavoro che hanno fatto altri colleghi in passato.

Queste sono delle regole generali per stare al sicuro quando effettuiamo un rebase:

  • Mai effettuare un rebase di qualcosa che sia stato inviato a remote. Bisogna effettuare un rebase solo quando il branch é esclusivamente locale.
  • In caso dovessi effettuare un rebase di un branch condiviso (es. develop) fallo nel tuo branch locale. Devi assicurarti che quando effetui il rebase tutti I cambi che siano stati effettuati in develop siano stati ricongiunti (merge) col tuo branch locale.

Condividi con I tuoi colleghi

Abbiamo creato un branch, abbiamo lavorato sodo sul nostro codice, abbiamo merged/rebased develop ed adesso siamo pronti per ricongiungere il nostro branch con develop. Ma prima qualcuno dovrebbe rivedere il nostro codice. Condividere il tuo lavoro con I colleghi non solo ti permette di avere una onesta valutazione del lavoro che hai fatto, ma é sopratutto un opportunitá per individuare eventuali errori che ti fossero sfuggiti.

Questo é il momento in cui possiamo sfruttare Git pull requests e l'interfaccia grafica di Bitbucket (se avessi bisogno di rivedere come aprire e controllare le pull requests su Bitbucket leggi  Using Pull Requests as Code Reviews). Una pull request puó essere utile a molte cose oltre che a mostrare ad altri il nostro lavoro prima di effettuare un push. Puo essere utile ad avere un tema di discussione e collaborare sullo stesso progetto, aggiungere foto, commentare direttamente sulle linee di codice e perfino aggiungere GIF e emojis per ridere un pó.

La persona ad effettuare un merge dopo una pull request dovrebbe essere la stessa persona che ha aperto la pull request, visto che probabilmente sará la stessa persona ad aver scritto la nuova parte di codice. In questo caso chiunque abbia riesaminato il codice dovrebbe lasciare un commento per comunicare che é stato approvato ma non effettuare un merge. Quando un collega da il via, la persona ad aprire la pull request puó finire il lavoro effettuando un merge.

Rilasciare il branch

Quando il branch develop é pronto per essere rilasciato, fai un merge con master:

Hai notato il –no-ff? Questo comando permette di non avere merge come fast-forward (andare avanti velocemente) quindi creerá un nuovo commit. La ragione per questo? Per creare una tag ovviamente! Crea una tag per questo commit come una nuova versione:

Dopo puoi fare merge di master dentro develop, cosi che develop sia aggiornato con l'ultimo commit.

Riguardo I nomi delle versioni, dovremmo usare semantic versioning. In questo modo il nome della versione sará sempre MAGGIORE.MINORE.PATCH . Come regola generale MAGGIORE é un numero che viene usato per grossi cambi. Puó essere usato per interrompere qualsiasi compatibilitá con una versione precedente. Minore é un numero che viene usato per nuovi cambi, di solito minori. Non deve interrompere nesusna compatibilitá.

Correggere gli errori come un ninja

Non dovremmo mai inviare parti di codice che contengano bugs o errori, ma quando succede bisogna rimediare all'errore il prima possibile. Siccome develop potrebbe avere alcune parti non finite del progetto, il nostro hotfix deve essere un branch creato da master (master é sempre deployable ricordi?!).

Per creare un hotfix, crea un branch da master, correggi l'errore e poi fai un non-fast-forward merge con master. Assegna la tag, e poi ri-effettua merge di master con develop (vogliamo che anche develop contenga la versione corretta). Poi puoi tranquillamente eliminare il branch creato.

É tempo di eseguire un GIT commit!

Riguardo il messaggio da abbinare al comando GIT commit: se tutti usano le stesse regole, il nostro workflow sará molto piú fluido. Ecco alcune dritte:

  • Usa l'imperativo invece del passato per un messagio di GIT commit.
  • La prima linea dovrebbe essere un piccolo messaggio che riassuma il commit (preferibilmente non piú di 50 caratteri) con la prima lettera in maiuscolo.
  • Se dovessi aver bisogno di aggiunger maggiori informazioni,fallo lasciando uno spazio vuoto. Queste informazioni dovrebbero essere un nuovo paragrafo.

Se vuoi saperne di piú riguardo a come scrivere un Git commit message, dai un occhiata a questo articolo di Tim Pope.

Trova la tua strada

Voglio ricordarti che il workflow descritto sopra é solo una guida, non regole da seguire alla lettera. Se ti piacciono e funzionano col tuo team seguile, altrimenti cerca di migliorarle o passa ad altro.

La cosa piú importante é che il tuo team abbia un workflow ben definito e chiaro a tutti. A quel punto potrai beneficiare di tutti I lati positivi che GIT offre quando si lavora in team.

Puoi vedere altre alternative al workflow su Atlassian's Git workflows guide.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.