这是我通常在工作中处理的工作流程。
git checkout -b feature_branch
# Do some development
git add .
git commit
git push origin feature_branch
至此，功能分支已经可以从我的同事那里进行审查，但是我想继续开发依赖于
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之外，其他一切都很酷。当我尝试将依赖分支重新建立到master或尝试将master合并到master中时，git被重新编写/压缩的历史混淆了，并且基本上将depedendent_branch中的每个更改标记为冲突。这是一个PITA，基本上需要进行重新执行或取消冲突dependent_branch中的所有更改。有解决办法吗？有时，我会手动创建一个补丁并将其应用到master的新分支上，但是如果与此产生任何实际冲突，则修复起来会更糟。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.
有任何想法吗？我知道发生这种情况是由于壁球期间的重写历史记录，但这是我不能更改的要求。什么是最好的解决方案/解决方法？我能做些魔术吗？还是有更快的方法来完成与手动创建差异有关的所有步骤？
最佳答案
关于发生这种情况的一些信息:
在将功能分支合并到其中之后，我将O设为“原始主”，并将FB设为“新主”:
说feature_branch看起来像:
O - A - B - C
dependent_feature除此之外还有一些额外的提交:O - A - B - C - D - E - F
您将原始要素分支合并到master并将其压缩，从而得到:
O - FB
现在，当您尝试重新建立从属分支的基础时，git将尝试找出这些分支之间的共同祖先。虽然它最初是，但最初是，但是如果您不压缩提交，则git会找到
C作为共同祖先。结果，git试图重播中已经包含的的O，A和B，您将遇到很多冲突。因此，您不能真正依靠典型的rebase命令，而必须通过提供
C参数使其更加明确:git rebase --onto master HEAD~3 # instruct git to replay only the last
# 3 commits, D E and F, onto master.
根据分支的需要修改
FB参数，您不必处理任何多余的冲突解决方案。一些替代语法，如果您不喜欢指定范围并且尚未删除原始功能分支:
git rebase --onto master feature_branch dependent_feature
# replay all commits, starting at feature_branch
# exclusive, through dependent_feature inclusive
# onto master
关于git - merge 到母版时，在压缩第一个分支后 merge 分支的分支，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/22593087/