Una delle funzionalità principali di Git è la capacità di creare più versioni del tuo progetto. Spesso vengono utilizzati per fork a breve termine chiamati “feature branch,” che vengono fusi in master. Tuttavia, a volte è necessario avere rami veramente separati, il che rende più difficile mantenerli sincronizzati.
Perché mantenere rami diversi?
Di solito, i rami sono di breve durata e sono destinati a essere riuniti nel ramo di rilascio principale. In alcuni casi, però, è necessario mantenere rami completamente separati. Ad esempio, potresti avere rami destinati a piattaforme o dipendenze diverse, con caratteristiche diverse, o semplicemente rami di rilascio separati che tieni in vita per un po'.
Questo è lo stesso flusso di lavoro con la maggior parte dei fork e dipende dal quantità e gravità delle modifiche, potrebbe essere difficile mantenere la sincronizzazione con l'upstream. Se i tuoi due rami sono in gran parte sincronizzati meno alcuni commit, ti sarà molto più facile gestire i conflitti e mantenere le cose aggiornate.
Nella maggior parte dei casi, tuttavia, dovresti cercare alternative al dover separare i rami, perché può diventare piuttosto noioso, specialmente con i conflitti di unione e tutti i test extra. Ad esempio, se hai due build destinate a piattaforme diverse, molti linguaggi hanno una configurazione di build e preprocessori in grado di gestirlo. C# ha #if NETVERSION, che consente modifiche al codice in base alla piattaforma per cui sta compilando.
Qualunque sia la tua ragione, questo è un flusso di lavoro Git valido che molte persone usano.< /p>
Mantenere i rami sincronizzati con il ribasamento
Ci sono fondamentalmente due opzioni su come farlo. Il primo e più comune metodo è il ribasamento, che è molto simile alla fusione, ma consente ai rami di essere completamente indipendenti.
Pubblicità
Puoi pensare ai commit Git come a una catena di modifiche che vanno indietro nel tempo, ognuna delle quali punta al commit precedente. Quando crei un nuovo ramo, questo si stacca dal ramo principale principale in un punto specifico, la base del ramo.
Il ribasamento consiste sostanzialmente nel sollevare l'intero ramo delle funzionalità e spostarlo in un nuovo punto nel tempo, in cui la sua fine punta a una diversa catena di commit. Questo è molto utile se il ramo biforcuto contiene solo pochi commit, perché i conflitti di unione saranno più facili da risolvere. In questo esempio, il ribasamento di questo ramo incorpora i commit B e C, ma non D ed E, poiché non deve essere ribasato sull'HEAD del ramo.
Il ribasamento è tuttavia comunemente usato solo per le filiali locali e presenta alcuni problemi se utilizzato con le filiali condivise. I commit in realtà non si spostano; vengono copiati, risultando in nuovi ID commit, con l'HEAD del ramo spostato nella nuova posizione.
Ciò significa che i vecchi commit vengono lasciati bloccati. Poiché Git è un sistema di controllo della versione decentralizzato, i tuoi colleghi potrebbero avere commit non inviati che fanno riferimento a quei commit eliminati. Il ribasamento dovrà essere qualcosa che coordini con tutti i collaboratori e, se qualcuno ha qualche conflitto, dovrà risolverlo localmente copiando le modifiche nella posizione corretta.
Ribasare un ramo è abbastanza facile. Dovrai controllare il ramo delle funzionalità, estrarre tutte le modifiche dal telecomando e quindi eseguire rebase <branch> per spostare il ramo di funzionalità sul ramo di destinazione.
git checkout feature git pull git rebase master Pubblicità
Ciò risulterà probabilmente in conflitti di unione, che dovrai risolvere tu stesso e quindi confermare le modifiche.
Mentre la maggior parte delle attività Git quotidiane possono essere eseguite abbastanza facilmente dalla riga di comando, il ribasamento è per natura un'operazione piuttosto visiva, quindi ti consigliamo di utilizzare un client Git GUI come Fork o GitKraken, se puoi. Questo ti mostrerà le diramazioni e ti aiuterà a pianificare il rebase in modo più efficace e può persino eseguire rebase interattive.
Poiché il rebasing applica fondamentalmente ogni commit dal ramo di funzionalità a una nuova posizione, non è necessario includerli tutti e il rebasing interattivo può eliminare i commit che non si utilizzano ;non ho bisogno. È possibile farlo dalla riga di comando, ma ha più senso da una GUI.
Correzione dei commit indesiderati
Cosa succede se non vuoi includere alcuni commit quando esegui il rebase? Se hai commit sul tuo ramo di funzionalità che desideri escludere durante il ribasamento su master, puoi eseguire un rebase interattivo. Ciò eliminerà i commit indesiderati durante il ribasamento, rimuovendoli essenzialmente dalla cronologia.
Ma è molto più probabile che ci siano commit sul bramo principale che preferiresti non avere nel tuo ramo di funzionalità. Poiché il rebasing imposta la base del nuovo ramo su master, non c'è modo di non includere quei commit.
Se ci sono solo uno o due commit che ti piacciono per non averlo, probabilmente puoi comunque eseguire il rebase e risolverlo nel conflitto di unione, risolverlo manualmente o semplicemente ripristinare il commit. Git ha un “revert” comando che applicherà le modifiche opposte, essenzialmente invertendo un commit e rendendolo come se non fosse mai accaduto. Per usarlo, esegui git log per trovare il commit che desideri ripristinare:
Quindi, copia l'hash SHA1 e ripristina il commit:
git revert 62ee517cc7c358eafbbffdebdde1b38dea92aa0f Pubblicità
Questo creerà un “revert commit” nel ramo delle funzioni.
Cherry-Picking si impegna su un altro ramo
L'ultimo scenario in cui potresti imbatterti è se ci sono solo pochi commit dal master che vorresti avere in funzione. Questo è comune se stai mantenendo branch per versioni diverse, perché spesso ci sono hotfix e patch che devono essere applicati a versioni precedenti del software.
Questo è il metodo più fastidioso per sincronizzare le cose però , perché se non stai mantenendo i tuoi rami almeno in qualche modo sincronizzati, c'è un'alta probabilità che il commit che desideri includere possa essere incompatibile con il ramo precedente.
Ma Git ha strumenti per copiare e incollare essenzialmente i commit su un ramo diverso. Questa azione è chiamata cherry-picking, perché stai prelevando un singolo commit dalla cronologia e rimuovendolo. Analogamente al rebasing, il cherry-picking crea nuovi commit copiati, ma di solito Git è abbastanza intelligente da risolverlo, anche se dovessi unire i rami insieme in seguito.
Per scegliere, devi prendere l'ID commit. Se la cronologia del tuo ramo è complicata, puoi eseguire git log con l'opzione –graph per ottenere una rappresentazione visiva della cronologia, sebbene un client GUI sia particolarmente utile per attività come questa.
git log –pretty=format :”%h %s” –graph
Allora assicurati di& #8217;re sul ramo funzionalità ed eseguire cherry-pick con l'ID commit per copiarlo.
git checkout feature git cherry-pick 1da76d3 Pubblicità
Ciò potrebbe causare conflitti, che tu dovrà risolvere.