>上下文
我们使用多个具有相同工作流程的 git 存储库，涉及两个分支，并且想知道如何最好地将提交从一个分支"同步"到另一个。
简而言之，我们的 git 存储库包含：
- 长寿树枝
- 两个分支：
- 硕士(持续开发的分支(
- 1.0(仅用于错误修复的分支，以维护稳定版本(
- 这两个分支都定期推送到公共回购
- 有时，正在进行的开发和错误修复会影响相同文件中的相同行，因此在合并/变基/等时会发生冲突。
我们也有一些不太常见的情况：
- 不寻常的比例：错误修复的差异(在 1.0 分支上(比正在进行的开发(在主分支上(的差异大得多。
- 有时，来自 1.0 分支的提交会被精心挑选到主分支(稳定版本和开发都需要"紧急"错误修复(
我们可以这样说明(提交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 上：
- 似乎有效
- 但是，如果我们将来再次执行相同的操作，则必须检查新提交和旧提交
- 将母版重定基数到 1.0 分支
- 在本地存储库中工作
- 但不能推送到远程，因为这会重写源/主
- 将 1.0 分支合并到主分支中
- 所有冲突解决最终都以一次提交结束，因此历史记录不会显示以前提交所需的实际修改
- 理想情况下，我们需要一个"git merge --interactive"，类似于"git rebase --interactive"：合并分支，但交互式地选择要包含或不包含的提交，随着我们的进行。
问题
在我们看来，这可能是 git 的一个非常典型的用例，或者对于任何在公共 git 存储库中维护和开发软件的人来说
。你会怎么做？
谢谢！
所有选择都有起伏，做出明智的决定将在很大程度上依赖于阅读您可能找到的所有内容。 最大的问题是 git 并不是真正从头开始设计的，没有任何着眼于维护多个"长期"分支，您可能需要在分支上维护多年的更改。 因此，当分支之间的代码库发生重大更改时，您最终可能会遇到合并问题。
如果您阅读了大多数工作流文档，那么您反复阅读的最重要的事情之一就是："将补丁应用于错误修复分支并将它们向上合并"，永远不会相反。
这是我为我们的Net-SNMP项目提出的解决方案。 我写了一个 Git WorkFlow [在 Net-SNMP 中] 页面，你可能会阅读，因为它包含圆圈和箭头，试图解释事情是如何与许多错误修复分支一起工作的。
但是，合并的缺点是历史变得非常非线性。 这使得阅读"git log"，无论你尝试和扔多少选项，都有点令人困惑。
我们的一位开发人员善意地指出，我们需要强制使用"git merge --log"，这至少对历史记录有所帮助。
祝你好运！