마스터에 병합 할 때 첫 번째 분기가 스쿼시 된 후 분기의 분기 병합

마스터에 병합 할 때 첫 번째 분기가 스쿼시 된 후 분기의 분기 병합

---

다음은 직장에서 일반적으로 다루는 워크 플로입니다.

git checkout -b feature_branch
# Do some development
git add .
git commit
git push origin feature_branch

이 시점에서 기능 브랜치는 동료의 검토를 받고 있지만 .NET Framework에 종속 된 다른 기능을 계속 개발하고 싶습니다 feature_branch. 그래서 feature_branch검토 하는 동안 ...

git checkout feature_branch
git checkout -b dependent_branch
# Do some more development
git add .
git commit

이제 feature_branch의 코드 검토에 대한 응답으로 몇 가지 변경을 수행합니다.

git checkout feature_branch
# Do review fixes
git add .
git commit
git checkout dependent_branch
git merge feature_branch

이제 여기에서 문제가 생깁니다. master에 대한 스쿼시 정책이 있습니다. 즉, master에 병합 된 기능 분기를 단일 커밋으로 스쿼시해야합니다.

git checkout feature_branch
git log # Look for hash at beginning of branch
git rebase -i  first_hash_of_branch # Squash feature_branch into a single commit
git merge master

를 제외한 모든 것이 멋집니다 dependent_branch. 종속 브랜치를 마스터로 리베이스하거나 마스터를 마스터로 병합하려고 할 때 git은 다시 작성 / 스쿼시 된 기록에 혼란스럽고 기본적으로 모든 변경 사항을 depedendent_branch충돌로 표시합니다. .NET의 모든 변경 사항을 거치고 기본적으로 다시 수행하거나 충돌을 해제하는 것은 PITA입니다 dependent_branch. 이것에 대한 해결책이 있습니까? 때로는 수동으로 패치를 만들어 마스터의 새로운 브랜치에 적용 하겠지만 실제 충돌이있는 경우 수정하는 것이 더 나쁩니다.

git checkout dependent_branch
git diff > ~/Desktop/dependent_branch.diff
git checkout master
git checkout -b new_dependent_branch
patch -p1 < ~/Desktop/dependent_branch.diff
# Pray for a clean apply.

어떤 아이디어? 스쿼시 동안 재 작성된 기록 때문에 이런 일이 발생한다는 것을 알고 있지만 변경할 수없는 요구 사항입니다. 최상의 솔루션 / 해결 방법은 무엇입니까? 내가 할 수있는 마법이 있나요? 아니면 수동으로 diff를 만드는 것과 관련된 모든 단계를 수행하는 더 빠른 방법이 있습니까?

---

왜 이런 일이 발생하는지에 대해 조금 :

나는 드리겠습니다 O될 "원본 마스터"와 FB기능 지점이되어에서 합병 후, "새 마스터"수 :

feature_branch다음과 같이 말합니다 .

O - A - B - C 

dependent_feature 그 위에 몇 가지 추가 커밋이 있습니다.

O - A - B - C - D - E - F

원래 기능 브랜치를 마스터로 병합하고 아래로 스쿼시하여 다음을 제공합니다.

O - FB

이제 종속 브랜치를 리베이스하려고 할 때 git은 해당 브랜치 간의 공통 조상을 파악하려고합니다. 원래 였을 것이지만 C커밋을 스쿼시하지 않았다면 대신 git O이 공통 조상으로 찾습니다 . 그 결과, 자식은 재생하려고하는 A, B그리고 C어떤이되어 이미 포함 에 FB, 당신은 충돌의 무리를 얻을 것입니다.

이러한 이유로 일반적인 rebase 명령에 실제로 의존 할 수 없으며 --onto매개 변수 를 제공하여 더 명확하게 설명해야합니다 .

git rebase --onto master HEAD~3  # instruct git to replay only the last
                                 # 3 commits, D E and F, onto master.

HEAD~3분기에 필요한대로 매개 변수를 수정하면 중복 충돌 해결을 처리 할 필요가 없습니다.

범위 지정이 마음에 들지 않고 원래 기능 브랜치를 아직 삭제하지 않은 경우 일부 대체 구문 :

git rebase --onto master feature_branch dependent_feature

                                 # replay all commits, starting at feature_branch
                                 # exclusive, through dependent_feature inclusive 
                                 # onto master

---

이 특별한 경우에는 당신이 원래 작업했던 브랜치의 스쿼시 된 작업 만이 마스터에 들어갔다는 것을 "알고있는"것 같습니다 .

따라서 갈등이있을 때마다 변경 사항을 유지하여 행복하게 병합 할 수 있습니다. 이에 대한 옵션이 있습니다.

git merge -Xours master

자세한 내용은 https://git-scm.com/docs/git-rebase 를 참조하십시오.

---

I heartily disagree with the "mash every feature development down into a single commit" policy, but it's their call...

I'd keep the branches as-is, and create a mashed up commit just for publication, in a special branch. Being able to follow the development step by step is valuable, even if management doesn't believe in it. Mark the places of squashes by tags in the "real" branches, you could also add between-squash tags with messages pointing back to the real commits.

참고URL : https://stackoverflow.com/questions/22593087/merging-a-branch-of-a-branch-after-first-branch-is-squashed-when-merged-to-maste