Git - 如何在不压缩的情况下在 rebase 期间一步解决每个提交的冲突？

Question

  A---B---C topic
 /
D---G master

假设我在 git 中有上面的分支结构。如果我执行 git checkout topic 然后执行 git rebase master，根据我的经验，我将不得不一次解决提交 A、B 和 C 的冲突时间。我正在寻找一种方法来避免一次解决每个提交的冲突。在 rebase 期间压缩提交似乎是一个选项，但是是否可以将提交分开并且只需要为最近的“主题”提交执行冲突解决？基本上我想知道是否有可能将“主题” rebase 为“主”并且只需要解决“C”和“G”之间的冲突而不会将所有提交压缩为一个。也许我误解了什么，但在我看来，既然“C”是最近的提交，也是我感兴趣的提交，为什么我必须先解决“A”和“B”的冲突？我对 git pull --rebase 也特别感兴趣。

感谢您的帮助

Answer 1

Q1:如何一次性解决所有冲突？

A:你不能，因为在 rebase 过程中， rebase 工具无法预见会发生什么。 Rebase 确实是一个脚本化的链式 cherry-pick。您可以尝试先在启用 rerere 的一次性分支上 merge 更改，但是 1) 它需要的步骤不仅仅是解决每个冲突，而且 2) 不保证您无论如何都不必解决冲突。

Q2:也许有什么我误解了，但在我看来，既然“C”是最近的提交，也是我感兴趣的，为什么我必须解决“A”和“”的冲突B”第一？

答:是的。当你 rebase 时，无论如何你都不会更新 master，你只会将更改应用到较新的 master 版本。所以也许你会想要放弃 C 或 B 甚至 A。我认为 git 的革命性之处在于你必须停止从“最新代码”的角度思考，而是从暂存变化的角度来思考(在术语中推出和/或将新的开发/功能转移到生产/部署/交付中)。如果我能做到这一点，我很想引用 Doc Brown 的话。

所以是的，这可能意味着最好的解决方案是将所有提交压缩为一个。虽然 git rebase 背后的思路是，规范应该是没有冲突，并且冲突应该是可以预见的。不足为奇。因为冲突是同义词 which CHANGE and change should be a new version .如果在您添加新内容、重构或简单的错误修复时出现冲突，那么与其说 git kungfu/features 不佳，不如说它是架构不佳的症状。 YMMV.