Git pull con rebase che causa conflitti eccessivi. Come posso sistemare il nostro flusso di lavoro?

Question

Abbiamo un sistema di base personalizzato per ogni cliente. La base vive nel proprio repository e ogni client vive nel proprio repository (originariamente clonato dalla base).

L'obiettivo è avere la possibilità di aggiungere correzioni di bug/funzionalità alla base, che possono essere propagate ai client, su richiesta.

Finora il flusso di lavoro è stata la seguente:

• Marchio impegna/argomento rami per le correzioni di base/caratteristiche: (sulla base, master) git commit -m "Fix admin typo"
• Unire le modifiche al client: (su client, master) git merge base/master. Ovviamente, ciò include la risoluzione di eventuali conflitti tra le personalizzazioni di base e del client.
• Spingere l'unione all'origine del cliente: (su client, master) git push origin master
• La nostra convenzione è stata quella di tirare con rebase (per mantenere leggibile la cronologia). Così, poi uno sviluppatore diverso lavoro cliente avrebbe (il cliente, padrone) git pull --rebase origin master

E 'a questo punto che si raggiunge notevoli problemi con quel tiro/rebase. Gli sviluppatori ottengono conflitti nel pull/rebase fatto dopo un'unione dalla base nel client. E non sono solo alcuni conflitti, sono molti (per molti dei quali vengono ripetuti?), E spesso codificano quel particolare sviluppatore che non ha mai nemmeno toccato. Penso che questo sia irragionevole e insostenibile.

Qual è la soluzione migliore qui?

Il mio unico pensiero è quello di smettere di usare rebase quando si tratta e di gestire registri sciatti e difficili da leggere, ma preferirei non doverlo fare. Questi progetti client possono durare per anni, e mi piacerebbe essere in grado di dare ancora un senso al sistema di base che si fonde in futuro.

Answer 1

Fatemi capire bene sulle tue pronti contro termine:

1. il progetto principale è separata, chiamati base
2. ogni progetto cliente viene clonato da base, aggiornamenti solo tirando
3. gli sviluppatori lavorano da parte del pubblico client_foo repo, e push/pull a/da detto

Il flusso di lavoro non riesce essere causa che un dev sta ridefinendo il ramo client_foo sul nuovo commit dal repository base e reindirizzandolo a client_foo. Questo finirà per rompere tutti gli altri sviluppatori usando client_foo quando provano a fare il loro prossimo tiro. Quindi non puoi farlo e aspettati che git lo gestisca automaticamente.

Se si trattasse solo di uno sviluppo per repository client, allora forse avrebbe funzionato. Suppongo che non sia il caso.

Opzioni:

1. continuare a fare ciò che il vostro facendo, ma quando il dev spinge il client_foo ramo ricalcolato (con i nuovi base commit) di nuovo al pubblico client_foo pronti contro termine, tutti gli altri hanno a che fare un reset --hard su origin/master. Se mantengono tutte le loro modifiche impreviste in un ramo di argomenti privato, devono restituire il numero rebase al nuovo client_foo/master.

2. Le modifiche merge dev da base a client_foo. Questo ti darà un merge commit su client_foo che hai detto che stai cercando di evitare, ma ti darà la cronologia più accurata. Quando i tuoi sviluppatori fanno un 'pull --rebase', non dovresti più ricevere la lunga lista di conflitti che hai ora.

3. Le modifiche cherrypick da base a client_foo. Ciò mantiene la cronologia lineare, ma git non traccerà più il fatto che i commit di cherrypick sono stati ottenuti da base. Dovrai trovare un altro modo per seguirlo.

Direi bastone con # 2 poiché è il modo in cui git dovrebbe funzionare. Tuttavia, qualcun altro potrebbe pensare a una soluzione non ovvia migliore.