마스터와 개발 브랜치 사이의 "git pull"또는 "git merge"

243

나는이 master지점과 develop몇 가지 변경 작업에 대한 분기를. 에서 master로 변경 사항을 병합해야 develop하지만 결국 모든 것을에서 develop로 병합 master합니다. 두 가지 다른 워크 플로를 염두에두고 있습니다.

git pull origin master에 develop지점
git merge master에 develop지점

이를 수행하는 가장 좋은 방법은 무엇이며 왜 그런가요?

git workflow

— 카슨
소스

18

추천 자료 : nvie.com/posts/a-successful-git-branching-model

— Alex Brasetvik

2

git pull= git fetch+git merge FETCH_HEAD

— Yousha Aleayoub

104

리베이스에주의하십시오. 개발 브랜치를 다른 사람과 공유하는 경우 rebase는 문제를 일으킬 수 있습니다. Rebase는 현지 지점에만 적합합니다.

경험상 분기를 원점으로 밀었다면 리베이스를 사용하지 마십시오. 대신, merge를 사용하십시오.

— 에릭 리드
소스

그러나 리베이스하고 git push origin rebasedBranch --force개인 레포지토리 를 이용하는 것이 안전 합니까? 유일한 사용자는 나 자신입니다.

— k0pernikus

네, 유일한 사용자라면 물론 안전합니다. 나는 유일한 사용자 인 git push --force를 항상 사용합니다. :)

— Tyler Rick

3

에릭의 경고를 반영합니다. 그러나 자신의 원격 지사를 리베이스하는 것도 완벽합니다. 리베이스와 병합을 모두 사용하면 각각의 장단점을 이해하고 사용시기를 배울 수 있습니다.

— Ian Lotinsky

rebase 사용에 관한 좋은 기사, 충돌을 해결 한 후에도 병합 : github.com/everpix/Everpix-Intelligence

— Ian Lotinsky

@IanLotinsky 귀하의 링크가 rebase의 기사를 가리 키지 않습니다. Longshot이지만 여전히 올바른 링크가 있습니까? :)

— Daniel Serodio

347

이 워크 플로는 나에게 가장 효과적입니다.

git checkout -b develop

... 일부 변경 ...

통지 마스터가 업데이트되었습니다 ...

... 변경 사항을 커밋하여 개발 ...

git checkout master
git pull

... 그런 변화를 다시 개발하게 ...

git checkout develop
git rebase master

... 더 많이 변경하십시오 ...

... 그들이 개발하도록 커밋 ...

... 마스터에게 합병 ...

git checkout master
git pull
git merge develop

— 이안 로틴 스키
소스

2

이것이 내가 작동하는 방식이며 잘 작동한다는 것을 알았습니다. 내가하지 않는 한 가지가 있으며, 그것이 git pull바로 바로 직전 git merge develop입니다. 그 목적은 무엇입니까?

— crdx

... 알림 마스터가 업데이트 된 후 ... 부분, 체크 아웃 마스터가 로컬 변경 사항을 지워서 커밋하지 않으면 개발하지 않습니까?

— a1an

1

@ a1an 아니오, 그러나 커밋하지 않으면 변경 사항이 마스터 브랜치로 넘어 가고 git은 커밋 될 때까지 잡아 당길 수 없습니다.

— elemjay19

5

@crdx 분기를 로컬 마스터에 병합하기 전에 다른 분기가 원격 마스터에 병합 될 수 있습니다. 원격 마스터 변경 사항을 가져와 로컬 마스터 사본으로 가져옵니다. 이것이 내가 이해 한 방법입니다.

— Tarun

12

git pull --rebase origin master개발 브랜치에서 조금 더 빠릅니다.

— Nathan Lilienthal

24

이런 종류의 일에 가장 적합한 방법은 아마입니다 git rebase. 이를 통해 마스터에서 개발 브랜치로 변경 사항을 가져올 수 있지만 모든 개발 작업은 커밋 로그의 맨 위에있는 상태에서 마스터의 항목으로 남겨 둡니다. 새 작업이 완료되면 마스터로 다시 병합하는 것이 매우 간단합니다.

— 다이브
소스

10

develop다른 사람과 공유하지 않는다고 가정하면 좋은 조언 입니다.

— Karl Bielefeldt

1

@KarlBielefeldt 다른 기고자와 develop 공유 하는 develop경우 일부 핫픽스를 직접 푸시 할 때 어떻게 업데이트 master합니까? 병합을해야합니까 git checkout master && git pull --rebase && git checkout develop && git merge master? 위의 최고 투표 답변에 대한 의견을 남겼습니다.

— modulitos

5

개발 브랜치를 다른 사람과 공유하지 않는 경우 마스터가 업데이트 될 때마다 리베이스를 리베이스 할 것입니다. 그러면 개발을 다시 마스터로 병합하면 히스토리 전체에서 병합 커밋이 발생하지 않습니다. 이 경우 워크 플로는 다음과 같습니다.

> 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

위의 단계는 개발 브랜치가 항상 마스터 브랜치의 최신 변경 사항 위에 있는지 확인합니다. 브랜치 개발을 마치고 마스터의 최신 변경 사항에 기반을두면 다시 병합 할 수 있습니다.

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

— KiRPiCH
소스

1

내 경험 법칙은 다음과 같습니다.

rebase와 나뭇 가지에 같은 이름 , merge그렇지.

동일한 이름의 예는 master, origin/master및 otherRemote/master입니다.

경우 develop로컬 저장소에 존재하고, 항상 최근이 기반으로 origin/master커밋, 당신은 그것을 호출해야 master하고, 직접이 작동합니다. 그것은 당신의 인생을 단순화하고, 실제로있는 그대로 제시합니다 : 당신은 master지점 에서 직접 발전하고 있습니다.

develop공유 된 경우 에 기반으로하지 말고에 master다시 병합하면됩니다 --no-ff. 에 개발 중입니다 develop. master그리고 develop우리가 다른 일을 할 원하기 때문에, 다른 이름을 가지고 있고, 별도의 유지. 와 동일하게 만들지 마십시오 rebase.

— 회이
소스