다른 개발자와 함께 프로젝트에서 몇 달 동안 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가 고급 기능인 것 같습니다. 내 직감은 내가하려는 일이 고급 설정이 아니기 때문에 rebase가 필요하지 않다는 것입니다. 나는 심지어 Git에 관한 새로운 Pragmatic Programming 책을 꼼꼼히 살펴 보았고 그것들은 광범위하게 병합되고 거의 rebase에 대해서는 언급하지 않았다.
어쨌든, 나는 최근 지점에서 워크 플로우를 따르고 있었고 마스터로 다시 병합하려고 시도했을 때 모두 지옥에 갔다. 중요하지 않은 것들과 많은 충돌이있었습니다. 갈등은 나에게 이해가되지 않았다. 로컬 마스터가 모든 충돌을 해결했지만 원격 마스터는 여전히 행복하지 않았기 때문에 모든 것을 정리하는 데 하루가 걸렸으며 결국 원격 마스터에게 강제로 밀렸습니다.
이와 같은 "올바른"워크 플로우는 무엇입니까? 힘내는 분기와 병합을 매우 쉽게 만들어야하며, 나는 그것을 보지 못합니다.
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이해에 많은 도움이되었습니다
