Se scrivi software per vivere nel 2018, posso dire con sicurezza che “conosci Git. lo strumento creato da Linus Torvalds è diventato sinonimo di controllo della versione e, senza dubbio, una delle migliori caratteristiche di Git è il modo in cui elimina il dolore di ramificazioni e fusioni. Esistono diversi modi per creare un ramo in Git. In questo post ne esamineremo alcuni. Quindi concluderemo con una piccola riflessione sul modello di ramificazione di Git e sulla ramificazione in generale.

Creazione di un ramo dal master

Non sorprende che crei rami in Git utilizzando il comando branch. Come molti altri comandi Git, “branch” è molto potente e flessibile. Oltre a creare rami, può anche essere usato per elencarli ed eliminarli e puoi personalizzarli ulteriormente il comando utilizzando un ampio elenco di parametri. Inizieremo con il primo modo per creare un ramo. Supponiamo che tu voglia creare una nuova cartella chiamata “my-app”, inserirla e avviare un nuovo repository Git. È esattamente come lo faresti:

mkdir my-appcd my-appgit init

Ora hai un nuovo repository Git vuoto. Ma i repository vuoti sono noiosi. Che ne dici di creare un nuovo file markdown con scritto “Hello World!”?

echo Hello World! > file.md

Se esegui “git status”, dovresti vedere un messaggio che dice che il tuo file non è tracciato:

Anche i file non tracciati non sono cool, quindi tracciamoli:

git add file.md

Infine, creiamo il nostro primo commit:

git commit -m "First commit"

Ora abbiamo un repository con un ramo, che ha esattamente un commit. Potrebbe non suonare come il la cosa più eccitante del mondo (perché in realtà non lo è), ma è certamente meno noioso che avere un repo senza alcun commit, giusto? Ora, diciamo che per qualsiasi motivo devi cambiare il file “è contenuto. Ma tu no voglia di farlo. E se qualcosa va storto e in qualche modo rovini il contenuto bello e incontaminato del tuo file? (Sì, lo so che è solo uno stupido file con dentro “Hello World!”, Ma usa i meravigliosi poteri della tua immaginazione e pensa al file come un proxy per un progetto molto più complesso.) La soluzione a questo dilemma è, ovviamente, creare un nuovo ramo:

git branch exp

Quindi ora abbiamo un nuovo ramo chiamato “exp”, per la sperimentazione Alcune persone che sono abituate a usare diversi sistemi di controllo delle versioni, specialmente quelli centralizzati, potrebbero dire che i rami hanno lo stesso “contenuto”. Tuttavia, questo non è del tutto accurato quando si parla di Git. Pensa ai rami come riferimenti che puntano a un determinato commit.

Creazione di un ramo da un commit

Supponiamo che, per qualsiasi motivo, rinunciamo al nostro esperimento, senza aggiungere un singolo impegnarsi nel nuovo ramo. Torniamo al master ed eliminiamo il ramo exp:

git checkout mastergit branch -d exp

Ora che siamo tornati a un singolo ramo, aggiungiamo alcuni commit per simulare il lavoro svolto:

Immagina che dopo aver fatto tutto questo “lavoro”, impari che, per qualsiasi motivo, devi tornare indietro nel tempo a quando erano solo due righe nel file e da quel momento in poi creano nuove modifiche. Ma allo stesso tempo, devi preservare i progressi già fatti. In altre parole, vuoi creare un ramo da un commit passato. Come lo faresti ? In Git, ogni commit ha un identificatore univoco. Quindi puoi vederlo facilmente usando il comando “git log”. Per creare un nuovo ramo basato su un commit specifico, passa semplicemente il suo hash come parametro al comando branch:

git branch new-branch 7e4decb

Per inciso, non hai nemmeno bisogno dell’intero hash per la maggior parte del tempo. Solo i primi cinque o sei caratteri lo faranno.

Creazione di un ramo da un tag

Se sei un po ‘più esperto con Git, allora dovresti avere familiarità con il concetto di tag. Utilizzi i tag per indicare che un determinato commit è importante o speciale in qualche modo. Ad esempio, i tag vengono generalmente utilizzati per indicare le versioni effettive di un prodotto. Se hai lavorato nella tua applicazione per un po ‘di tempo e credi che sia ora di rilasciare la versione 1.0, quello che normalmente fai è aumentare i numeri di versione laddove necessario, confermare le modifiche e quindi aggiungere un tag a quel momento specifico. Per creare un tag, di solito “d esegui qualcosa del genere:

git tag -a v1.0 -m "First major version"

Il parametro” -a “indica che sta andando essere un tag annotato. A differenza di un tag leggero, questo è un oggetto Git in piena regola, contenente informazioni come il nome e l’email del committer, il timestamp e un messaggio. Ora hai un tag, un’indicazione che questo particolare punto della storia è speciale e ha un nome. Bello. Puoi continuare a lavorare, come al solito, creando e confermando le modifiche che faranno parte della versione 1.1. Fino a quando non arriva una segnalazione di bug. Alcuni client che sono stati aggiornati a 1.La versione 0 del prodotto dice che una funzione di importazione non funziona come previsto. In teoria potresti correggere il bug nel ramo principale e distribuirlo. Ma poi i client riceverebbero funzionalità che sono potenzialmente non testate e incomplete. Questo “sa no -no. Allora cosa fai? La risposta: crei un nuovo ramo dal tag che hai creato per indicare la versione principale. Risolvi il problema lì, compila e distribuisci. E probabilmente dovresti unirlo di nuovo al master in seguito, in modo che le versioni successive contengano la correzione . Come faresti a farlo? Facile:

git branch <NAME-OF-THE-BRANCH> <TAG>

Più specificamente, utilizzando il nostro esempio precedente:

git branch fix-bug-123 v1.0

Dopodiché, puoi controllare il tuo nuovo ramo come al solito. O meglio ancora, potresti fare tutto in un unico passaggio:

git checkout -b fix-bug-1234 v1.0

Creazione di una filiale in uno stato di testa distaccato

Hai mai desiderato tornare indietro nel tempo? Con Git questo è possibile … almeno per quanto riguarda i file nel nostro repository. Puoi, in qualsiasi momento, controllare un commit se conosci il suo hash:

git checkout <SHA1>

Dopo averlo eseguito, Git ti mostrerà un messaggio curioso:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

Al momento del check out un commit, si entra in uno stato speciale c alled, come puoi vedere, “testa distaccata”. Sebbene sia possibile eseguire il commit delle modifiche in questo stato, tali commit non appartengono a nessun ramo e diventeranno inaccessibili non appena si esegue il check out di un altro ramo. Ma cosa succede se si desidera mantenere quei commit? il comando “checkout” di nuovo per creare un nuovo ramo:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

E ovviamente, ormai sai che puoi scrivere il ultime due righe come un unico comando:

git checkout -b new-branch-to-keep-commits

Abbastanza facile, giusto?

Solo perché puoi … Non significa che dovresti

Il modello di ramificazione di Git è uno dei suoi punti di forza. Trasforma in un gioco da ragazzi quello che in altri sistemi di controllo del codice sorgente è un processo doloroso e persino lento. Si potrebbe dire che Git ha democratizzato con successo le ramificazioni per le masse. Ma esiste un serio pericolo. A causa dell’economicità della ramificazione in Git, alcuni sviluppatori potrebbero cadere nella trappola di lavorare con rami estremamente longevi o di impiegare flussi di lavoro o modelli di ramificazione che ritardano grazione. Noi, come industria, ci siamo stati. L’abbiamo fatto. Non funziona. Scegli invece flussi di lavoro che impiegano rami di durata estremamente breve. Avrai una sandbox sicura in cui codificare senza timore di rompere le cose o far perdere tempo ai tuoi colleghi. Ma questo ti fa chiedere: “Come faccio a distribuire codice con funzionalità parzialmente completate?” In tal caso, sono presenti flag in soccorso. I branch Git sono uno strumento potente. Usali con saggezza e non abusarne. E quando non sono sufficienti, utilizza la fornitura continua / l’integrazione continua insieme ai contrassegni delle funzionalità, inclusi strumenti specializzati a tua disposizione, in modo che le tue applicazioni possano passare al livello successivo.