"Git pull" o "git merge" tra i rami master e di sviluppo

243

Ho il mio masterramo e un developramo per lavorare su alcune modifiche. Devo unire le modifiche da masterin develop, ma alla fine unirò tutto da developin master. Ho in mente due diversi flussi di lavoro:

git pull origin masternel developramo
git merge masternel developramo

Qual è il modo migliore per farlo, e perché?

git workflow

— Carson
fonte

18

Lettura consigliata: nvie.com/posts/a-successful-git-branching-model

— Alex Brasetvik

2

git pull= git fetch+git merge FETCH_HEAD

— Yousha Aleayoub

104

Fai attenzione con rebase. Se stai condividendo il tuo ramo di sviluppo con qualcuno, rebase può fare un casino di cose. Rebase è buono solo per le tue filiali locali.

Regola empirica, se hai spostato il ramo all'origine, non usare rebase. Invece, usa unisci.

— Eric Leads
fonte

Eppure è sicuro rifare e un git push origin rebasedBranch --forcerepo privato? L'unico utente è me stesso.

— k0pernikus,

Sì, se sei l'unico utente, ovviamente è sicuro. Uso git push --force sempre quando sono l'unico utente. :)

— Tyler Rick,

3

Rispondo all'avvertimento di Eric. Anche se, va perfettamente bene anche il reimpostazione del proprio ramo remoto. Gioca con rebase e merge e capirai i pro e i contro di ciascuno e imparerai quando usarli.

— Ian Lotinsky,

Buon articolo sull'uso di rebase, anche dopo la fusione dopo aver risolto i conflitti: github.com/everpix/Everpix-Intelligence

— Ian Lotinsky,

@IanLotinsky il tuo link non punta a un articolo su rebase. Longshot, ma hai ancora il link corretto? :)

— Daniel Serodio

347

Questo flusso di lavoro funziona meglio per me:

git checkout -b develop

... apporta alcune modifiche ...

... avviso master è stato aggiornato ...

... apporta modifiche per sviluppare ...

git checkout master
git pull

... riporta quei cambiamenti nello sviluppo ...

git checkout develop
git rebase master

... apporta altre modifiche ...

... impegnali a sviluppare ...

... uniscili nel maestro ...

git checkout master
git pull
git merge develop

— Ian Lotinsky
fonte

2

È così che lavoro anche io e trovo che funzioni bene. C'è una cosa che non faccio però, ed è git pullproprio prima della finale git merge develop. Qual è lo scopo di quello?

— crdx,

Dopo che il ... Notice Master è stato aggiornato ... parte, il Master di checkout non cancellerebbe le modifiche locali per svilupparle se non le commetti?

— a1an

1

@ a1an No, ma se non li esegui, le modifiche verranno spostate nel ramo principale e git non ti consentirà di eseguire il pull fino a quando non saranno state eseguite.

— elemjay19

5

@crdx È probabile che altri rami vengano uniti al master remoto prima di unire il ramo al master locale. È possibile estrarre e apportare modifiche al master remoto alla copia locale del master. È così che l'ho capito.

— Tarun,

12

git pull --rebase origin mastersul tuo ramo di sviluppo è un po 'più veloce.

— Nathan Lilienthal,

24

L'approccio migliore per questo genere di cose è probabilmente git rebase. Ti consente di inserire le modifiche dal master nel tuo ramo di sviluppo, ma lascia tutto il tuo lavoro di sviluppo "in cima a" (più avanti nel registro di commit) le cose dal master. Quando il tuo nuovo lavoro è completo, la fusione con il master è molto semplice.

— divegeek
fonte

10

Un buon consiglio, supponendo che developnon sia condiviso con nessun altro.

— Karl Bielefeldt,

1

@KarlBielefeldt Se develop viene condiviso con altri contributori, come potremmo aggiornare developquando alcuni hotfix venivano trasferiti direttamente a master? Dovremmo fare una fusione, cioè git checkout master && git pull --rebase && git checkout develop && git merge master? Ho lasciato un commento sulla risposta più votata sopra, che descrive anche questa preoccupazione.

— Modulitos,

5

Se non stai condividendo il ramo di sviluppo con nessuno, lo rifarei ogni volta che master viene aggiornato, in questo modo non avrai commit di merge in tutta la tua storia una volta che lo farai diventare un master. Il flusso di lavoro in questo caso sarebbe il seguente:

> git clone git://<remote_repo_path>/ <local_repo>
> cd <local_repo>
> git checkout -b develop
....do a lot of work on develop
....do all the commits
> git pull origin master
> git rebase master develop

I passaggi precedenti assicureranno che il ramo di sviluppo sia sempre in cima alle ultime modifiche dal ramo principale. Una volta che hai finito con il ramo di sviluppo ed è ridisegnato alle ultime modifiche su master, puoi semplicemente ricollegarlo:

> git checkout -b master
> git merge develop
> git branch -d develop

— Kirpich
fonte

1

la mia regola empirica è:

rebaseper i rami con lo stesso nome , mergealtrimenti.

esempi per gli stessi nomi sarebbero master, origin/mastere otherRemote/master.

se developesiste solo nel repository locale ed è sempre basato su un origin/mastercommit recente , dovresti chiamarlo mastere lavorare direttamente lì. semplifica la tua vita e presenta le cose come sono in realtà: ti stai sviluppando direttamente sul masterramo.

se developè condiviso, non dovrebbe essere riformulato master, ma semplicemente ricollegato --no-ff. stai sviluppando develop. mastere develophanno nomi diversi, perché vogliamo che siano cose diverse e che restino separati. non farli uguali con rebase.

— hoijui
fonte