压缩过去的 git 提交答案

【问题标题】：Squashing past git commits压缩过去的 git 提交
【发布时间】：2021-04-30 12:46:58
【问题描述】：

我有一个 git 这样的历史记录：

* aab941c (HEAD -> master) Added ...
| * 2519b79 (participantQueue) Added ...
| * 39c4efb Created ...
|/  
* 87b0cf7 Import ...
| * 5569822 (settings) Modified ...
|/  
* ee67831 Added ...
* c07902f Added ...
* 7f5ab04 Added ...
* 82be721 Modified from `A` to `B`
* d86702b Modified from `A` to `B`
* 8cad721 Modified from `A` to `B`
* 5db240b Removing ...

我想将8cad721 压缩为82be721，最终得到：

* aab941c (HEAD -> master) Added ...
| * 2519b79 (participantQueue) Added ...
| * 39c4efb Created ...
|/  
* 87b0cf7 Import ...
| * 5569822 (settings) Modified ...
|/  
* ee67831 Added ...
* c07902f Added ...
* 7f5ab04 Added ...
* 82be721 Modified from `A` to `B` (82be721, d86702b squashed into here)
* 5db240b Removing ...

我已经尝试过git rebase -i 5db240bas suggested in other SO answers，将pick 替换为squash 用于d86702b 和82be721。结果如下：

* 4d91ea0 (HEAD -> master) Added ...
* 7040d3c Import ...
* f6c0fb5 Added ...
* 299c918 Added ...
* 58b209f Added ...
* e8b36f7 Modified from `A` to `B`
| * 2519b79 (participantQueue) Added default participant properties to unpaired queue export
| * 39c4efb Created ...
| * 87b0cf7 Import ...
| | * 5569822 (settings) Modified ...
| |/  
| * ee67831 Added ...
| * c07902f Added ...
| * 7f5ab04 Added ...
| * 82be721 Modified from `A` to `B`
| * d86702b Modified from `A` to `B`
| * 8cad721 Modified from `A` to `B`
|/  
* 5db240b Removing ...

我应该改用什么命令？

在 LeGEC 实施以下答案后，我有以下几点：

* 669164c (participantQueue) Added ...
* 5bc13a8 Created ...
| * 6abf940 (settings) Modified ...
| | * 3518be1 (HEAD -> master) Added ...
| |/  
|/|   
* | 2692632 Import ...
|/  
* 810389b Added ...
* 0c85217 Added ...
* 9284cff Added ...
* eee5eef Modified  from `A` to `B`
* 5db240b Removing ...

这让我愣了一秒，因为它看起来确实不同，但对master 的再次提交会像以前一样重新排序git log 输出的“主干”。

【问题讨论】：

标签： git rebase squash

【解决方案1】：

您还必须重写 participantQueue 和 settings 的历史记录，以便它们派生您为 master 创建的新提交。

你可以使用git rebase --onto ...：

# for 'settings' :
git checkout settings
# rewrite onto f6c0fb5 the history coming after ee67831 :
git rebase --onto f6c0fb5 ee67831

# for 'participantQueue' :
git checkout participantQueue
# rewrite onto 7040d3c the history coming after 87b0cf7 :
git rebase --onto 7040d3c 87b0cf7

如果您有更多的分支或标签要移动，最好使用全局重写工具，例如git filter-repo。

在您的情况下，只需移动两个额外的分支，这种更手动的方式也可以正常工作。

【讨论】：

为了澄清我应该按照问题中的说明运行git rebase，然后按照这些步骤操作？谢谢！
是的。一旦你重新定位了master，你就创建了新的提交，你可以在你的回购历史中发现它们。使用“settings 的新分支点”和“participantQueue 的新分支点”的提交哈希。
取消最后一条评论 - 意识到那里发生了什么

【解决方案2】：

git rebase 只重写一个分支的历史。这可能看起来很奇怪，但要理解的是rebase 不会“编辑”现有提交，甚至不会删除它们。它只创建新的提交，然后选择性地移动一个分支，以便它使用新的提交而不是旧的提交。（事实上，提交根本无法更改。这就是您的新提交具有新提交 ID 的原因；即在您的问题中，您说您想从

* 82be721 Modified from `A` to `B`
* d86702b Modified from `A` to `B`
* 8cad721 Modified from `A` to `B`
* 5db240b Removing ...

到

* 82be721 Modified from `A` to `B` (82be721, d86702b squashed into here)
* 5db240b Removing ...

这永远不会发生； 82be721 永远是 d86702b[1] 的子代。乍一看可能听起来很学术，但这正是您的其他分支没有“看到”更改的原因 - 因为它仍在查看提交 82be721。）

正如 LeGEC 的回答所指出的，在这种情况下，一种解决方案是重写每个分支的历史记录。这可行（但仍然不方便）只是因为您的历史记录相对简单。

另一种选择是使用git filter-repo[2]，它可以重写整个历史记录（即使该历史记录有许多分支、标签和其他引用，以及会阻碍rebase 的合并）。此选项合理的部分原因是您只是在压缩提交 - 可以将其处理为重新父级而不是变基。详细信息可以在filter-repo 文档中找到：https://github.com/newren/git-filter-repo

[1] 这有点夸大事实，因为我们使用的是 ID 前缀而不是完整的 ID。有可能 - 尽管极不可能 - 有两个 ID 以相同的 7 个十六进制数字开头的提交。即便如此，它们将是不同的对象，并且它们的 ID 的某些其他部分会有所不同。两次提交会计算出完全相同的 ID，真是不可思议。

[2] 这是一种可以使用filter-repo的表亲git filter-branch的操作；但一般不建议再使用。

【讨论】：