A---B---C topic
/
D---G master
git checkout topic，然后再运行git rebase master，根据我的经验，我需要一次解决一个提交的A、B和C的冲突。我想找到一种方法，避免每次都要解决一个提交的冲突。在rebase期间压缩提交似乎是一个选择，但是否可能保持提交单独，并且只需要针对最新的“topic”提交执行冲突解决？基本上，我想知道是否可能将“topic”合并到“master”，只需在“C”和“G”之间解决冲突，而无需将所有提交压缩为一个提交。也许我有什么误解，但在我看来，既然“C”是最新的提交并且我感兴趣的提交，为什么我必须首先解决“A”和“B”的冲突呢？我特别关注git pull --rebase的这个问题。谢谢任何帮助。问题1：如何一次性解决所有冲突？
答案：你不能这样做，因为在rebase过程中，rebase工具无法预知接下来会发生什么。Rebase实际上是一个脚本化的连锁挑选操作。你可以尝试先在一个可丢弃的分支上启用rerere功能合并更改，但是这将需要比仅解决每个冲突更多的步骤，并且不能保证你不必解决冲突。
问题2：也许我有什么误解，但我觉得既然“C”是最新的提交，而且我感兴趣，为什么我要先解决“A”和“B”的冲突呢？
答案：是的，确实如此。在rebase过程中，您不会更新主分支，您只会将更改应用于较新的主分支版本。因此，您可能想要放弃C或B甚至A。我认为Git的革命之处在于，你必须停止以“最新代码”为思考方式，而是以分阶段的变更（在推出和/或将新的开发/特性移入生产/部署/交付方面）为思考方式。如果我能够完全引用Doc Brown对McFly的话，我会很想这样做。
是的，这可能意味着最好的解决方案是将所有提交压缩为一个。Git rebase 的思路是规范应该是没有冲突的，冲突应该是可以预见的，而不是惊喜。因为冲突等同于变更，变更应该是一个新的版本。如果在添加新内容、重构或纯粹的错误修复时出现冲突，那么这更多是架构不良的症状，而不是 Git 技能/功能不足。你的情况可能有所不同。
git pull --rebase（这是我被鼓励使用的方法），并且必须逐个解决过去提交的冲突，其代码已被覆盖并且不再需要。虽然我相当确定我没有使用最聪明的工作流程，但我将尝试不进行太多无意义的本地提交。 - Multibran
git rerere。另请参阅http://git-scm.com/blog/2010/03/08/rerere.html。 - torek