Negli articoli precedenti abbiamo visto come sia possibile creare più versioni del nostro codice per poter effettuare dei test o per poter collaborare al prodotto che stiamo realizzando.
Una volta però che abbiamo effettuato le nostre modifiche avremo bisogno di poterle integrare nel ramo originale e poterle così poi applicare al nostro codice. Questa operazione è chiamata merge (trad. unione).
Git ha ovviamente un comando dedicato a questa operazione: git merge.
A---B---C branch_con_modifiche
/
---D---E---F---G master
Come si utilizza quindi il comando merge per poter unire i due rami? Ammesso di essere all’interno della branch principale (master), è possibile eseguire il seguente comando:
git merge branch_con_modifiche
Git si occuperà di unificare i due rami, unendo le modifiche al nostro codice originale. Se tutto è andato come si deve la situazione che otterremo sarà la seguente:
A---B---C branch_con_modifiche / \ ---D---E---F---G---H master
Ovvero Git avrà creato sulla branch master un nuovo commit con all’interno le nostre modifiche.
Tutto questo ovviamente se il processo di unione è andato a buon fine. Ovvero? Qualora le due branch che andiamo ad unire avesseo delle modifiche all’interno che coinvolgono porzioni comune di codice, il merge non andrà a buon fine e il sistema vi avviserà che c’è un conflitto da risolvere.
here is some content not affected by the conflict <<<<<<< master this is conflicted text from master ======= this is conflicted text from feature branch
Generalmente il codice prima del marker ======= è relativo alla branch che sta ricevendo le modifiche, nel nostro caso master.
Una volta che avrete risolto tutti i conflitti, è sufficiente eseguire un normale git commit per poter completare l’operazione.
Il caso coperto da questo esempio è chiamato anche fast forward merge: è il caso più comune e si verifica quando una branch contiene del codice più recente rispetto alla branch che vogliamo integrare. Un esempio tipico di questo flusso di lavoro è quando viene staccata una branch per aggiungere una funzione al codice: quando la nuova funzionalità sarà pronta, la branch verrà unita al codice principale.
Se durante lo sviluppo della vostra nuova funzione sulla branch secondaria, doveste intervenire sul codice principale, durante l’operazione di merge Git eseguirà quello che viene definito “3-way merge”: dal vostro punto di vista il risultato finale non cambierà, ma Git effettuerà alcune operazioni ulteriori “sotto il cofano” per poter integrare tutte le modifiche. Va da se che qualora fosse necessario un merge di tipo 3-way, è più probabile che il codice oggetto del merge generi conflitti.
Questa serie di articoli non può ovviamente essere esaustiva di tutto il mondo di Git né tantomeno del versioning. Vi lascio quindi di seguito alcuni riferimenti dove potrete approfondire gli argomenti visti in questi giorni:
Documentazione ufficiale Git (https://git-scm.com/docs)
Tutorial di Atlassian Bitbucket (https://it.atlassian.com/git/tutorials/learn-git-with-bitbucket-cloud)
Stay Tuned!
