ho il mio master ramo e un ramo develop per lavorare su alcune modifiche. Devo unire le modifiche da master a develop, ma alla fine unire tutto da develop a master. Ho due flussi di lavoro diversi in mente:"git pull" o "git merge" tra il master e sviluppo rami
git pull origin master in develop ramogit merge master in develop ramoQual è il modo migliore per fare questo, e perché?
stare attenti con rebase. Se condividi il tuo ramo di sviluppo con qualcuno, rebase può fare un casino di cose. Rebase è valido solo per le tue filiali locali.
regola generale, se hai spinto il ramo all'origine, non usare rebase. Invece, usa unione.
E 'sicuro rebase e un' git push origin rebasedBranch --force' su un repository privato? L'unico utente è me stesso. – k0pernikus
Sì, se sei l'unico utente, ovviamente è sicuro.Io uso git push - forza tutto il tempo in cui sono l'unico utente. :) –
Ricordo l'avvertimento di Eric. Anche se, è perfettamente corretto rebase anche il tuo ramo remoto. Gioca con entrambi rebase e unisci e capirai i pro e i contro di ciascuno e impari quando usarli. –
L'approccio migliore per questo genere di cose è probabilmente git rebase. Ti consente di trasferire le modifiche dal master al tuo ramo di sviluppo, ma lascia tutto il lavoro di sviluppo "in cima" (più avanti nel log di commit) alla roba del master. Quando il tuo nuovo lavoro è completo, l'unione torna al master è quindi molto semplice.
Un buon consiglio, assumendo' develop' non è condiviso con nessun altro –
@KarlBielefeldt Se 'develop' ** è condiviso ** con altri contributori, come dovremmo aggiornare' develop' quando alcuni hotfix sono stati inseriti direttamente in 'master'? Dovremmo fare una fusione, cioè 'git checkout master && git pull --rebase && git checkout sviluppare && git merge master'? Ho lasciato un commento sulla risposta più votata in alto, che descrive anche questa preoccupazione. – modulitos
Questo flusso di lavoro funziona meglio per me:
git checkout -b develop
... apportare alcune modifiche ...
... Avviso master è stato aggiornato ...
... commettere modifiche per sviluppare ...
git checkout master
git pull
... riportare tali modifiche in sviluppo ...
012.git checkout develop
git rebase master
... fare altri cambiamenti ...
... impegnarsi a sviluppare ...
... unirli in Master ...
git checkout master
git pull
git merge develop
super utile, grazie! – tester
Così lavoro anche io e trovo che funzioni bene. C'è una cosa che non faccio però, e questo è il 'git pull' proprio prima della finale 'git merge develop'. Qual è lo scopo di questo? – crdx
Dopo che il master di notifica è stato aggiornato ... parte, il master di checkout non eliminerà le modifiche locali da sviluppare se non le si esegue il commit? – a1an
Se non stai condividendo lo sviluppo di branch con nessuno, ti aggiornerò ogni volta che il master verrà aggiornato, in questo modo non avresti unire commit su tutta la tua cronologia una volta che ti unirai allo sviluppo di master. Flusso di lavoro in questo caso sarà 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
Sopra passi farà sì che il ramo sviluppare sarà sempre in cima alle ultime modifiche dal ramo principale. Una volta che si è fatto con lo sviluppo ramo e che sia aggiornato alla le ultime modifiche sul maestro si può solo unire indietro:
> git checkout -b master
> git merge develop
> git branch -d develop
mia regola è:
rebaseper rami con il stesso nome,mergealtrimenti.
esempi per stessi nomi sarebbero master, origin/master e otherRemote/master.
se develop esiste solo nel repository locale ed è sempre basato su un recente commit origin/master, è necessario chiamarlo master e lavorarci direttamente. semplifica la tua vita e presenta le cose come sono realmente: ti stai sviluppando direttamente sul ramo master.
se develop è condiviso, non deve essere rebasato su master, è appena stato incorporato in esso con --no-ff. stai sviluppando su develop. master e develop hanno nomi diversi, perché vogliamo che siano cose diverse e rimangano separati. non farli lo stesso con rebase.
Letture consigliate: http://nvie.com/posts/a-successful-git-branching-model/ –
'git pull' =' fetch' git + 'git merge FETCH_HEAD' –