Git 워크 플로 및 리베이스 및 병합 질문

질문 : Git 워크 플로 및 리베이스 및 병합 질문

---

저는 다른 개발자 한 명과 함께 프로젝트에서 몇 달 동안 Git을 사용해 왔습니다. 나는 SVN에 대해 수년간의 경험을 가지고 있기 때문에 관계에 많은 짐을 가져다 줄 것 같습니다.

Git이 분기 및 병합에 탁월하다고 들었는데 지금까지는 보이지 않습니다. 물론 분기는 매우 간단하지만 병합하려고하면 모든 것이 지옥으로 이동합니다. 이제 저는 SVN에서 익숙해졌지만, 한 서브 파 버전 시스템을 다른 시스템으로 교환 한 것 같습니다.

내 파트너는 내 문제가 willy-nilly를 병합하려는 욕구에서 비롯되며 여러 상황에서 병합 대신 rebase를 사용해야한다고 말합니다. 예를 들어, 그가 작성한 워크 플로는 다음과 같습니다.

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature

기본적으로 기능 브랜치를 생성하고 항상 마스터에서 브랜치로 리베이스하고 브랜치에서 마스터로 다시 병합합니다. 주목해야 할 중요한 점은 브랜치가 항상 로컬에 있다는 것입니다.

제가 시작한 워크 플로는 다음과 같습니다.

clone remote repository
create my_new_feature branch on remote repository
git checkout -b --track my_new_feature origin/my_new_feature
..work, commit, push to origin/my_new_feature
git merge master (to get some changes that my partner added)
..work, commit, push to origin/my_new_feature
git merge master
..finish my_new_feature, push to origin/my_new_feature
git checkout master
git merge my_new_feature
delete remote branch
delete local branch

두 가지 근본적인 차이점이 있습니다 (제 생각에) : 리베이스 대신 항상 병합을 사용하고 기능 브랜치 (및 기능 브랜치 커밋)를 원격 저장소로 푸시합니다.

원격 지점에 대한 나의 이유는 작업하는 동안 작업을 백업하기를 원하기 때문입니다. 저장소는 자동으로 백업되며 문제가 발생하면 복원 할 수 있습니다. 내 노트북은 그렇지 않거나 철저하지 않습니다. 따라서 다른 곳에서 미러링되지 않은 랩톱에 코드가있는 것이 싫습니다.

rebase 대신 병합에 대한 나의 이유는 병합이 표준 인 것처럼 보이고 rebase가 고급 기능인 것 같다는 것입니다. 내 직감은 내가하려는 것이 고급 설정이 아니기 때문에 리베이스가 불필요하다는 것입니다. 나는 심지어 Git에 관한 새로운 Pragmatic Programming 책을 읽었고, 그들은 병합을 광범위하게 다루고 리베이스에 대해 거의 언급하지 않았습니다.

어쨌든, 나는 최근 브랜치에서 내 워크 플로를 따르고 있었고 마스터로 다시 병합하려고했을 때 모든 것이 지옥으로 갔다. 중요하지 말아야 할 것들과 수많은 갈등이있었습니다. 갈등은 나에게 의미가 없었습니다. 모든 것을 정리하는 데 하루가 걸렸고, 로컬 마스터가 모든 충돌을 해결했기 때문에 결국 원격 마스터에 강제 푸시로 정점에 달했지만 원격 마스터는 여전히 만족하지 않았습니다.

이와 같은 "올바른"워크 플로우는 무엇입니까? Git은 분기와 병합을 매우 쉽게 만들어야하는데, 나는 그것을 보지 못하고 있습니다.

2011-04-15 업데이트

이것은 매우 인기있는 질문 인 것 같아서 처음 질문 한 이후로 2 년 간의 경험을 업데이트 할 것이라고 생각했습니다.

최소한 우리의 경우에는 원래 워크 플로가 올바른 것으로 밝혀졌습니다. 즉, 이것이 우리가하는 일이며 작동합니다.

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge my_new_feature

사실, 우리의 워크 플로우는 원시 병합 대신 스쿼시 병합 을 수행하는 경향이 있기 때문에 약간 다릅니다. ( 참고 : 이것은 논란의 여지가 있습니다. 아래를 참조하십시오. )이를 통해 전체 기능 분기를 마스터의 단일 커밋으로 전환 할 수 있습니다. 그런 다음 기능 브랜치를 삭제합니다. 이를 통해 브랜치에서 약간 지저분하더라도 마스터에 대한 커밋을 논리적으로 구조화 할 수 있습니다. 그래서 이것이 우리가하는 일입니다 :

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge --squash my_new_feature
git commit -m "added my_new_feature"
git branch -D my_new_feature

스쿼시 병합 논쟁 -여러 댓글 작성자가 지적했듯이 스쿼시 병합은 기능 브랜치의 모든 기록을 폐기합니다. 이름에서 알 수 있듯이 모든 커밋을 하나의 커밋으로 압축합니다. 작은 기능의 경우 단일 패키지로 압축하므로 의미가 있습니다. 더 큰 기능의 경우 특히 개별 커밋이 이미 원자 적 인 경우에는 좋은 생각이 아닙니다. 그것은 정말로 개인적인 취향에 달려 있습니다.

Github 및 Bitbucket (기타?) 풀 요청 -병합 / 리베이스가 풀 요청과 어떻게 관련되는지 궁금하다면 마스터로 다시 병합 할 준비가 될 때까지 위의 모든 단계를 수행하는 것이 좋습니다. 수동으로 git과 병합하는 대신 PR을 수락하면됩니다. 이것은 스쿼시 병합을 수행하지 않지만 (적어도 기본적으로는 아님), 스쿼시가 아닌 비 빨리 감기가 풀 요청 커뮤니티에서 허용되는 병합 규칙입니다 (내가 아는 한). 특히 다음과 같이 작동합니다.

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git push # May need to force push
...submit PR, wait for a review, make any changes requested for the PR
git rebase master
git push # Will probably need to force push (-f), due to previous rebases from master
...accept the PR, most likely also deleting the feature branch in the process
git checkout master
git branch -d my_new_feature
git remote prune origin

저는 Git을 사랑하게되었고 SVN으로 돌아가고 싶지 않습니다. 고군분투하고 있다면 그것에 충실하면 결국 터널 끝에서 빛을 보게 될 것입니다.

답변

---

"충돌"은 "동일한 콘텐츠의 병렬 진화"를 의미합니다. 따라서 병합 중에 "모두 지옥으로"이동하면 동일한 파일 세트에 대해 엄청난 발전이 있음을 의미합니다.

리베이스가 병합보다 나은 이유는 다음과 같습니다.

• 마스터 중 하나를 사용하여 로컬 커밋 기록을 다시 작성한 다음 작업을 다시 적용하고 충돌을 해결합니다.
• 최종 병합은 마스터의 모든 커밋 내역과 다시 적용 할 변경 사항 만 포함하므로 "빨리 감기"작업이 될 것입니다.

이 경우 올바른 워크 플로 (일반 파일 집합에 대한 진화)가 먼저 리베이스 된 다음 병합되는지 확인 합니다.

그러나 이는 (백업 이유로 인해) 로컬 브랜치를 푸시하는 경우 해당 브랜치를 다른 사람이 가져 오지 않아야 함을 의미합니다 (연속 리베이스에 의해 커밋 내역이 다시 작성되므로).

---

그 주제 (REBASE 다음 병합 워크 플로우)에서 barraponto가 에서 의견이 개 흥미로운 게시물을 모두 언급 randyfay.com :

• Git에 대한 Rebase Workflow : 먼저 가져 오기를 상기시키고 rebase :

HEAD 최신 패치처럼 항상 공개 브랜치의 맨 위에 올라갑니다.

(바자에도 비슷한 기술이 있습니다)

• Git 재해 방지 : 피투성이 이야기 git push --force 의 위험성에 대해 (예를 들어 git pull --rebase 대신)

출처 : https://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions