Git：如何将带有子分支的项目分支轻松地带入master？

Question

情况：具有主分支（绿线）和项目分支的存储库，该分支具有多个子分支。我们的规则是，进入Master的所有东西都通过拉取请求到达那里。

这种情况应该很常见，但不知怎的，我没有找到问题的答案：

如何将蓝色分支正确且轻松地带回绿色主分支？

我已经尝试过rebasing，前20次提交都很顺利，但此后，它要求我为每次后续提交手动解决冲突。我宁愿只需要一次解决整个事情，而不是微观项目中的每次提交。我不能将蓝色分支的“提交总数”重新定义为主分支吗？

一位同事建议创建一个新的（粉红色，不在图中）分支，从与蓝色微项目分支相同的绿色提交中分支，在我们分支的提交和最后一次蓝色提交之间创建差异 - 并应用差异到粉红色的分支。这对我来说似乎是可行的，但我想知道是否真的没有更多git风格的解决方案......？

Answer 1

由于多种原因，重新定位可能不是最好的解决方案。 （我会回到原因，以防你不相信。）

通常做的事情（因为是的，这是一种常见的情况）只是将“蓝色”分支合并为主。 “子分支”不会影响它，这不会影响它们，所以它就像任何其他合并一样简单。既然你提到PR，你必须使用某种托管的仓库（github？）;但无论你使用什么服务，它肯定只支持PR的简单旧合并......

现在为什么这比试图改变更好？

首先，您的分支/合并样式看起来很像gitflow。提交拓扑是gitflow的优点之一，那么为什么要通过rebase来破坏它呢？无论如何，你在蓝色分支上都有这些东西，这不是线性的。如果您尝试对其进行重新定义，则默认情况下会尝试将其全部转换为线性历史记录。你可以用--preserve-merges来阻止它，但是（1）它可能会搞乱合并，并且（2）它仍然会用一个新的，未经测试的提交替换每个提交（由于更改，它可能无法编译或运行可能不适用于新基地。）

此外，重新定价最多只会影响一个单一的参考。可能指向旧历史记录的任何标记或其他本地分支仍然指向旧历史记录，在历史记录图中创建难以修复的分割。你不能通过重新定位其他引用来修复它 - 由于提交时间戳，它们会进一步分裂。你必须弄清楚每个人在哪里（相对来说）在“新”图中的位置并移动它们。

然后是更大的问题：远程分支引用。他们仍然指向旧历史，并且移动它们会创建一个“上游rebase”条件，将打破每个现有克隆（除了你的）。听起来你希望这是你发布过程中的一个步骤;你真的想让每个人在每次发布后都经历一个恢复过程吗？

Rebasing有其用途，但这不是其中之一。