Perché così tanti progetti preferiscono "git rebase" piuttosto che "git merge"?

Uno dei vantaggi dell'utilizzo di un DVCS è il flusso di lavoro edit-commit-merge (rispetto a edit-merge-commit spesso imposto da un CVCS). Consentire la registrazione di ogni modifica unica nel repository indipendentemente dalle fusioni garantisce che il DAG rifletta accuratamente il vero pedigree del progetto.

Perché così tanti siti web parlano del voler "evitare impegni di fusione"? La fusione tra pre-commit o rebasing post-merge non rende più difficile isolare le regressioni, ripristinare le modifiche passate, ecc.?

Punto di chiarimento: il comportamento predefinito per un DVCS è quello di creare commit di unione. Perché così tanti luoghi parlano del desiderio di vedere una storia di sviluppo lineare che nasconde questi impegni di fusione?

Le persone vogliono evitare i commit di unione perché rendono il log più bello. Sul serio. Sembra che i registri centralizzati con cui sono cresciuti e localmente possano fare tutto il loro sviluppo in un singolo ramo. Oltre a questi aspetti estetici, non ci sono vantaggi e diversi inconvenienti oltre a quelli che hai citato, come renderli inclini al conflitto ad attirare direttamente da un collega senza passare attraverso il server "centrale".

In due parole: git bisect

Una cronologia lineare consente di individuare l'origine effettiva di un bug.

def bar(arg=None):
    pass

def foo():
    bar()

La filiale 1 esegue alcuni refactoring in modo che argnon siano più validi:

def bar():
    pass

def foo():
    bar()

Branch 2 ha una nuova funzionalità che deve usare arg:

def bar(arg=None):
    pass

def foo():
    bar(arg=1)

Non ci saranno conflitti di unione, tuttavia è stato introdotto un bug. Fortunatamente, questo particolare verrà catturato dal passaggio della compilation, ma non siamo sempre così fortunati. Se il bug si manifesta come comportamento imprevisto, piuttosto che un errore di compilazione, potremmo non trovarlo per una settimana o due. A quel punto, git bisectin soccorso!

Oh merda. Questo è ciò che vede:

(master: green)
|             \_________________________
|                \                      \
(master: green)  (branch 1: green)     (branch 2: green)
|                 |                     |
|                 |                     |
(master/merge commit: green)            |
|                         ______________/
|                        /
(master/merge commit: red)
|
...days pass...
|
(master: red)

Quindi, quando spediamo git bisectper trovare il commit che ha interrotto la build, individuerà un commit di unione. Bene, questo aiuta un po ', ma essenzialmente indica un pacchetto di commit, non uno solo. Tutti gli antenati sono verdi. D'altra parte, con il rebasing, ottieni una cronologia lineare:

(master: green)
|
(master: green)
|
(all branch 1 commits: green)
|
(some branch 2 commits: green)
|
(branch 2 commit: red)
|
(remaining branch 2 commits: red)
|
...days pass...
|
(master: still red)

Ora, git bisectindicherà l'esatto commit di funzionalità che ha interrotto la build. Idealmente, il messaggio di commit spiegherà cosa è stato progettato abbastanza bene per fare un altro refactor e correggere immediatamente il bug.

L'effetto è aggravato solo in grandi progetti quando i manutentori non hanno scritto tutto il codice, quindi non ricordano necessariamente perché è stato eseguito un determinato commit / a cosa serviva ogni ramo. Quindi individuare il commit esatto (e quindi essere in grado di esaminare i commit attorno ad esso) è di grande aiuto.

Detto questo, (attualmente) preferisco ancora fondermi. Il rifacimento su un ramo di rilascio ti fornirà la cronologia lineare da utilizzare con git bisect, pur mantenendo la cronologia reale per il lavoro quotidiano.

In breve, perché la fusione è spesso un altro posto in cui qualcosa può andare storto, e deve solo andare storto una volta per rendere le persone molto spaventate di affrontarlo di nuovo (una volta morso due volte timido, se vuoi).

Supponiamo quindi che stiamo lavorando su una nuova schermata di gestione dell'account e si scopre che c'è un bug scoperto nel flusso di lavoro del nuovo account. OK, prendiamo due percorsi separati: finisci la gestione dell'account e correggo il bug con i nuovi account. Dato che entrambi abbiamo a che fare con gli account, abbiamo lavorato con un codice molto simile, forse abbiamo dovuto persino modificare gli stessi pezzi di codice.

Ora, in questo momento abbiamo due versioni diverse ma perfettamente funzionanti del software. Entrambi abbiamo eseguito un commit sulle nostre modifiche, entrambi abbiamo testato diligentemente il nostro codice e indipendentemente siamo molto fiduciosi di aver fatto un ottimo lavoro. E adesso?

Bene, è tempo di fondersi, ma ... merda, cosa succede adesso? Potremmo benissimo passare da due set di software funzionanti a uno, unificato, orribilmente rotto di software di nuova generazione in cui la gestione dell'account non funziona e i nuovi account sono rotti e non so nemmeno se il vecchio bug è ancora lì .

Forse il software era intelligente e diceva che c'era un conflitto e ha insistito perché gli dessimo una guida. Beh, merda - mi siedo per farlo e vedo che hai aggiunto un codice complesso che non capisco immediatamente. Penso che sia in conflitto con le modifiche che ho apportato ... te lo chiedo, e quando ricevi un minuto controlli e vedi il mio codice che non capisci. Uno o entrambi dobbiamo prenderci il tempo per sederci, fare una fusione corretta e possibilmente ripetere il test dell'intera cosa del pericolo per assicurarci di non averlo rotto.

Nel frattempo altri 8 ragazzi stanno tutti commettendo codice come i sadici, ho fatto alcune piccole correzioni di bug e le ho inviate prima di sapere che abbiamo avuto un conflitto di unione, e l'uomo sembra sicuramente un buon momento per fare una pausa, e forse tu sono fuori per il pomeriggio o bloccati in una riunione o altro. Forse dovrei solo andare in vacanza. O cambia carriera.

E così, per sfuggire a questo incubo, alcune persone hanno avuto molta paura dell'impegno (cos'altro c'è di nuovo, prima?). Ovviamente siamo avversi al rischio in scenari come questo - a meno che non pensiamo di fare schifo e comunque lo rovineremo, nel qual caso le persone iniziano a recitare con abbandono spericolato. sospiro

Quindi eccoti. Sì, i sistemi moderni sono progettati per alleviare questo dolore, e dovrebbe essere in grado di retrocedere e rifare facilmente, debase e freebase e hanglide e tutto il resto.

Ma è tutto più lavoro e vogliamo solo premere il pulsante sul microonde e fare un pasto di 4 portate prima di avere il tempo di trovare una forchetta, e tutto sembra così insoddisfacente: il codice è lavoro, è produttivo, è significativo, ma gestire con grazia una fusione non conta.

I programmatori, di regola, devono sviluppare una grande memoria di lavoro, e quindi hanno la tendenza a dimenticare immediatamente tutti quei nomi spazzatura e variabili e scoping non appena hanno finito il problema e gestiscono un conflitto di unione (o peggio, un unione erroneamente gestita) è un invito a ricordare la tua mortalità.

Il rifacimento fornisce un punto di diramazione mobile che semplifica il processo di invio delle modifiche alla linea di base. Ciò consente di trattare un ramo con esecuzione prolungata come se si trattasse di una modifica locale. Senza la rifasatura, i rami accumulano le modifiche dalla linea di base che verranno incluse nelle modifiche che vengono ricondotte alla linea di base.

La fusione lascia la linea di base nel punto di diramazione originale. Se unisci alcune settimane di modifiche dalla linea da cui sei stato ramificato, ora hai molte modifiche dal tuo punto di diramazione, molte delle quali saranno nella tua linea di base. Ciò rende difficile identificare le modifiche nella tua filiale. La restituzione delle modifiche alla linea di base può generare conflitti non correlati alle modifiche. In caso di conflitti, è possibile spingere cambiamenti incoerenti. Le fusioni continue richiedono sforzi per la gestione ed è relativamente facile perdere i cambiamenti.

Rebase sposta il punto di diramazione sull'ultima revisione sulla baseline. Qualsiasi conflitto che incontrerai sarà solo per le tue modifiche. Spingere le modifiche è molto più semplice. I conflitti vengono risolti nella filiale locale effettuando un rebase aggiuntivo. In caso di push contrastanti, l'ultimo a spingere la modifica dovrà risolvere il problema con la modifica.

Gli strumenti automatizzati stanno migliorando per assicurarsi che il codice di fusione verrà compilato ed eseguito, evitando conflitti sintattici , ma non possono garantire l'assenza di conflitti logici che possono essere introdotti dalle fusioni. Quindi una fusione "riuscita" ti dà un senso di falsa fiducia, quando in realtà non garantisce nulla e devi ripetere tutti i test.

Il vero problema con le ramificazioni e le fusioni, secondo me, è che calcia il proverbiale barattolo lungo la strada. Ti permette di dire "Lavorerò nel mio piccolo mondo" per una settimana, e affronterà qualsiasi problema si presenti in seguito. Ma correggere i bug è sempre più veloce / economico quando sono freschi. Quando tutti i rami del codice iniziano a fondersi, potresti già dimenticare alcune delle sfumature delle cose che sono state fatte.

Prendi i due problemi sopra menzionati e potresti trovarti in una situazione in cui è più semplice e più facile far lavorare tutti dallo stesso tronco e risolvere continuamente i conflitti mentre si presentano, anche se rendono lo sviluppo attivo un po 'più lento.

Un altro punto rilevante è questo: con il rebasing posso facilmente selezionare o ripristinare una funzione nel mio ramo di rilascio.

Tre cose non sono state dette in nessuna delle risposte:

• Diffondere all'interno di un ramo:

  • La differenza tra una coppia arbitraria di commit in un ramo diventa estremamente difficile quando ci sono commit di unione.

• Unione di un elemento alla volta:

  • Quando si risolve la differenza tra due rami, in genere si verifica un'unione in una sola volta e tutti i conflitti di unione che si lasciano fare senza contesto di quale specifico commit era responsabile del conflitto. Se si ribatte, il rebase si fermerà nel punto in cui si è verificato il conflitto e ti consentirà di risolverlo in quel contesto.

• Pulizia prima della spinta:

  • Se hai commesso un errore che devi correggere in seguito, se non hai spinto il rebase interattivo ti consentirà di combinare / dividere / cambiare / spostare i commit. Mentre puoi ancora farlo se ti sei unito, diventa molto difficile se vuoi combinare / dividere / cambiare / spostare attraverso un confine di unione.