Git：如何在分支合并后进行变基并保留合并提交的更改

Question

我的历史记录如下：

A - B - M
 \    /
    C 

A、B和M是主干，C在一个功能分支上。

我犯了两个错误：

1. 我没有意识到公司远程不接受合并提交，直到我提交之后才知道。
2. 除了解决冲突以外，我对合并提交做了很多修改。

我想进行变基，这样看起来就像 A - B - C - M，C-M 可能会被压缩在一起。

我只找到了一个与我的情况非常相似的问题，唯一的回答是“合并没问题”。

我承认我还不太熟悉变基语法，但我告诉 Git 进行任何组合，带或不带 -p 和/或 -i，它要么说没有要变基的内容（noop），要么说它无法工作。

似乎逻辑上的选择是跳到 C 上并使用 rebase -ip master，但它并没有完全按照我的预期做出反应。

- Martin S.

Answer 1

给定这个历史记录：

A - B - M
  \    /
    C 

如果您在M处软重置到B，并提交，那么您最终会得到A-B-M'，这似乎是您想要的：

git checkout M
git reset B
git commit

分支的内容保持不变，这些命令都不会改变它，只有 C 从历史记录中被消除，使它看起来像一个直线分支。

- janos

---

这将是 git checkout <branchname> 和 git reset --soft B，因为新的提交是从索引内容创建的，并影响当前分支（或分离的 HEAD）。 - torek

这个工作得很好，但我不知道为什么。重置为什么会这样？M消失了（我猜重置通常会这样），C在另一个分支上，但没有人关心他。因此，软重置基本上是使分支头指向该提交，并将差异作为要提交的更改。这很好知道，特别是它不关心分支或任何东西，只关心实际更改？ - Martin S.

当您执行软重置时，工作目录的内容不会更改。这非常关键。但是HEAD指向您指定的某个版本。此时，查看git diff，您将看到HEAD和您的内容之间的差异。当您提交时，自然地，这些差异成为新提交的内容。这很简单。是的，我认为可以说Git通常关心实际变化。这很有道理。 - janos