Git non ha un supporto particolarmente buono per questo. Il problema concettuale è che ogni commit Git rappresenta uno stato di progetto, non una diff. L'unione di due rami significa combinare le differenze tra gli stati del progetto dei due rami. In genere questo è facile perché Git applica modifiche non in conflitto da entrambi i rami. Ma quando aggiungi un commit a un ramo di funzione e poi lo unisci di nuovo, sarà più difficile della prima unione e dovrai potenzialmente risolvere nuovamente molti degli stessi conflitti. Sebbene git-rerere possa essere abilitato localmente per riutilizzare una risoluzione di conflitto di unione registrata da una precedente unione:
Another application of rerere is where you merge a bunch of evolving topic branches together into a testable head occasionally, as the Git project itself often does. If the tests fail, you can rewind the merges and re-do them without the topic branch that made the tests fail without having to re-resolve the conflicts again.
To enable rerere functionality, you simply have to run this config setting:
$ git config --global rerere.enabled true
– Git Book / Pro Git 2nd ed. by Scott Chacon, Ben Straub.
Considerare il motivo per cui sono necessari i rami di funzionalità e ciò che rappresenta il ramo di test. Se il ramo test diventerà qualcosa di simile a un candidato alla release, ci sarà un valore limitato nell'applicare ulteriori modifiche ai branch delle feature (e quindi dover unirle di nuovo). Invece, considerare di commutare la modifica come hot fix direttamente sul ramo di test. Se il ramo di prova non è la base per un rilascio, tieni presente che stai testando un sistema diverso da quello che stai rilasciando, soprattutto perché i conflitti di fusione potrebbero essere risolti in modo diverso.
Puoi anche selezionare o rebase la correzione dal ramo della funzione al ramo del test, o viceversa. Questo duplica le modifiche nel commit in cima ad un'altra cronologia. Potrebbero esserci conflitti, ma in genere più limitati di una fusione completa.
Né l'unione né la ridenominazione possono aggiornare automaticamente un commit di unione. È in linea di principio possibile modificare il commit di unione o lo schiacciamento di due commit di unione, ma questo è relativamente difficile da fare. L'approccio più semplice sarebbe quello di raggiungere prima e commettere lo stato del progetto che si desidera avere dopo l'unione, quindi registrare una nuova cronologia che produce questo stato: reimpostare il ramo di test prima di tale unione, avviare un'unione di polpo di tutti i rami ma --no-commit l'unione, quindi usa git-checkout per ripristinare l'albero di lavoro allo stato del progetto che desideri e commetti il risultato come unione.
Il modo migliore per evitare conflitti di fusione in Git è evitare rami di lunga durata. Capisco che questo non è sempre possibile, ma l'integrazione delle funzionalità in anticipo (e possibilmente la protezione con i pulsanti di selezione delle funzionalità) causerà la risoluzione e la risoluzione dei conflitti in anticipo, e solo una volta. Allo stesso modo, un'architettura in cui è possibile aggiungere nuove funzionalità senza modificare un sacco di codice esistente eviterà conflitti. In breve: lo spostamento della complessità dal modello di ramificazione al codice stesso.