在第一次合并后再次将git分支A合并到分支B

Question

我的情况如下。

              o---o---o issue-2 
             /         \
o---o---o---o---M---R---o develop
         \     /
          o---o---F issue-1

在第一个问题上做了一些工作。经过审查，它被合并为开发(commit )。不幸的是，很快就发现出现了一些严重的错误。为了解决其他问题，合并提交被恢复(提交R)。后来，其他问题(如问题2)也被合并到开发中。原始分支上的代码是固定的(提交F)。

问题是--如何将问题1合并到现在的发展中去？简单的合并将保留revert的效果，并且只应用尚未在开发分支(commit F)中的更改，而不是所有这些更改。

Answer 1

有几种选择：

1. 还原还原
   • 优点:这就是Git文件推荐的的方法，而且很容易做到
   • 缺点:让人们更难理解代码是如何随时间发展的(例如，git blame将显示还原的还原，而不是issue-1分支上的单个提交)。

​

1. 重新定位已恢复的分支并合并该
   • 优点：git blame和其他历史挖掘工具使理解代码历史变得更容易
   • 缺点:回顾历史可能有点混乱(为什么历史中有两组看似相同的提交？有人搞砸了基地吗？)

​

1. 编辑历史记录:重做开发分支以移除提交M和提交R
   • 优点:最干净的结果
   • 缺点：
     • 如果您的存储库是共享的，则会很危险，除非您的用户对Git很在行，并且您已经将计划传达给了每个人。
     • 很难做，因为Git没有一个简单的历史编辑工具：
       • 重基不会使编辑(或编辑出)合并变得容易，并且--preserve-merges选项不适用于交互式重基，因此您将最终将issue-2提交到develop中。
       • filter-branch很难使用

​

​

​

一般来说，我推荐的方法是恢复还原。我建议遵循以下详细步骤：

1. 看看原来的坏分支： git checkout issue-1
2. 在来自父分支的最新提交中合并： git merge --no-ff develop
3. 还原还原(其中R是还原提交的SHA1 ID )： git revert R
4. 修复树枝上的缺陷。(您已经在commit F中这样做了；为了其他人的考虑，我假设您需要做一个额外的修复。)
5. 试验试验试验
6. 切换回父分支： git checkout develop
7. 在修复的分支中合并： git merge --no-ff issue-1

生成的图形应该如下所示：

              o---o---o issue-2 
             /         \
o---o---o---o---M---R---o-------------o develop
         \     /         \           /
          o---o---F-------o---RR---F2 issue-1

这不是很漂亮，但人们应该能弄清楚到底发生了什么。