Git:定期合并/重基长寿命的bugfix分支以掌握。

Question

上下文

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

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

• 长生枝
• 两个分支：
  • 硕士(负责持续发展的分支)
  • 1.0 (只用于修补程序的分支，以维护稳定的版本)

​

• 这两家分行都定期推出公开回购。
• 有时，正在进行的开发和错误修复会影响相同文件中的相同行，因此在合并/重基/等时会发生冲突。

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

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

我们可以如下所示(commit 5'是来自1.0分支的提交5的一个重要选择)：

-1-2-3-5‘-7--(主人)\4-5-6-- (1.0)

目标

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

在这样做时，我们的需要是：

• 不能更改1.0分支(从主到1.0分支不提交)
• 主人需要保持与原版/母版的兼容，以便我们可以推送到远程回购。这基本上意味着避免重写大师的历史(除非有一种神奇的方法来推动这一点，我们不知道！)
• 我们不希望丢失提交历史记录:我们需要能够查看来自1.0分支的提交是否已应用于主分支。
• 我们不想手动解决以前的樱桃选择引起的冲突，我认为git应该能够自己解决这个问题(如手册页所示)。
• 在未来，我们将再次达到类似的情况，并且需要以同样的方式解决它，但是不需要记住我们已经解决了一次的提交4和6的决议。

因此，我们的目标是：

-1-2-3-5‘-7-4’

我们尝试过的

• 使用1.0分支的副本，并将其重定向到主服务器：
  • 似乎很管用
  • 但是，如果我们在将来再次执行相同的操作，我们必须检查新的和旧的提交。

​

• 将母版重定向到1.0分支上
  • 在当地一家回购公司工作
  • 但是不能被推到远程，因为这将重写原版/母版。

​

• 将1.0分支合并到主中
  • 所有冲突解决方案都以一次提交结束，因此历史记录没有显示以前提交所需的实际修改。
  • 理想情况下，我们需要一个"git合并-交互式“，类似于"git rebase --交互式”：合并分支，但交互地选择包含或不包含的提交。

​

问题是

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

你会怎么做？

谢谢!

Answer 1

所有的选择都有起起落落，做出明智的决定将在很大程度上依赖于阅读你可能找到的一切。最大的问题是，git实际上并不是从根本上设计的，而是着眼于维护多个“长期”分支，在那里您可能需要在分支上保持多年的更改。因此，当分支之间的代码库发生显著变化时，您可能最终会遇到合并问题。

如果您阅读了大多数工作流文档，那么您反复阅读的最大的事情之一就是：“向bug修复分支应用补丁并向上合并它们”，永远不会相反。

下面是我为我们的Net-SNMP项目提出的解决方案。我编写了一个Git WorkFlow [在Net中]页面，您可能会读到，因为它包含圆圈和箭头，试图解释很多错误修复分支是如何工作的。

然而，合并的缺点是历史变得非常非线性.这使得阅读"git日志“，无论你尝试了多少选项，扔给它，有点混乱。

我们的一位开发人员善意地指出，我们需要强制使用“git合并日志”，这至少对历史有所帮助。

祝好运!