In che modo il recupero è diverso dal pull e in che modo l'unione è diversa dal rebase?

160

Non riesco proprio a capirlo. Ho letto molto sul web e sui libri e qualcosa non mi sta proprio nella testa. Qualcuno può darmi la versione fittizia di quanto segue:

git fetch vs pull
git merge vs rebase

git

— techsjs2013
fonte

24

Sono d'accordo con l'interrogatore. La documentazione e i consigli sono così pesanti e possibili permutazioni del flusso di lavoro così enormi che si diventa estremamente confusi. La testa è appena esplosa e non si sa bene cosa chiedere, semplicemente non è così ovvio.

— Ed Randall,

3

Perché non scegliere la risposta di pestrella come accettata?

— Arashsoft,

@Arashsoft perché non si vede dal 2013

— VdeX il

415

prendere vs tirare

fetch scaricherà eventuali modifiche dal ramo remoto *, aggiornando i dati del repository, ma lasciando invariato il ramo locale *.

pulleseguirà un fetche inoltre mergele modifiche nella tua filiale locale.

Qual è la differenza? pullaggiorna la tua filiale locale con le modifiche dalla filiale estratta. A fetchnon fa avanzare la tua filiale locale.

unione vs rebase

Data la seguente storia:

          C --- D --- E locale
         /
    A --- B --- F --- G telecomando

mergeunisce due storie di sviluppo insieme. Lo fa riproducendo le modifiche che si sono verificate sul ramo locale dopo che si è discostato sul ramo remoto e registra il risultato in un nuovo commit. Questa operazione conserva gli antenati di ciascun commit.

L'effetto di a mergesarà:

          C --- D --- E locale
         / \
    A --- B --- F --- G --- H remoto

rebaseprenderà i commit esistenti nella tua filiale locale e li riapplicerà in cima alla filiale remota. Questa operazione riscrive gli antenati dei tuoi commit locali.

L'effetto di a rebasesarà:

                  C '- D' - E 'locale
                 /
    A --- B --- F --- G telecomando

Qual è la differenza? A mergenon cambia la discendenza dei commit. A rebase riscrive gli antenati dei tuoi impegni locali.

*Questa spiegazione presuppone che il ramo corrente è un ramo locale, e che il ramo specificato come argomento fetch, pull, merge, o rebaseè un ramo remoto. Questo è il solito caso. pull, ad esempio, scaricherà tutte le modifiche dal ramo specificato , aggiornerà il repository e mergele modifiche nel ramo corrente .

— pestrella
fonte

31

Questa è di gran lunga la spiegazione più semplice e migliore senza entrare nel dibattito dietro ogni pratica. Grazie!

— Jonathan S. Fisher,

3

Risposta assolutamente dorata

— ChaseMoskal,

5

Vorrei poter "preferito" questa risposta. Forse lo stamperò e lo legherò sul mio muro.

— LarsH,

2

Direi la migliore delle migliori risposte che ho in StackOverflow, grazie

— Shahab J

1

Se il recupero scarica solo le modifiche dal ramo remoto e aggiorna i dati del repository, ma lascia invariato il ramo locale, qual è il punto di recupero se la directory di lavoro non mostra / riflette le modifiche? La mia domanda originariamente era che come potevo vedere i cambiamenti che qualcun altro ha fatto e poi decidere se vorrei unirli nella mia directory di lavoro (cioè sperimentare i cambiamenti di altre persone per assicurarmi che non rompesse il mio lavoro) ma sono ancora confuso come farlo? Devo solo fare un pul e sperimentare / esplorare, e se fosse problematico, fare un hard reset?

28

Fetch vs Pull

Git fetch aggiorna semplicemente i dati del tuo repository, ma un git pull eseguirà sostanzialmente un recupero e quindi unirà il ramo estratto

Qual è la differenza tra 'git pull' e 'git fetch'?

Unisci vs Rebase

dal blog Atlassian SourceTree, unisci o ripristina :

La fusione unisce due linee di sviluppo, preservando al contempo la discendenza della storia di ciascun commit.

Al contrario, il rebasing unifica le linee di sviluppo riscrivendo le modifiche dal ramo di origine in modo che appaiano come figli del ramo di destinazione, fingendo effettivamente che tali commit siano stati scritti sempre sopra il ramo di destinazione.

Inoltre, dai un'occhiata a Learn Git Branching , che è un bel gioco che è stato appena pubblicato su HackerNews ( link per pubblicare ) e insegna molti trucchi di ramificazione e fusione. Credo che sarà molto utile in questa materia.

— Felipe Sabino
fonte

grazie Felips .. quindi se eseguo un recupero da remoto il mio ramo principale non avrà gli aggiornamenti? inoltre sembra che dovrei rifare di più rispetto a Merga

— techsjs2013,

rebase vs merge dipende da quale è la tua intenzione, tenendo presente che rebase riscrive tutti i commit della cronologia. E sì, se recuperi solo, il ramo master non verrà modificato, dovrai unire (o tirare) per applicare le modifiche remote

— Felipe Sabino,

git merge <remote>/<branch>. per esempio, se sei il ramo principale e il tuo telecomando è chiamato origine, puoi farlo git merge origin/master.

— Felipe Sabino,

quindi sembra che dovrei sempre fare un checkout git master git fetch git diff origin / master git rebase origin master

— techsjs2013

8

pull vs fetch :

Il modo in cui lo capisco è che git pullè semplicemente git fetchseguito da git merge. Vale a dire recuperare le modifiche da un ramo remoto e quindi unirle nel ramo corrente.

unione vs rebase :

Una fusione farà come dice il comando; unire le differenze tra il ramo corrente e il ramo specificato (nel ramo corrente). Vale a dire il comando git merge another_branchsi fonderà another_branchnel ramo corrente.

Un rebase funziona in modo un po 'diverso ed è abbastanza bello. Diciamo che esegui il comando git rebase another_branch. Git troverà prima l'ultima versione comune tra il ramo corrente e another_branch. Vale a dire il punto prima che i rami divergessero. Quindi git sposterà questo punto divergente alla testa del another_branch. Infine, tutti i commit nel ramo corrente dal punto divergente originale vengono riprodotti dal nuovo punto divergente. Questo crea una storia molto pulita, con meno rami e fusioni.

Tuttavia, non è privo di insidie! Dato che la cronologia delle versioni è "riscritta", dovresti farlo solo se il commit esiste solo nel tuo repository git locale. Cioè: non farlo mai se hai trasferito i commit a un repository remoto.

La spiegazione sulla riformulazione fornita in questo libro online è abbastanza buona, con illustrazioni di facile comprensione.

tirare con rebasing invece di unire

In realtà sto usando abbastanza rebase, ma di solito è in combinazione con pull:

git pull --rebase

recupererà le modifiche remote e quindi rifaserà invece di unire. Vale a dire ripeterà tutti i tuoi commit locali dall'ultima volta che hai eseguito un pull. Lo trovo molto più pulito rispetto a un normale pull con la fusione, che creerà un ulteriore impegno con le fusioni.

— Steinar
fonte

quindi se sto lavorando e ramo e voglio ricollegarlo al master prima di fare una spinta. Dovrei fare il checkout master, quindi ottenere la correzione rebase?

— techsjs2013,

Non riesco ancora a

— capire

Penso che le illustrazioni fornite dalla risposta di Pestrella mostrino chiaramente la differenza. Inoltre, controlla: git-scm.com/book/en/Git-Branching-Rebasing - che fa un lavoro abbastanza decente nel spiegarlo (stesso collegamento a quello nella risposta, ma dato di nuovo per quelli pigri).

— Steinar,

0

Unisci : il ramo HEAD genererà un nuovo commit, preservando l'antenato di ogni cronologia di commit. La storia può essere inquinata se i commit di unione sono fatti da più persone che lavorano nello stesso ramo in parallelo.

Rebase : riscrive le modifiche di un ramo su un altro senza creare un nuovo commit. La cronologia del codice è semplificata, lineare e leggibile ma non funziona con le richieste pull, perché non puoi vedere quali modifiche minori sono state apportate da qualcuno.

Vorrei utilizzare git mergequando ho a che fare con il flusso di lavoro basato sulle funzionalità o se non ho familiarità con rebase. Ma, se voglio una storia più pulita e lineare, allora git rebaseè più appropriato. Per maggiori dettagli assicurati di dare un'occhiata a questo articolo di unione o rebase .

— Nesha Zoric
fonte