假设我正在开发一个非常重要的功能分支，该功能分支遵循项目的“主”分支，并且具有相当多的活动。这通常会让我处于一种情况，为了保持理智，我必须落后于“头”，以便弄清楚如何使某些东西发挥作用。
这通常导致我的分支在主分支后面有几千个提交的情况 - 包含所有有趣的事情，例如相关模块被重构或类似。一旦我决定开始“追赶”，这让我有一个棘手的任务：单一的合并是不可能的，因为：
几乎不可能同时考虑所有“我的”更改乘以所有“主”更改。我尝试过这几次，我犯了很多错误，最终不得不退出。
由此产生的合并将是如此巨大，以至于隐藏在其中的所有魔法将成为文档的噩梦。
因此，我最终采用的方法是进行“分阶段”合并：不是直接与主人合并，而是选择性地与主人历史中的“有趣”点合并。这通常是关于可能具有“棘手”冲突的模块的提交。这样做的最大好处是我有可以推理和测试的实际可构建的中间点，因此使整个过程更易于管理。
然而，这种方法似乎有缺点......也就是说，如果合并中存在错误，我稍后才会注意到。我尝试使用git rebase -i -p来修复历史记录，但发现这似乎不是它背后的人们想象的那种用法。具体是
在合并之间插入更改似乎会导致rebase进程挽救或多或少复杂的冲突，并且
将常规提交压缩为合并提交似乎使新提交成为非合并，失去对合并提交的引用
现在我正在使用一些或多或少花哨的shell脚本来解决所有这些问题，但我真的很想知道我是否错过了一些可以帮助我处理这种情况的Git功能。到目前为止我能想到的最好的想法是使用rerere手动重做所有合并。
答案 0 :(得分：1)
我发现将主题分支重新定位到主分支证明是一个更容易/更易于管理的过程。
所以不是这个
A--B--C--D--E--F--M
\ /
X--Y--Z-
这样做
A--B--C--D--E--F
\
X'--Y'--Z'
答案 1 :(得分：1)
以更简单的方式，您不会git merge（或git cherry-pick）从主人到您的功能分支的任何更改。您总是git rebase您的功能分支在主人之后移动您的更改。
如果你经常使用git rebase并保持git rebase较小，那么live会更容易。
答案 2 :(得分：0)
git rebase是一个很棒的功能。
我不确定你是否尝试过你的情况，但我会做的是以下几点。
Checkout主分支确保其与原始数据保持同步。
检查您的功能分支
git rebase master
如果有任何冲突可以帮助您解决冲突，如果您遇到任何奇怪的事情，您可以随时做git rebase --abort
假设您遇到问题，修复该文件并执行git add <some file>然后git rebase --continue并且rebase将继续执行其工作。
请确保如果您的功能分支已被推送到远程并被其他人处理，请不要使用rebase。