A---B---C topic
/
D---G master
说我在git中有上面的分支结构。如果我git checkout topic后面跟着git rebase master，那么根据我的经验，我将不得不一次解决提交A，B和C的冲突。我正在寻找一种方法来避免必须一次解决每个提交的冲突。在rebase期间压缩提交似乎是一个选项，但是是否可以将提交分开并且只需要对最近的“主题”提交执行冲突解决？基本上我想知道是否可以将“主题”重新定义为“主”并且只需解决“C”和“G”之间的冲突而不将所有提交压缩为一个。也许有一些我误解的东西，但在我看来，由于“C”是最近的提交和我感兴趣的提交，为什么我必须首先解决“A”和“B”的冲突？我也特别感兴趣为git pull --rebase做这件事。
感谢您的帮助
答案 0 :(得分：0)
Q1：如何一次解决所有冲突？
答：你不能，因为在变基期间，变基工具无法预见到底会发生什么。 Rebase真的是一个脚本链式樱桃挑选。您可以尝试在启用了rerere的情况下首先合并一次性分支上的更改但是1）它将需要更多的步骤，而不仅仅是解决每个冲突; 2）无论如何都无法保证您不必解决冲突。
Q2：也许有些事我误解了，但在我看来，由于“C”是最近的提交而我感兴趣的是，为什么我必须解决“A”和“ B“先？答：是的。在进行变基础时，无论如何都不会更新主数据，只会在较新的主版本上应用更改。所以也许你会想要放弃C或B甚至是A.我认为具有革命性的git的东西是你不得不停止思考“最新代码”，而是关于暂存变化（就术语而言）推出和/或将新的开发/特征移动到生产/部署/交付中。如果我能做到的话，我很想引用布朗博士给麦克弗利。
所以是的，它可能意味着最好的解决方案是将所有提交压缩为一个。 git rebase背后的一条线是，规范不应该是冲突，冲突应该是可预见的。不足为奇。因为冲突是同义词，其中CHANGE和change应该是新的version。如果在你添加新内容，重构或普通错误修复时出现冲突，那么它更像是糟糕的git kungfu / features的架构不佳的症状。 YMMV。