In un mondo ideale, i conflitti non si verificano mai. Ci sono alcuni scenari in cui i conflitti di fusione sono più comuni ... Quindi il mio consiglio per te sarebbe evitare questi scenari. Ed eccoli qui.

Preoccupazioni strettamente accoppiate

Supponiamo che tu abbia un tecnico front-end e un tecnico back-end. E tu incontri dei conflitti. Questo di solito è dovuto al fatto che il tuo codice non è strutturato in modo tale che le due parti possano evolversi senza interrompersi a vicenda, come ad esempio il mix di accesso al database con il template. Si aggira questo introducendo solo abbastanza astrazione per aggiungere la distanza tra le due preoccupazioni.

Modifiche API e sviluppo simultaneo delle funzionalità

Diciamo che sto aggiungendo una piccola funzionalità al mio prodotto, ed è ortogonale alle interiora. Sarà un punto di rilascio. Nel frattempo, l'architetto capofila sta rifacendo il coraggio del prodotto per portarlo da 1.0 a 2.0. Mi aspetto da 1.0 a 1.1 per l'uscita della mia funzione.

Qui, l'architetto toccherà molta superficie. E se non hai un altro livello di astrazione tra la tua funzione e l'API raw, ti imbatterai in un conflitto molto disordinato.

A volte nelle grandi organizzazioni questo non può essere aiutato.

Refactoring eccessivamente aggressivo

Questo è in realtà lo stesso delle modifiche API. Anche se non ci sono cambiamenti funzionali, ci sono molte modifiche testuali e, dal punto di vista di Git, è lo stesso.

Remedies

• Mantenere le modifiche fisicamente piccole. Piccole differenze, piccole quantità di righe modificate
• Rilasciare per padroneggiare frequentemente
• Integrazione frequente del master
• Comunicare le modifiche dirompenti (come le modifiche API / i grandi refactoring)
• Separare le preoccupazioni aziendali tra i limiti "fisici" (moduli / file / repos)

Se hai bisogno di questo tipo di funzionalità, git non fa per te. È progettato fondamentalmente per consentire un funzionamento indipendente e disconnesso. Scegli un altro VCS adatto alle tue esigenze.

Per quanto riguarda la riduzione al minimo dei conflitti di fusione, ciò può essere fatto comunicando ciò su cui stai lavorando, oltre a una buona architettura del codice. Se segui i buoni principi di progettazione, puoi ridurre al minimo l'ampiezza dei cambiamenti, riducendo al minimo la possibilità di un conflitto, sebbene non sia possibile eliminare del tutto i conflitti.

Inoltre, non so se hai mai lavorato su un grande team che ha utilizzato un VCS di blocco. C'è una ragione che quasi nessuno li usa più, tranne i formati di file binari. Dici che staresti bene aspettando che un file sia sbloccato, ma la maggior parte delle persone non la pensa così. Ciò che finisce per accadere è che le persone apportano modifiche localmente in ogni caso, mentre stanno aspettando, e le uniscono manualmente fuori dal controllo della versione una volta che il file viene sbloccato. È un sistema molto incline agli errori ed è molto difficile convincere le persone a non farlo.

In altre parole, le fusioni avvengono indipendentemente dal fatto che il VCS ti aiuti o meno con loro. Meglio accettarlo e utilizzare un VCS che lo renda più semplice.

Git è progettato per migliorare il processo di unione e non lo rimuove. Se scopri che la fusione è eccessivamente dolorosa, ti suggerisco di perfezionare il tuo processo.

Vorrei anche dare un'occhiata a questa domanda ...

link

Ottima risposta di Mark Canlas. Ecco come pianifichiamo la nostra stessa strategia nel nostro ambiente:

Accetta spesso e spinge spesso

Una delle strategie che usiamo nel nostro ufficio è di impegnarsi spesso e spingere spesso. Se commetto e spingo sul server spesso, il ragazzo che fa grandi cambiamenti dovrà eseguire l'unione, non io. Questo incoraggia efficacemente i membri del team a mantenere le loro modifiche semplici in modo che le fusioni non siano troppo complicate.

Avere il server CI per verificare le modifiche

Abbiamo anche un server CI per verificare i commit, che eseguono anche test unitari aggiuntivi per la creazione della soluzione, quindi chi rompe la build dovrà ripararlo. Il momento peggiore per rompere la build è prima di lasciare l'ufficio, poiché la nostra politica è quella di non lasciare la struttura rotta durante la notte. Il rischio di avere una struttura distrutta venerdì pomeriggio è sufficiente per gli sviluppatori che cercano di mantenere piccole le modifiche.

Chiedi al server CI di inviare email su build danneggiate

Il nostro server CI invia un'e-mail di notifica quando si interrompe una build o quando una build rotta è stata riparata. Questa email viene inviata al proprietario del commit, nonché all'amministratore del progetto. Le nostre build rotte sono state risolte rapidamente grazie a questo.