如何从git的多分支合并中删除分支？

我刚刚将三个不同的分支合并为一个功能集的一部分，并推送结果，使存储库树当前看起来如下所示：

--- A --- A1 --- A2 --- A3 -- | \ + --- B1 --- B2 --- B3 --- B4- | \ + --- C1 --- C2 --- C3 ---------C4 + --- B1 --- B2 --- B3 --- B4 --- B5 | / --- A --- A1 --- A2 --- A3 -- | \ + --- C1 --- C2 --- C3 --- C4 --- C5 恢复C4（并提交该恢复），然后将A3合并到刚才创建的C5中

--- A --- A1 --- A2 --- A3 -----------------------------
    |                         \                          \
    + --- B1 --- B2 --- B3 --- B4-                        \
    |                              \                       \
    + --- C1 --- C2 --- C3 ---------C4--- C5(reverts C4) -- C6

最终，B4包含B3+A3，C6包含C3+A3

---

我想你也可以通过重定基调来完成这一切，但我更喜欢在我做了一些乱七八糟的事情后留下我的足迹，这样我就可以看到我的错误以及我为纠正它所做的事情。Rebase撤销历史记录，这让我感到不安。

我来自一个阵营，它喜欢重做糟糕的事情，只要它没有被推，留下一个不太详细的历史记录，我通常这样做：

# go back to commit C3
git checkout C3

# redo the merge with only A
git merge branch_A

# make sure you've gotten the desired alteration
# git diff --stat branch_C
# git diff branch

# switch your C branch over to your redone version
git checkout -B branch_C

# otherwise if you change your mind, just go back to C4
# git checkout branch_C

Edit:Comment#4完全正确，因为之前的版本没有任何结果。此编辑更改了先前正在合并的

B4

行的

git merge

。初始签出中的

--detach

选项也被删除，因为如果参数

C3

不是分支名称，则该选项是多余的。

假设您尚未与其他任何人共享此存储库，您可以尝试

其中B3和A3实际上是提交SHA本身

不过，我强烈建议在执行此命令之前备份存储库，以确保安全

# checkout before merge
git checkout C3
# make merge we want
git merge A3
# rebase any work on top of the new merge
git rebase --onto HEAD C4 branch_C
# use fixed version as branch_C
git branch -f branch_C HEAD
# aha! now you on the fixed branch_C
git checkout branch_C

---

我想，在“坏”合并之后，您没有进一步分支C&B。

那么，是否只需要恢复到

B3

并提交撤销

B4

提交（如果需要的话）？Revert并不完全“撤销”提交。您不会“恢复”到以前的版本。恢复提交将创建与指定提交相反的新提交，从而在时间上向前移动时收回更改。所以：要撤消B4提交，您需要恢复B4，然后在该分支上提交它。请参阅

git reset

使您在时间上向后移动，有点像rebase，但我更喜欢还原并保留错误和修复的跟踪记录。还原合并是。。。有趣。阅读

-m

选项下的手册页，包括后续合并不会恢复更改的警告。没有理由期望C3上会有分支。事实上，一切都表明了另一种情况：在图中，C3表示提交。所以你使用

--detach

是一种不必要的干扰。这是真的。但是在我的建议中，我使用的

--detach

更多的是关于明确性，我认为上面使用它有以下优点：1。它暗示了使用分离状态的概念，这与在分支上使用

git checkout

类似，但略有不同。2.如果我没有按照这些思路明确地说些什么，那么不太熟悉的人可能会认为指定分支名称是同义词，然后在移动它之后就会陷入混乱。（尽管经过再三考虑，这些人可能不会创建任意分支。）重点是，虽然知道这是一件好事，但这并不是一个展示它的含义或为什么需要使用它的好方法，因为你使用它的情况是不可行的。如果我错了，请纠正我，但是您的演练实际上不会产生一个代码库，它是

A3

和

C3

的合并，没有

B3

代码。我想要的是

C

分支的负责人是

A3

和

C3

，除非是这样，否则我必须否决这个答案，因为它实际上没有回答问题。你为什么不将所有分支硬重设为第三状态，并与来自B和C的A合并？你的意思是说，在这次失败合并之后，你已经做了一些额外的工作，并且想在保留以下工作的同时修复这次合并吗？@the.malkolm-在某些情况下，我认为可能是这样的，一位开发人员询问如何删除一些不会发布的功能代码。

git rebase --onto B3 A3 C

# checkout before merge
git checkout C3
# make merge we want
git merge A3
# rebase any work on top of the new merge
git rebase --onto HEAD C4 branch_C
# use fixed version as branch_C
git branch -f branch_C HEAD
# aha! now you on the fixed branch_C
git checkout branch_C