Git：定期合并/重组长期生活的bugfix分支到master

Question

上下文

我们使用几个具有相同工作流程的git存储库，涉及两个分支，并且想知道如何最好地“从一个”提交“同步”提交。

简单地说，我们的git存储库包含：

• 长寿树枝
• 两个分支：
  • master（正在进行的开发分支）
  • 1.0（仅限错误修正分支，以维护稳定版本）
• 这两个分支都经常被推送到公共仓库
• 有时，正在进行的开发和错误修正会影响同一文件中的相同行，因此在合并/重新定位/等时会发生冲突。

我们也有一些不太常见的情况：

• 不寻常的比例：错误修正的差异（在1.0分支上）远远大于正在进行的开发（在主分支上）。
• 有时，来自1.0分支的提交被挑选到主分支（稳定版本和开发都需要“紧急”错误修正）

我们可以将其说明如下（commit 5'是来自1.0分支的提交5的选择）：

-1--2-3--5'--7-- (master)
     \
      4--5---6-- (1.0)

目标

我们经常需要确保1.0分支上的所有错误修正都在主分支上可用。

这样做时，我们的需求是：

• 不得更改1.0分支（没有来自master的提交转到1.0分支）
• Master需要与origin / master保持兼容，以便我们可以推送到远程仓库。这基本上意味着避免重写大师的历史（除非有一种神奇的方法来推动我们不知道的事情！）
• 我们不想丢失提交历史记录：我们需要能够看到1.0分支的提交是否已应用于主分支。
• 我们宁愿不必手动解决之前樱桃选择引起的冲突，我认为git应该能够自行解决这个问题（如手册页所示）。
• 将来，我们会再次达到类似的情况，并且需要以相同的方式解决它，但不想记住我们已经排序的提交4和6使用的解决方案一次。

因此，我们的目标是：

-1--2-3--5'--7--4'--6'-- (master)
     \
      4--5---6-- (1.0)

我们尝试了什么

• 使用1.0分支的副本，并将其重新定位到master上：
  • 似乎工作
  • 但如果我们将来再次进行相同的操作，我们必须审核新提交和旧提交
• 将master重新绑定到1.0分支上
  • 在本地仓库工作
  • 但是无法推送到远程，因为这将重写origin / master
• 将1.0分支合并为主分支
  • 所有冲突解决都会在一次提交中结束，因此历史记录不会显示之前提交的实际修改
  • 理想情况下，我们需要一个“git merge --interactive”，类似于“git rebase --interactive”：合并分支但交互式选择要包含或不包含的提交，我们一起去

问题

在我们看来，无论如何，这可能是git或任何在公共git仓库中维护和开发软件的人的典型用例。

你会怎么做？

谢谢！

Answer 1

所有选择都有起伏不定，做出明智的决定将严重依赖于阅读您可能找到的所有内容。最大的问题是git并非真正从头开始设计，而是专注于维护多个“长期”分支机构，您可能需要在分支机构中维护多年的变更。因此，当分支机构之间的代码库发生重大变化时，您最终可能会遇到合并问题。

如果您阅读了大多数工作流文档，那么您反复阅读的最重要的事情之一是：“将修补程序应用于错误修复分支并将它们向上合并”，从来没有反过来。

这就是我提出的解决方案，我为Net-SNMP项目提出了解决方案。我写了一个你可能会阅读的Git WorkFlow [in Net-SNMP]页面，因为它包含了圆圈和箭头，试图解释一些错误修复分支的工作原理。

然而，合并的缺点是历史变得非常非线性。这使得阅读“git log”，无论你尝试多少选项并抛出它，都会让人感到困惑。

我们的一位开发人员慷慨地指出，我们需要强制使用'git merge --log'，这至少会对历史有所帮助。

祝你好运！