Git:定期 merge/重新设置长期存在的错误修复分支以掌握

Question

上下文

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

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

• 长寿枝
• 两个分支:
  • master(持续开发分支)
  • 1.0(仅修复错误的分支，以保持稳定的版本)
• 两个分支都被定期推送到公共(public)仓库
• 有时，正在进行的开发和错误修复会影响相同文件中的相同行，因此在 merge/ rebase 等时会发生冲突。

我们还有一些不太常见的情况:

• 异常比率:错误修复的差异(在 1.0 分支上)比正在进行的开发(在 master 分支上)的差异大得多。
• 有时，来自 1.0 分支的提交被精心挑选到 master 分支(稳定版本和开发都需要“紧急”错误修复)

我们可以如下说明这一点(提交 5' 是从 1.0 分支中精选的提交 5):

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

目标

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

在做这件事的时候，我们的需求是:

• 不得更改 1.0 分支(master 没有提交到 1.0 分支)
• Master 需要与 origin/master 保持兼容，这样我们才能推送到远程仓库。这基本上意味着避免重写 master 的历史记录(除非有一种我们不知道的神奇方法来 push 它!)
• 我们不想丢失提交历史记录:我们需要能够查看来自 1.0 分支的提交是否已应用到 master 分支。
• 我们宁愿不必手动解决由以前的 cherry-picks 引起的冲突，我认为 git 应该能够自行解决这个问题(如手册页中所示)。
• 将来，我们会再次遇到类似的情况，需要以相同的方式解决它，但不想记住我们已经排序的提交 4 和 6 使用什么解决方案出去一次。

因此，我们的目标是:

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

我们尝试了什么

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

问题

在我们看来，这可能是 git 的一个非常典型的用例，或者对于任何在公共(public) git 存储库中维护和开发软件的人来说，无论如何。

你会怎么做？

谢谢!

Answer 1

所有选择都有起伏，做出明智的决定在很大程度上取决于阅读您可能找到的所有内容。最大的问题是 git 并不是真正从头开始设计的，着眼于维护多个“长期”分支，您可能需要在分支上维护多年的更改。因此，当分支之间的代码库发生显着变化时，您最终可能会遇到 merge 问题。

如果您阅读了大部分工作流文档，那么您反复阅读的最重要的内容之一就是:“将补丁应用到错误修复分支并将它们向上 merge ”，永远不要相反。

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

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

我们的一位开发人员友善地指出，我们需要强制使用“git merge --log”，这至少对历史记录有一点帮助。

祝你好运!