Quando dovrei usare git pull --rebase?

Conosco alcune persone che usano git pull --rebasedi default e altre che insistono per non usarlo mai. Credo di aver capito la differenza tra fusione e rebasing, ma sto cercando di metterlo nel contesto di git pull. Si tratta solo di non voler vedere molti messaggi di commit unione o ci sono altri problemi?

Dovresti usare git pull --rebasequando

• le modifiche non meritano un ramo separato

Anzi - perché non allora? È più chiaro e non impone un raggruppamento logico sui tuoi commit.

Ok, suppongo che abbia bisogno di qualche chiarimento. In Git, come probabilmente sai, sei incoraggiato a ramificarsi e fondersi. La tua filiale locale, in cui raccogli le modifiche, e la filiale remota sono, in realtà, diverse filiali e git pullsta per fonderle. È ragionevole, dal momento che spingi non molto spesso e di solito accumuli un numero di modifiche prima che costituiscano una funzionalità completa.

Tuttavia, a volte - per qualsiasi motivo - pensi che sarebbe effettivamente meglio se questi due - remoti e locali - fossero un ramo. Come in SVN. È qui che git pull --rebaseentra in gioco. Non ti unisci più - ti impegni effettivamente in cima al ramo remoto . Ecco di cosa si tratta.

Che sia pericoloso o meno è la questione se stai trattando il ramo locale e remoto come una cosa inseparabile. A volte è ragionevole (quando i cambiamenti sono piccoli, o se sei all'inizio di uno sviluppo robusto, quando cambiamenti importanti sono portati da piccoli impegni). A volte non lo è (quando normalmente crei un altro ramo, ma eri troppo pigro per farlo). Ma questa è una domanda diversa.

Vorrei fornire una prospettiva diversa su cosa significhi effettivamente "git pull --rebase", perché a volte sembra perdersi.

Se hai mai usato Subversion (o CVS), potresti essere abituato al comportamento di "svn update". Se hai delle modifiche da impegnare e il commit fallisce perché sono state apportate modifiche a monte, "svn update". Subversion procede unendo le modifiche a monte con le tue, causando potenzialmente conflitti.

Quello che Subversion ha appena fatto è stato essenzialmente "pull --rebase". L'atto di riformulare le modifiche locali per renderle relative alla versione più recente è la parte "riequilibrante" di essa. Se prima del tentativo di commit fallito avevi eseguito "svn diff" e successivamente hai confrontato il diff risultante con l'output di "svn diff", la differenza tra i due diff è ciò che ha fatto l'operazione di rebasing.

La differenza principale tra Git e Subversion in questo caso è che in Subversion, le "tue" modifiche esistono solo come modifiche non impegnate nella tua copia di lavoro, mentre in Git hai delle commit effettive localmente. In altre parole, in Git hai biforcuto la storia; la tua storia e la storia a monte sono divergenti, ma hai un antenato comune.

Secondo me, nel caso normale di avere il tuo ramo locale semplicemente riflettendo il ramo a monte e facendo uno sviluppo continuo su di esso, la cosa giusta da fare è sempre "--rebase", perché è quello che stai facendo semanticamente . Tu e gli altri state tagliando via la storia lineare prevista di un ramo. Il fatto che qualcun altro abbia spinto leggermente prima del tuo tentativo di spinta è irrilevante, e sembra controproducente per ognuno di questi incidenti di tempismo comportare fusioni nella storia.

Se senti davvero il bisogno di qualcosa per essere un ramo per qualsiasi motivo, questa è una preoccupazione diversa secondo me. Ma a meno che tu non abbia un desiderio specifico e attivo di rappresentare i tuoi cambiamenti sotto forma di unione, il comportamento predefinito dovrebbe, secondo me, essere "git pull --rebase".

Ti preghiamo di considerare altre persone che hanno bisogno di osservare e comprendere la storia del tuo progetto. Vuoi che la storia sia disseminata di centinaia di fusioni in tutto il luogo o vuoi solo le poche fusioni selezionate che rappresentano reali fusioni di sforzi intenzionali di sviluppo divergente?

Forse il modo migliore per spiegarlo è con un esempio:

1. Alice crea il ramo tematico A e ci lavora
2. Bob crea un ramo di argomento B non correlato e ci lavora
3. Lo fa Alice git checkout master && git pull. Il Master è già aggiornato.
4. Bob lo fa git checkout master && git pull. Il Master è già aggiornato.
5. Lo fa Alice git merge topic-branch-A
6. Bob lo fa git merge topic-branch-B
7. Bob fa git push origin masterprima di Alice
8. Alice lo fa git push origin master, il che viene rifiutato perché non è un'unione di avanzamento rapido.
9. Alice guarda il registro di origine / master e vede che il commit non è correlato al suo.
10. Lo fa Alice git pull --rebase origin master
11. Il commit di merge di Alice viene svolto, il commit di Bob viene eseguito e il commit di Alice viene applicato dopo il commit di Bob.
12. Alice lo fa git push origin master, e tutti sono felici di non dover leggere un inutile commit di unione quando guardano i log in futuro.

Si noti che il ramo specifico che viene unito è irrilevante per l'esempio. Il master in questo esempio potrebbe essere altrettanto facilmente un ramo di rilascio o un ramo di sviluppo. Il punto chiave è che Alice e Bob stanno contemporaneamente unendo i loro rami locali a un ramo remoto condiviso.

Penso che dovresti usare git pull --rebasequando collabori con altri nello stesso ramo. Sei nel tuo lavoro → commit → lavoro → ciclo di commit, e quando decidi di spingere il tuo lavoro la tua spinta viene rifiutata, perché c'è stato un lavoro parallelo sullo stesso ramo. A questo punto faccio sempre a pull --rebase. Non uso lo squash (per appiattire i commit), ma rifaccio per evitare i commit di unione extra.

Man mano che la tua conoscenza di Git aumenta, ti ritrovi a guardare molto di più nella storia rispetto a qualsiasi altro sistema di controllo della versione che ho usato. Se hai un sacco di piccoli impegni di unione, è facile perdere la concentrazione del quadro più ampio che sta accadendo nella tua storia.

Questa è in realtà l'unica volta che eseguo il rebasing (*) e il resto del mio flusso di lavoro è basato su merge. Ma finché i committer più frequenti lo fanno, la storia sembra molto meglio alla fine.

(*) Durante l'insegnamento di un corso Git, uno studente mi ha arrestato su questo, dal momento che in alcune circostanze ho anche sostenuto il rinnovamento dei rami delle funzioni. E aveva letto questa risposta;) È anche possibile tale rifasamento, ma deve sempre essere secondo un sistema prestabilito / concordato, e come tale non dovrebbe essere "sempre" applicato. E a quel tempo di solito non lo faccio pull --rebaseneanche, ed è di questo che si tratta;)

Non credo che ci sia mai un motivo per non usarlo pull --rebase- ho aggiunto il codice a Git specificamente per consentire al mio git pullcomando di ribadire sempre contro i commit a monte.

Quando si guarda alla storia, non è mai interessante sapere quando il ragazzo / ragazza che lavora alla funzione si è fermato per sincronizzarsi. Potrebbe essere utile per il ragazzo / ragazza mentre lo sta facendo, ma è quello che reflogserve. Sta solo aggiungendo rumore per tutti gli altri.

Ricorda:

• pull = fetch + merge
• pull --rebase = fetch + rebase

Quindi, scegli il modo in cui vuoi gestire il tuo ramo.

Faresti meglio a conoscere la differenza tra unire e rebase :)

Penso che si riduce a una preferenza personale.

Vuoi nascondere i tuoi sciocchi errori prima di spingere le tue modifiche? Se è così, git pull --rebaseè perfetto. Ti consente di ridurre in seguito i tuoi commit a pochi (o uno) commit. Se ti sei unito alla tua storia (non pubblicata), non è così facile fare una storia git rebasesuccessiva.

Personalmente non mi dispiace pubblicare tutti i miei sciocchi errori, quindi tendo a fondermi invece di ribadire.

git pull --rebasepotrebbe nascondere una riscrittura della cronologia da un collaboratore git push --force. Consiglio di usarlo git pull --rebase solo se sai di aver dimenticato di spingere i tuoi commit prima che qualcun altro faccia lo stesso.

Se non hai commesso nulla, ma il tuo spazio di lavoro non è pulito, poco git stashprima di git pull. In questo modo non riscrivi silenziosamente la tua storia (che potrebbe far cadere silenziosamente parte del tuo lavoro).