Lo schiacciamento si impegna in una pratica ottimale (per questo particolare flusso di lavoro)?

Question

ho la git flusso di lavoro seguente:

1. Crea nuovo ramo di caratteristica
2. lavoro sul ramo di caratteristica
3. Commit spesso
4. Una volta funzione è completa, si fondono in master ramo
5. sciacquare e ripetere

Tuttavia, a volte, ho bisogno per ripristinare un'intera funzione dal master. Ciò potrebbe coinvolgere un sacco di revert ing. (Il motivo per cui ho bisogno di annullare una funzionalità è che ho un sito Web che funziona da un repository.In questo punto, utilizziamo uno script che distribuisce il sito sul nostro sito di produzione o sul sito di Staging. Non chiedere, è proprio quello che mi è stato dato per lavorare. A volte, sto lavorando a qualcosa che ho messo in scena, ma poi è necessario apportare un cambiamento immediato, quindi avevo bisogno di un modo per tirare le mie modifiche in ordine per pulire il repository)

Sto pensando che il modo più semplice per farlo è se ogni ramo di funzionalità ha un solo commit. Quindi potrei revert che commette. Quindi, naturalmente, sto pensando di schiacciare tutti i commit di un ramo di funzionalità in uno, prima di unirlo a master.

Così ora il mio flusso di lavoro sarà simile:

1. Crea nuovo ramo di caratteristica
2. lavoro sul ramo di caratteristica
3. Commit spesso
4. Una volta caratteristica è completa git rebase -i HEAD ~ number_of_commits (o se la filiale remota è disponibile, origine/funzione_branco)

C'è qualche problema con questa logica? Va contro le migliori pratiche? Ho fatto alcuni test e l'intero flusso di lavoro sembra funzionare senza intoppi e risolve il mio problema, ma volevo gestire l'idea con altri (più intelligenti) Git-ers per vedere se c'è qualcosa di sbagliato in questo.

Grazie!

Answer 1

Si dovrebbe cercare di sfruttare la capacità di fusione dello squash di git, ad esempio git merge --squash, in modo da non riscrivere la storia inutilmente.

Entrambe git merge --squash e git rebase --interactive possono essere utilizzate per produrre un commit schiacciato con lo stesso albero di lavoro risultante, ma sono intesi per servire 2 scopi completamente diversi.Alla fine il tuo albero finisce per sembrare diverso in entrambi i casi.

albero iniziale:

a -- b -- c -- d master 
     \ 
     \-- e -- f feature1 

Dopo git checkout master; git merge --squash feature1; git commit:

a -- b -- c -- d -- F master 
     \ 
     \-- e -- f feature1 

Dopo git checkout master; git rebase -i feature1 e scegliendo di pick c e squash d:

a -- b   /-- F master 
     \  /
     \-- e -- f feature1 

Come si può vedere dalla differenza, si fa non riscrivere la storia di qualsiasi ramo quando si utilizza git merge --squash ma si finisce per riscrivere la cronologia di master quando si utilizza git rebase -i.

Si noti inoltre che i commit effettivi (per quelli che sono stati schiacciati) sarebbero presenti nella cronologia git in entrambi i casi, solo fino a quando si dispone di un riferimento di ramo o tag attraverso il quale tali commit sono raggiungibili.

In altre parole, nell'esempio di cui sopra, se si elimina feature1 dopo aver fatto merge --squash, non sarebbe in grado di visualizzare in realtà i commit e o f in futuro (soprattutto dopo i 90 giorni reflog periodo). Lo stesso vale per i commit c e d nell'esempio rebase.

Answer 2

Uno svantaggio specifico del tuo approccio è che riduce drasticamente l'utilità di git bisect nel rintracciare i bug nel tuo codice.

Detto questo, se vi trovate tornando un'intera funzione abbastanza spesso al punto in cui siete alla ricerca di modi per ottimizzare questo processo, si consiglia di chiedersi se si sta fondendosi in master troppo in fretta. Si consiglia di prendere in considerazione l'utilizzo di più rami di lunga durata per impostare un flusso di lavoro adatto al proprio progetto.