Risoluzione dei conflitti e ordine di fusione per il codice del progetto?

Ti unisci nell'ordine che rende l'unione il più semplice. Non esiste un'euristica generale per questo perché dipende in gran parte dalle modifiche al codice in questione. Il più delle volte, il tuo "istinto" è abbastanza vicino a quello ottimale. Considera che puoi testare diversi ordini di fusione in locale prima di farlo ufficialmente per il repository centrale.

Inoltre, la fusione diventa molto più difficile più a lungo si va senza farlo. Se le tue modifiche sono troppo infrante per unire in master , dovresti almeno unire frequentemente master in i tuoi rami di refactoring e spesso unire i rami del refactoring l'uno nell'altro. In questo modo, stai risolvendo i conflitti un po 'alla volta anziché tutti alla volta.

L'unione di rami l'uno nell'altro può assumere un paio di forme diverse. Il modo più comune in cui lo faccio è che occasionalmente unisco il ramo di un collega nel mio che so ha dei cambiamenti sovrapposti. Questo ha alcuni potenziali risultati:

• Il codice del mio collega si trova in uno stato di interruzione perché la funzione o il refactor è a metà, quindi esco dall'unione e riprovo più tardi.
• Ci sono conflitti di unione che posso risolvere cambiando il mio codice, quindi lo faccio.
• Ci sono conflitti di fusione che richiedono una conversazione con il mio collega, quindi ne ho uno.

Se il mio collega si fonde prima con master , allora il mio PR escluderà automaticamente le modifiche unite da quel ramo. Se ho bisogno di una richiesta di pull, posso ridigitarli.

L'altro modo di unire rami l'uno con l'altro che probabilmente funzionerebbe meglio nella tua situazione sarebbe creare un ramo temporaneo refactor che possa essere usato per l'integrazione continua delle modifiche del refactoring, quindi effettuare una grande richiesta di pull per unire refactor in master . In questo modo, gli sviluppatori stanno riesaminando piccole richieste di pull contro il ramo refactor .

Lo svantaggio di unire rami l'un l'altro è che tendi a introdurre dipendenze l'uno dall'altro, quindi devi fare attenzione ad evitarlo, o accettarlo e unirli tra loro vicini. Tuttavia, non dover prendere tutte le modifiche tramite il ramo master nel repository centrale è uno dei principali punti di forza di git. Assicurati di non trascurarlo.

Unisci in ordine di completamento. Altrimenti le persone sono in attesa di qualcosa.

Diciamo che hai due rami completi simultaneamente da unire

branch 1 è un piccolo cambiamento, la funzione Add è ora chiamata Addizione e prende un parametro extra (quindi l'ide non può effettuare automaticamente la modifica)

branch 2 è una grande modifica a diverse funzioni di business logic che utilizzano la funzione Aggiungi in più posizioni.

Quindi hai tre compiti.

• Unisci B1
• Unisci B2
• Cambia tutte le funzioni Aggiungi influenzate da B2 ad Addizione e aggiungi il parametro extra

Quale mai l'ordine che scegli prima B1 o B2 hai lo stesso terzo compito. L'unica differenza è come viene presentata l'attività.

Ma anche questa è una scelta sbagliata, diciamo che prima unisci B2 e ti viene presentato lo spostamento di tutto il codice B2 in B1. Potresti ignorare quella presentazione se lo desideri e basta copiare B2 e applicare la modifica del nome ad essa. Il risultato è lo stesso codice.

Quindi hai un ramo principale e hai creato quattro rami e ogni ramo ha eseguito il proprio refactoring. E ogni ramo è a sua volta fine.

Uno dei quattro proprietari di filiali è fortunato e unisce i suoi cambiamenti con il master, senza conflitti. Ovviamente le revisioni dei codici vengono eseguite, i test vengono eseguiti, quindi il ramo principale è di nuovo in buono stato, con un refactoring eseguito.

Gli altri tre rami ora hanno un problema. Non si basano più sul ramo master attuale. Non possono essere uniti senza conflitto. Se noti che il tuo ramo non può essere unito senza conflitti, allora non puoi unire in master e risolvere i problemi mentre vai, è solo un suicidio e impossibile da recensire. Invece, unisci il master nel tuo ramo e prendi la responsabilità di farlo funzionare. Gli altri due rami fanno lo stesso. Uno dei tre è fortunato, e fonde i suoi cambiamenti in master, senza conflitto (perché hanno fuso il master nel loro stesso ramo).

E questo viene ripetuto altre due volte.

Avrai notato che tutto questo è un sacco di lavoro. Questo perché avere più sviluppatori di modificare gli stessi file in modo indipendente è solo una cattiva idea che creerà un incubo di fusione. Il modo migliore è fare un refactoring, unirmi al master, fare un secondo refactoring e così via. O rendi assolutamente chiaro quali file è consentito a ogni sviluppatore di toccare prima che ognuno inizi il suo refactoring e non permetta a due sviluppatori di rifattorizzare gli stessi file.