Creare un ramo ed eseguire il merge delle modifiche
Quando si lavora con il codice Bicep, è in genere necessario eseguire più operazioni alla volta. Ecco ad esempio due scenari per l'uso del sito Web dell'azienda di giocattoli:
- Il team di sviluppo del sito Web vuole aiuto per l'aggiornamento dei file Bicep con modifiche significative. Tuttavia, il team non vuole ancora che queste modifiche vengano pubblicate online. È necessario avere la possibilità di apportare modifiche secondarie alla versione live corrente del sito Web in parallelo con il lavoro sulla nuova versione.
- Si sperimenta con le modifiche che si ritiene miglioreranno le prestazioni del sito Web. Queste modifiche sono tuttavia preliminari. Non dovranno essere applicate alla versione live del sito Web fino a quando non si è pronti.
In questa unità si apprenderà che cosa sono i rami di Git.
Nota
I comandi riportati in questa unità vengono illustrati per spiegare i concetti. Non eseguire ancora i comandi. Presto sarà possibile provare quanto appreso.
Che cosa sono i rami?
Un ramo consente di avere più copie attive dei file alla volta. È possibile creare i rami e passare da uno all'altro in qualsiasi momento. Una volta completato un ramo, è possibile eseguirne il merge in un altro ramo. In alternativa, è possibile eliminarlo, rimuovendo tutte le modifiche.
L'uso dei rami è comune per tutto il lavoro. Spesso si designa un ramo come primario, che rappresenta la versione valida o live dei file. Per convenzione, questo ramo è in genere denominato main, ovvero principale. È possibile creare qualsiasi numero di altri rami. Quando le modifiche in un ramo sono pronte, ne viene eseguito il merge nel ramo main.
Creare ed eseguire il checkout di un ramo
La creazione di un ramo è un'operazione semplice e immediata in Git. Esistono vari modi per eseguirla, ma quello più semplice consiste in genere nell'usare il comando git checkout. Ecco un esempio di come creare un nuovo ramo denominato my-experimental-changes:
git checkout -b my-experimental-changes
Questo comando esegue effettivamente due operazioni: crea il ramo my-experimental-changes e ne esegue il checkout. Per checkout si intende che la copia dei file visualizzati nella cartella rispecchierà il contenuto del ramo. Se sono disponibili due rami con set di modifiche diversi, eseguendo il checkout di un ramo e quindi dell'altro sarà possibile passare da un set di modifiche all'altro.
È possibile passare a un ramo esistente anche usando il comando git checkout. In questo esempio si esegue il checkout del ramo main:
git checkout main
Nota
In genere è necessario eseguire il commit delle modifiche prima del checkout di un ramo diverso. Git avvisa se non è possibile eseguire il checkout.
Lavorare con un ramo
Dopo il passaggio a un ramo, eseguire il commit dei file come di consueto. In realtà, tutte le operazioni eseguite fino a questo momento sono state fatte in un ramo. Si è lavorato nel ramo main, ovvero quello predefinito quando si crea un nuovo repository.
Quando si esegue il commit di alcune modifiche durante il checkout di un ramo, il commit viene associato al ramo. Quando si passa a un ramo diverso, è probabile che il commit non verrà visualizzato nella cronologia di git log finché non viene eseguito il merge del ramo.
Eseguire il merge dei rami
I rami rappresentano un'ottima scelta per separare il lavoro incorso dalla versione live corrente del codice Bicep. Ma, dopo aver completato le modifiche ai file in un ramo, spesso è necessario eseguirne il merge nel ramo main.
Quando si lavora con un unico ramo, è possibile eseguire il merge delle modifiche di un altro ramo in quello corrente usando il comando git merge.
Nota
Assicurarsi di eseguire il checkout del cosiddetto ramo di destinazione del merge prima di eseguire effettivamente il merge. Tenere presente che il merge viene eseguito da un altro ramo al ramo di lavoro corrente.
Ecco un esempio che mostra come eseguire il checkout del ramo main e quindi eseguire il merge delle modifiche dal ramo my-experimental-changes al ramo main. Infine, eliminare il ramo my-experimental-changes perché non è più necessario.
git checkout main
git merge my-experimental-changes
git branch -d my-experimental-changes
Suggerimento
Quando si collabora con altre persone, in genere si usano richieste pull per eseguire il merge delle modifiche invece che direttamente dei rami. Gli argomenti relativi a collaborazione e richieste pull verranno trattati tra poco.
Conflitti di merge
Quando Git esegue il merge delle modifiche di un ramo in un altro, esamina i file modificati e prova a eseguire il merge delle modifiche. In alcuni casi, si potrebbero aver apportato modifiche alle stesse righe di codice in due rami diversi. In queste situazioni, Git non può determinare qual è la versione corretta del codice, quindi crea invece un conflitto di merge.
In questo modulo i conflitti di merge non vengono illustrati in modo approfondito, ma è importante sapere che i conflitti di merge possono verificarsi. E sono più comuni quando si collabora con altre persone. Nel riepilogo di questo modulo è disponibile un collegamento ad altre informazioni sul modo in cui Git e Visual Studio Code consentono di risolvere i conflitti di merge.
Flussi di lavoro di Git
In questo modulo si apprendono solo le nozioni di base dei rami. Tuttavia, i rami offrono molte possibilità e maggior flessibilità nel modo in cui si lavora. È ad esempio possibile creare rami da altri rami ed eseguire il merge di un ramo con qualsiasi altro. È possibile usare i rami per creare tutti i tipi di flussi di lavoro diversi che supportano vari modi di lavorare.
In questo modulo viene usato un flusso di lavoro semplice, lo sviluppo basato su trunk. In questo flusso di lavoro è presente un singolo ramo trunk. Ad esempio, si usa quello principale negli esempi di questo articolo. Tale ramo rappresenta la versione valida del codice. Quando si apportano modifiche o si esegue qualsiasi operazione, si creano rami da questo trunk.
Per lo sviluppo basato su trunk è sconsigliabile apportare modifiche direttamente nel ramo trunk. Provare a mantenere altri rami solo per un breve periodo di tempo, in modo da ridurre al minimo i conflitti di merge. Quindi eseguire il merge ed eliminare questi rami mentre si completano parti del lavoro.
Sono presenti altri flussi di lavoro comuni negli ambienti dei team in cui può essere necessario controllare la frequenza di rilascio delle modifiche. Nel riepilogo di questo modulo sono disponibili collegamenti ad altre informazioni sui flussi di lavoro Git.