I conflitti di unione complicati frequenti sono un segno di problemi?

Non è impossibile che il problema sia il tuo codice. Se la tua base di codice ha un sacco di interrelazioni tra i moduli, allora ogni cambiamento avrà viticci ovunque, e ogni dev che interagisce con il codice di qualcun altro, sarà un incubo.

Tenderei a pensare che prima lo noteresti in altri modi, ma è possibile che tu sia così abituato a non vederlo più.

Sono abituato al flusso di lavoro "fetch-rebase-push". Quale è in realtà il primo, più primitivo, flusso di lavoro, che è descritto nel tuo tutorial. Ecco i vantaggi:

• Vera integrazione continua
• Gestione precoce dei conflitti - subito dopo aver scritto e testato il codice
• Risposta rapida - "-Hey, Bob, l'interpolazione cubica che hai scritto sta dando un risultato divertente, potresti guardarlo mentre sono a pranzo?"
• Nessuna unione si impegna - pulire la timeline come se uno sviluppatore scrivesse everithyng

Ora, riguardo a complicati conflitti di fusione. Non capisco come si possano sperimentare entrambe le frequenti fusioni e complicate. La complicazione deriva dal non ribaltare / cherry-picking per un lungo periodo, lavorando su quella caratteristica solitaria per un mese.

Personalmente preferirei affrontare conflitti di fusione frequenti, facili (in realtà rebase), piuttosto che rari e onnicomprensivi merge horror.

Le unioni e le rebase dovrebbero causare gli stessi identici conflitti, per quei conflitti inerenti che un umano deve risolvere (cioè due sviluppatori che cambiano la stessa linea di codice). Per altri conflitti, le fusioni tendono in realtà ad essere più pulite, perché non stai cambiando lo SHA-1 di commit ovunque. Non sono sicuro di come tu riesca a entrare in uno stato in cui le unioni causano più conflitti che rebases, ma è certamente un segnale che il flusso di lavoro di alcune persone è incasinato, e probabilmente hanno bisogno di più formazione su come funziona git. Stanno rimuovendo il commit di altre persone quando eseguono i loro rebases locali, o qualcosa del genere?

Il vantaggio e l'inconveniente del metodo pull-rebase è che è molto simile ai flussi di lavoro centralizzati a cui sono abituate molte persone. Non devi capire la ramificazione per poterla usare.

In ogni caso, è perfettamente fattibile eseguire un flusso di lavoro di una feature branch solo localmente, se non riesci a far firmare ad altre persone.

Il progetto a cui sto lavorando presenta questo tipo di problemi di tanto in tanto e sembra derivare da un paio di fattori:

• Usiamo Visual Studio e file come Visual Studio .sln sono solo documenti XML (che non rispondono bene alle fusioni testuali) pieni di Guids (che Git non riesce a capire meglio di tutti noi) e può facilmente essere unito male e causare la perdita di file.
• Alcune persone stanno lavorando su aree simili del codice, in modo che le modifiche ottenute possano essere proprio l'una accanto all'altra nelle classi. Anche se inevitabile in questa situazione, questo tipo di configurazione sarà molto difficile per qualsiasi sistema di controllo del codice sorgente. Anche se hai una buona comunicazione nella tua squadra, a volte le persone non si renderanno conto che stanno entrando nel reciproco codice e che sorgono conflitti.

Sono interessato al potenziale per Semantic Merge per aiutare con alcuni di questi problemi, ma ovviamente è solo un qualche uso se stai lavorando in un linguaggio che è in grado di analizzare e non ho ancora incontrato alcuna sfida significativa quando lo sto utilizzando, quindi non posso garantire la sua efficacia.

A meno che gli sviluppatori non stiano modificando i commit storici (anziché le unioni pure), i conflitti in un modello di git del flusso di lavoro di una caratteristica sono un segno di una base di codice strettamente accoppiata (/ brandnew codebase) o di una sovrapposizione di funzioni.

Hai un ramo principale (principale) e tutti lavorano nei loro rami di funzionalità.

I lavori nei rami delle funzionalità possono richiedere da poche ore a pochi mesi.

Ogni tanto qualcuno rovescia la fusione del suo changeset nel ramo principale. Il responsabile della tua squadra deve assicurarsi che solo una persona faccia una fusione inversa alla volta. Una volta eseguita questa operazione, è necessario inoltrare la fusione dal ramo principale al ramo delle funzionalità. Una volta che tutti si uniscono in avanti, a un'altra persona può essere consentito di invertire l'unione nel ramo principale. Altrimenti troppe modifiche verranno invertite e si verificheranno tonnellate di conflitti di unione durante l'unione in avanti.

Giusto per chiarire la terminologia, con "reverse merge" intendo la fusione da feature branch al ramo principale, e con "forward merge" intendo l'unione dal ramo principale al branch di funzionalità. In base a ciò che ho sperimentato in precedenza, è probabile che vedrai più conflitti di unione in caso di unione inversa, anziché unione in avanti.

Due cose che possono aiutare: uno, evitare qualsiasi strumento che apporti modifiche da solo. Due sviluppatori che utilizzano impostazioni di tabulazione diverse sono una ricetta per il disastro. Due, apportare modifiche in luoghi diversi. Si ottiene un problema, ad esempio se tre sviluppatori aggiungono codice alla fine dello stesso file - molto meglio se aggiungono codice in luoghi diversi.