Perché l'unione delle bolle nella cronologia git non è effettivamente così brutta?

Prima di tutto, come hai già sottolineato, richiedono meno lavoro. Secondo me, l'onere è sul processo che richiede più lavoro, in questo caso il processo di rebase, per dimostrare la sua utilità superiore.

L'argomento più importante è che le fusioni mantengono una cronologia accurata, poiché lo sviluppo è effettivamente avvenuto. Una storia lineare e consolidata è utile a un livello più alto di astrazione, come i team di qualità e di rilascio. È piuttosto il contrario di un team di sviluppo, in cui è estremamente utile sapere esattamente quando e come è stato introdotto un bug. È successo a causa di un'unione, o è stato il bug durante lo sviluppo e l'ho mancato? Se la cronologia viene distrutta, non hai modo di rispondere a domande del genere.

L'altro motivo è che incoraggia la cooperazione fluida in altre categorie oltre a quelle a stella. Nel controllo della versione centralizzata, l'unico modo per condividere il tuo lavoro è quello di commetterlo sul server centrale. Con distribuito, potresti avere due persone che lavorano insieme per un giorno o due, tirando l'una dall'altra, quindi spingono al server centrale quando è pronto per il gruppo più grande. È un modo molto efficiente e naturale di voler lavorare.

Se gli sviluppatori devono preoccuparsi del fatto che se x commit rebased contiene le stesse modifiche di y commit che hanno tirato da qualcun altro durante lo sviluppo attivo, ciò crea un carico cognitivo che scoraggia quella modalità di cooperazione. L'unione unisce gli sforzi di tracciamento verso il software di controllo della versione, motivo per cui ce l'abbiamo.

Se una risposta soddisfacente esiste per questa domanda è discutibile poiché le bolle di fusione sono desiderabili per una serie di motivi.

C'è meno manutenzione a lungo termine richiesta quando si mantiene lineare la cronologia in git, in più rende molto più facile vedere cosa sta facendo qualcuno piuttosto che tentare di attraversare una storia folta e complessa. Dall'esperienza con una grande organizzazione e un gran numero di sviluppatori, c'è un tasso molto più alto di problemi / bug introdotti a causa di unioni non corrette rispetto a rebase.

Onestamente, non c'è molto sovraccarico per mantenere lineare la cronologia per evitare l'unione delle bolle. È davvero così difficile aggiungere un'opzione --rebase a Git Pull? O impostare il comportamento di rebase come comportamento di pull predefinito nella configurazione?

Inoltre, i seguenti vantaggi si realizzano quando si utilizza rebase invece di unire per evitare l'unione delle bolle:

1. Gli sviluppatori devono solo preoccuparsi dei commit che spingono quando usano rebase e non tutta la complessità e i commit non necessari che hanno aggiunto alla cronologia con le unioni. Ciò semplifica notevolmente anche il processo di revisione del codice.
2. L'analisi della cronologia delle modifiche è notevolmente semplificata con meno tempo e sforzi necessari.
3. L'annullamento delle modifiche è un processo diretto quando la cronologia viene mantenuta lineare attraverso il rebase. Con l'unione delle bolle nella cronologia, il ripristino può essere più impegnativo di quanto valga.

In generale, le migliori pratiche relative a quando utilizzare rebase vs merge possono essere descritte con i seguenti due casi d'uso:

1. Rebase dovrebbe essere usato per il tipico lavoro di sviluppo dei singoli contributori poiché non ha quasi nessun sovraccarico rispetto a un'unione.
2. Unisci deve essere utilizzato da qualcuno in un ramo o rilasciare la capacità di gestione per unire le modifiche tra progetto, organizzazioni e / o team.

Come disclaimer rapido, con team di sviluppo più piccoli queste considerazioni non entrano in gioco troppo spesso, ma dovrebbero comunque essere seguite come best practice. Tuttavia, con le grandi organizzazioni, i vantaggi dell'utilizzo di rebase per mantenere lineare la cronologia superano di gran lunga una nozione mal concepita che l'unione abbia un sovraccarico minore rispetto a rebase.

Il motivo per cui le bolle sono considerate negative in primo luogo è che rovinano il registro cronologico. Quando è solo una bolla per segmento non è poi così male - ma quando una squadra numerosa usa unire tutto il tempo il grafico della storia inizia ad apparire come uno di questi labirinti follow-the-line .

Se la tua squadra ha deciso che le bolle di fusione non sono così male, rispetto a:

1. Sono disposti ad accettare il grafico della cronologia disordinato
2. Sono disposti ad usare flag come --first-parent per renderlo lineare
3. La squadra non è abbastanza grande per poter sfuggire di mano (non probabile)
4. Qualsiasi altro motivo che ti consente di rispettare i grafici della cronologia disordinata