Come posso usare git rebase senza richiedere un push forzato?

Nel tentativo di raggiungere il git nirvana, sto passando la giornata a imparare come sfruttare il rebase per le situazioni in cui attualmente mi unisco.

Quando eseguo quello che considero un flusso git 101 (che spiegherò di seguito), devo farlo push --forcequando rimetto le mie modifiche all'origine.

Non sono l'unico - so che questo è un terreno coperto (vedere 1 , 2 , 3 , 4 , 5 ) e capisco le ragioni tecniche per cui è necessaria una forza. Il mio problema è questo --- ci sono molti (molti) post di blog che cantano le lodi di rebase e come ha cambiato le loro vite (vedi 1 , 2 , 3 , 4 per elencarne alcuni), ma nessuno di loro menziona che push --forcefa parte di il loro flusso. Tuttavia, quasi tutte le risposte alle domande di stackoverflow esistenti dicono cose come "sì, se vuoi riformulare, devi usare push --force".

Dato il numero e la religiosità dei sostenitori del rebase, devo credere che l'uso di "push --force" non sia una parte intrinseca di un flusso di rebase, e che se uno deve spesso forzare le loro spinte, sta facendo qualcosa di sbagliato .

push --forceè una brutta cosa .

Quindi ecco il mio flusso. In che modo potrei ottenere gli stessi risultati senza una forza?

Semplice esempio

Due rami:

• v1.0 - un ramo di rilascio, contiene solo patch
• master - tutto per la prossima major release.

Ho alcuni commit di patch e alcuni commit per la prossima versione.

Vorrei incorporare le patch nel mio master in modo che non vadano perse per la prossima versione. Pre-illuminazione, avrei semplicemente:

git checkout master
git merge v1.0

Ma ora ci sto provando

git checkout master
git rebase v1.0

Quindi ora sono qui:

Tempo per:

git push

Niente da fare.

Il rebasing è un ottimo strumento, ma funziona meglio quando lo usi per creare unioni in avanti veloce per i rami di argomento sul master. Ad esempio, potresti riformulare il tuo ramo add-new-widget contro master:

git checkout add-new-widget
git rebase -i master

prima di eseguire una fusione in avanti veloce del ramo nel master. Per esempio:

git checkout master
git merge --ff-only add-new-widget

Il vantaggio di questo è che la tua cronologia non avrà molti commit di unione complessi o conflitti di unione, perché tutte le tue modifiche verranno ribasate sulla punta del master prima dell'unione. Un vantaggio secondario è che hai ribasato, ma non devi usarlo git push --forceperché non stai rovinando la cronologia sul ramo principale.

Questo non è certamente l'unico caso d'uso per rebase, o l'unico flusso di lavoro, ma è uno degli usi più sensati che ho visto. YMMV.

@CodeGnome ha ragione. Non dovresti ribasare il master sul ramo v1.0 ma il ramo v1.0 sul master, questo farà la differenza.

git checkout -b integrate_patches v1.0
git rebase master
git checkout master
git merge integrate_patches

Crea un nuovo ramo che punta alla v1.0, sposta quel nuovo ramo sopra il master e quindi integra la nuova versione delle patch V1.0 nel ramo master. Finirai con qualcosa del tipo:

o [master] [integrate_patches] Another patch on v1.0
o A patch on v1.0
o Another change for the next major release
o Working on the next major release
|  o [v1.0] Another path on v1.0
|  o A patch on v1.0
| /
o Time for the release

Questo modo di usare rebase è consigliato dalla documentazione ufficiale di git .

Penso che tu abbia ragione git push --force: dovresti usarlo solo se hai commesso un errore e hai spinto qualcosa che non volevi.

Devi forzare il push se rebase e hai già pubblicato le tue modifiche, giusto?

Uso il rebase un intero gruppo, ma pubblico su qualcosa di privato in cui un force push non ha importanza (ad esempio: il mio clone su GitHub, come parte di una richiesta pull), o rebase prima di spingere per la prima volta.

Questo è il cuore del flusso di lavoro in cui usi il rebase, ma non forzare molto il push: non pubblicare le cose finché non sono pronte, non rebase dopo aver eseguito il push.

Penso che ci sia un buon caso d'uso per questo modello rebase-then-force-push che non è il risultato di un push errato: lavorare su un ramo di funzionalità da solo da più posizioni (computer). Lo faccio spesso, poiché a volte lavoro in ufficio sul mio desktop, e talvolta da casa / dal sito del cliente sul mio laptop. Di tanto in tanto ho bisogno di rebase per stare al passo con il ramo principale e / o per rendere più pulite le fusioni, ma devo anche forzare il push quando lascio una macchina per andare a lavorare su un'altra (dove mi limito a tirare). Funziona come un incantesimo, purché io sia l'unico a lavorare sul ramo.

Ecco cosa uso (supponendo che il nome del tuo ramo sia foobar ):

git checkout master              # switch to master
git rebase   foobar              # rebase with branch
git merge -s ours origin/master  # do a basic merge -- but this should be empty
git push origin master           # aaand this should work

tl; dr si fonde con rami condivisi, rebase con rami individuali. --force-with-leaseè un'alternativa più sicura alla forza e dovrebbe aiutarti a raggiungere detto git nirvana senza la natura distruttiva della forza.

Una regola pratica generale che ho visto funzionare per i flussi di lavoro di vari team è quella di utilizzare mergeper rami condivisi (cioè, master o sviluppo) e utilizzare rebasequando si lavora sul proprio ramo di funzionalità. Ecco un tipico ciclo di vita di un ramo di funzionalità

git checkout master
git checkout -b new-feature
git commit -am "commit new work"
git push -u origin new-feature
# have code reviewed, run CI, etc.,
# meanwhile master has new commits
git checkout master
git pull
git rebase -i master # -i for interactive rebase allows you to squash intermediate commits
git push --force-with-lease
git merge master

Una semplice versione inglese di ciò che abbiamo fatto qui:

1. Creato un nuovo ramo del master
2. Fatto il lavoro sul ramo e inviato a remoto
3. ribasato da master
4. Spingi il lavoro in remoto con force-with-lease
5. fondersi nel master con un log git molto pulito, riducendo l'ingombro di più unioni dal nostro ramo condiviso per fare in modo che il nostro ramo "raggiunga" l'ultimo master (ramo condiviso)

Il quarto passo è VERAMENTE importante e uno dei motivi principali per cui ho iniziato a sostenere l'uso del rebase. force-with-leasecontrolla il telecomando per vedere se sono stati aggiunti nuovi commit. Se tuogit push stato dimostrato di essere distruttivo, non spingerà!

Spero che questo dia a qualcuno più fiducia nell'usare rebase.