„Git pull” lub „git merge” między gałęziami master i developerskimi

243

Mam swój masteroddział i developoddział do pracy nad kilkoma zmianami. I trzeba scalić zmiany od masterdo develop, ale w końcu połączyć wszystko od developdo master. Mam na myśli dwa różne przepływy pracy:

git pull origin masterdo developoddziału
git merge masterdo developoddziału

Jaki jest najlepszy sposób na to i dlaczego?

git workflow

— Carson
źródło

18

Zalecane lektury: nvie.com/posts/a-successful-git-branching-model

— Alex Brasetvik

2

git pull= git fetch+git merge FETCH_HEAD

— Yousha Aleayoub

104

Ostrożnie z rebase. Jeśli udostępniasz swoją gałąź rozwoju komukolwiek, rebase może zrobić bałagan. Rebase jest dobry tylko dla twoich lokalnych oddziałów.

Ogólna zasada, jeśli przesunąłeś gałąź do początku, nie używaj bazy. Zamiast tego użyj scalenia.

— Eric Leads
źródło

Ale czy można bezpiecznie bazować i git push origin rebasedBranch --forcekorzystać z prywatnego repozytorium? Jedynym użytkownikiem jest ja.

— k0pernikus

Tak, jeśli jesteś jedynym użytkownikiem, oczywiście jest to bezpieczne. Używam git push - force przez cały czas, gdy jestem jedynym użytkownikiem. :)

— Tyler Rick

3

Powtarzam ostrzeżenie Erica. Chociaż bazowanie na własnym oddziale również jest całkowicie w porządku. Graj zarówno z rebase, jak i scalaniem, a zrozumiesz zalety i wady każdego z nich i dowiesz się, kiedy z nich korzystać.

— Ian Lotinsky,

Dobry artykuł na temat korzystania z rebase, a nawet łączenia po rozwiązaniu konfliktów: github.com/everpix/Everpix-Intelligence

— Ian Lotinsky

@IanLotinsky Twój link nie prowadzi do artykułu na temat bazy. Longshot, ale czy nadal masz poprawny link? :)

— Daniel Serodio

347

Ten przepływ pracy działa najlepiej dla mnie:

git checkout -b develop

... dokonaj zmian ...

... wzorzec powiadomień został zaktualizowany ...

... zatwierdzaj zmiany, by się rozwijać ...

git checkout master
git pull

... przywróć te zmiany do rozwoju ...

git checkout develop
git rebase master

... dokonaj kilku zmian ...

... zobowiązać ich do rozwoju ...

... scalić je w mistrza ...

git checkout master
git pull
git merge develop

— Ian Lotinsky
źródło

2

Tak też pracuję i uważam, że działa dobrze. Jest jedna rzecz, której nie robię, i to jest git pulltuż przed finałem git merge develop. Jaki jest tego cel?

— crdx

Po części ... wzorzec powiadomień został zaktualizowany ... czy wzorzec kasowania nie wyczyściłby lokalnych zmian w celu opracowania, jeśli ich nie zatwierdzisz?

— a1an

1

@ a1an Nie, ale jeśli ich nie zatwierdzisz, zmiany zostaną przeniesione do gałęzi master i git nie pozwoli ci pociągnąć, dopóki nie zostaną zatwierdzone.

— elemjay19,

5

@crdx Możliwe, że inne gałęzie zostaną scalone ze zdalnym masterem przed scaleniem oddziału z lokalnym masterem. Pobierasz i wprowadzasz zmiany zdalne master do lokalnej kopii master. Tak to zrozumiałem.

— Tarun

12

git pull --rebase origin masterw twojej gałęzi rozwoju jest trochę szybszy.

— Nathan Lilienthal,

24

Prawdopodobnie najlepsze podejście do tego rodzaju rzeczy git rebase. Pozwala na ściągnięcie zmian z master do gałęzi programistycznej, ale całą pracę programistyczną pozostaw „na wierzchu” (później w dzienniku zatwierdzeń) rzeczy z master. Po zakończeniu nowej pracy scalenie z powrotem do mistrza jest wtedy bardzo proste.

— divegeek
źródło

10

Dobra rada, zakładając, że developnie jest udostępniany nikomu innemu.

— Karl Bielefeldt,

1

@KarlBielefeldt Jeśli develop jest udostępniany innym współautorom, w jaki sposób zaktualizowalibyśmy się, developgdy niektóre poprawki zostały przekazane bezpośrednio do master? Czy powinniśmy wykonać scalenie, tj. git checkout master && git pull --rebase && git checkout develop && git merge master? Zostawiłem komentarz do wyżej głosowanej odpowiedzi powyżej, która również opisuje tę obawę.

— modulitos,

5

Jeśli nie dzielisz się gałęzią rozwijania z nikim, to po prostu będę ją zmieniał za każdym razem, gdy master zostanie zaktualizowany, w ten sposób nie będziesz mieć zatwierdzeń scalania w całej swojej historii, kiedy scalisz rozwój z powrotem w master. W tym przypadku przepływ pracy wyglądałby następująco:

> 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

Powyższe kroki zapewnią, że twoja gałąź rozwoju będzie zawsze na bieżąco z najnowszymi zmianami z gałęzi master. Po zakończeniu tworzenia gałęzi i ponownym wprowadzeniu zmian do master możesz po prostu scalić:

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

— KiRPiCH
źródło

1

moją ogólną zasadą jest:

rebasedla oddziałów o tej samej nazwie , w mergeprzeciwnym razie.

Przykładami takich samych nazwach byłoby master, origin/masteri otherRemote/master.

jeśli developistnieje tylko w lokalnym repozytorium i zawsze jest oparte na ostatnim origin/masterzatwierdzeniu, powinieneś go wywołać masteri pracować bezpośrednio tam. upraszcza twoje życie i przedstawia rzeczy takimi, jakie są w rzeczywistości: rozwijasz się bezpośrednio w Interneciemaster branży.

jeśli developjest udostępniony, nie należy go ponownie włączać master, po prostu ponownie się z nim łączy --no-ff. rozwijasz się develop. masteri developmają różne nazwy, ponieważ chcemy, aby były różnymi rzeczami i pozostały osobne. nie róbcie tego samego z rebase.

— hoijui
źródło