Avanzamento rapido VS nessuna unione di avanzamento rapido

Git merge ci consente di eseguire l'unione rapida dei rami senza avanzamento veloce. Qualche idea su quando utilizzare l'unione di avanzamento rapido e quando non utilizzare l'unione di avanzamento rapido?

L' --no-ffopzione è utile quando si desidera avere un'idea chiara del ramo delle funzionalità. Quindi, anche se nel frattempo non sono stati effettuati commit, FF è possibile - a volte vuoi comunque che ogni commit nella linea principale corrisponda a una caratteristica. Quindi trattate un ramo di caratteristiche con un sacco di commit come una singola unità e le unite come una singola unità. È chiaro dalla tua cronologia quando si unisce l'unione delle funzioni--no-ff .

Se non ti importa di questa cosa, probabilmente potresti cavartela con FF ogni volta che è possibile. In questo modo avrai una sensazione di flusso di lavoro più simile a svn.

Ad esempio, l'autore di questo articolo pensa che l' --no-ffopzione dovrebbe essere predefinita e il suo ragionamento è vicino a quello che ho descritto sopra:

Considera la situazione in cui una serie di commit minori sul ramo "feature" compongono collettivamente una nuova funzionalità: se fai semplicemente "git merge feature_branch" senza --no-ff", è impossibile vedere dalla cronologia di Git quali degli oggetti commit insieme hanno implementato una funzione — dovresti leggere manualmente tutti i messaggi di log. Il ripristino di un'intera funzione (cioè un gruppo di commit), è un vero mal di testa [se --no-ffnon viene usato], mentre è facile se il --no-ffflag è stato usato [perché è solo un commit] ".

Posso fare un esempio comunemente visto nel progetto.

Qui, l'opzione --no-ff(vale a dire true merge ) crea un nuovo commit con più genitori e fornisce un migliore monitoraggio della cronologia. Altrimenti, --ff(vale a dire unione di avanzamento rapido ) è l'impostazione predefinita.

$ git checkout master
$ git checkout -b newFeature
$ ...
$ git commit -m 'work from day 1'
$ ...
$ git commit -m 'work from day 2'
$ ...
$ git commit -m 'finish the feature'
$ git checkout master
$ git merge --no-ff newFeature -m 'add new feature'
$ git log
// something like below
commit 'add new feature'         // => commit created at merge with proper message
commit 'finish the feature'
commit 'work from day 2'
commit 'work from day 1'
$ gitk                           // => see details with graph

$ git checkout -b anotherFeature        // => create a new branch (*)
$ ...
$ git commit -m 'work from day 3'
$ ...
$ git commit -m 'work from day 4'
$ ...
$ git commit -m 'finish another feature'
$ git checkout master
$ git merge anotherFeature       // --ff is by default, message will be ignored
$ git log
// something like below
commit 'work from day 4'
commit 'work from day 3'
commit 'add new feature'
commit 'finish the feature'
commit ...
$ gitk                           // => see details with graph

(*) Nota che qui se il newFeatureramo viene riutilizzato, invece di creare un nuovo ramo, git dovrà --no-ffcomunque fare una fusione. Ciò significa che l'unione rapida in avanti non è sempre idonea.

Quando lavoriamo sull'ambiente di sviluppo e uniamo il nostro codice al ramo di staging / produzione, Git non può essere un'opzione migliore per avanzare rapidamente. Di solito, quando lavoriamo nel ramo di sviluppo per una singola funzione, tendiamo ad avere più commit. Tracciare le modifiche con più commit può essere scomodo in seguito. Se ci uniamo con il ramo di staging / produzione usando Git senza avanzamento rapido, avrà solo 1 commit. Ora, ogni volta che vogliamo ripristinare la funzione, ripristina semplicemente il commit. La vita è facile.

È anche possibile che si desideri avere rami di funzionalità personalizzati in cui il codice viene inserito alla fine della giornata. Ciò consente di seguire lo sviluppo in modo più dettagliato.

Non vorrei inquinare lo sviluppo principale con codice non funzionante, quindi fare --no-ff potrebbe essere proprio quello che si sta cercando.

Come nota a margine, potrebbe non essere necessario eseguire il commit del codice funzionante su un ramo personalizzato, poiché la cronologia può essere riscritta git rebase -ie forzata sul server purché nessun altro lavori su quello stesso ramo.