strategia git sulla funzione di unione / ribobinazione che è stata abbandonata ma viene ripresa

Question

strategia git sulla funzione di unione / ribobinazione che è stata abbandonata ma viene ripresa

#1 da (2 voti)

0

Diciamo che abbiamo questa situazione:

* master
| 
* a
| 
* b
      ... a lot has happened
*
      ... a lot has happened
* z
|
|  * aa (want to rebase onto master or merge into master but having too many conflicts)
|  |
|  * bb
....
|  |
|  * yy
|  |
|  * zz
| / 
* parent

parent in master ha eseguito un completo refactoring del codice parent a aa ha eseguito un completo refactoring del codice, ma un diverso refactoring

Ho bisogno di unire aa in master . O rebase aa su master , per riportare aa in azienda.

Ho provato a fare entrambe le cose, ed entrambe sembrano dolorose. Ho circa 13 correzioni di rebase da fare se utilizzo la route rebase. e mentre passo passo dopo passo, qualcosa si rompe a causa del diverso refactoring fatto su entrambi i rami. Quindi, in un certo senso, refregolatore e modifica le cose quando eseguo il rebase.

Quando faccio l'unione, almeno so che cosa devo correggere subito, poiché tutti i conflitti vengono visualizzati immediatamente. Tranne che la funzione aa è stata eseguita tanto tempo fa, non riesco facilmente a comprendere tutti i conflitti. Potrei dire che rebase, almeno, me lo dà passo dopo passo.

Ma entrambi sembrano abbastanza difficili e so che git ha un'ottima reputazione quando si tratta di fusioni. Quindi forse sto lottando per nulla? C'è un modo migliore?

Il mio obiettivo è riportare parent a aa percorso nel mio master.

git workflows

posta Dennis 10.02.2015 - 00:53

fonte

1 risposta

Leggi altre domande sui tag git workflows

Esistono schemi di serializzazione per OOP che includono metodi o operazioni nel contratto oltre alla struttura dei dati? Assicurarsi che la configurazione di caricamento (non predefinita) sia valida

score 2 · Accepted Answer

Mentre git è bello, la fusione / ridefinizione di un ramo di funzionalità non aggiornato sarà sempre un'esperienza dolorosa. Non esiste un proiettile magico (di cui sono a conoscenza) che farà andare via questo mal di testa.

Nella mia esperienza, preferisco la ridefinizione della fusione in queste situazioni per i motivi che hai menzionato: puoi risolvere gli errori in ogni commit uno alla volta e assicurarti che tutto si sviluppi e che i test passino prima di passare al commit successivo .

In rebases estremamente difficili, ho in realtà reimplementato la funzione usando come riferimento le differenze di commit dal branch di funzionalità. Per quanto possa sembrare folle, può essere molto più rapido aggiungere rapidamente alcune classi e test all'attuale base di codice piuttosto che risolvere i conflitti per una funzionalità progettata per una base di codici molto diversa e non aggiornata.