git 交互式 rebase squash 进入下一个提交

Question

在 Git 中，我可以使用交互式 rebase 重写历史记录，这非常棒，因为在我的功能分支中，当我探索不同的重构和完成它的方法时，我使用部分工作代码进行了大量提交。

我想在将分支变基或合并到 master 之前将很多提交压缩在一起。

一些按从第一个（顶部）到底部（最后一个）的顺序组成的提交

1. Initial commit on feature branch "Automatic coffee maker UI"
2. Add hot chocolate as product
3. Add tea as product. Products are now generic
4. Create in memory data store for adapter tests
5. Cry because I can't get entity framework to create a composite key. Integration tests broken.
6. Implemented composite key!!
7. All tests green and feature done!

假设我想保留提交 3、4 和 7。

使用 rebase 我想“压缩”提交

• 1 和 2 进入 3。
• 4 次入住
• 5 和 6 进入 7

理想情况下在我会做的交互式变基中

1. squash
2. squash
3. pick (contains the work of 1 & 2)
4. pick 
5. squash
6. squash
7. pick (contains the work of 5 & 6)

但这是倒退的，因为 squash 将提交与之前的提交合并。我不知道如何让它向前挤压。

我是不是很难，我是否应该接受它不起作用（我宁愿让它起作用），还是有办法做到这一点？

我正在调用这个命令

git checkout My-feature-branch
git rebase master -i

然后我正在编辑出现的提交列表，并尝试通过保存文件并编辑编辑器来完成它，这通常对我有用。

Answer 1

确实可以在交互式变基期间将提交压缩到以下提交中，并完全保留第二个提交的身份（包括作者、日期等）。

然而，该方法有些涉及，因此仍然感谢git rebase -i 的原生支持。

我将演示三个提交 aaaaaaa A、bbbbbbb B 和 ccccccc C，我们希望将 A 折叠成 B 并保留 B 的身份：（该方法很容易推广到更多提交）

• git rebase -i aaaaaaa^
• 修改编辑脚本在提交B后停止并退出编辑器：

  pick aaaaaaa A
  edit bbbbbbb B
  pick ccccccc C
  

• 当 rebase 在B 之后停止时，恢复最新的提交两次，然后继续：

  git revert HEAD
  git revert HEAD
  git rebase --continue
  

  因为还原还原会还原以前的状态，所以所有后续提交都将干净地应用。 B 和 Revert "B" 的顺序一起没有影响，但是这些提交中的第一个带有提交 B 的完整标识（实际上，在这个阶段它仍然是提交 B） .
  B 和 Revert "B" 可以压缩在一起形成一个无操作提交，该提交带有一个单独的rebase -i --keep-empty aaaaaaa^ 转发 B 的身份。这非常有用，建议防止虚假合并冲突，尤其是在更复杂的情况下。但是，我们将在此处跳过该步骤，并将提交保持在一起。
  现在重要的提交是 Revert "Revert "B""，它将携带最初由 B 所做的所有更改。
• 现在rebase -i aaaaaaa^ 再次移动A 越过B 和Revert "B"，同时将B 挤压到Revert "B" 和A 中：

  pick   bbbbbbb B
  squash b111111 Revert "B"
  squash a222222 A
  squash b333333 Revert "Revert "B""
  pick   c444444 C
  

  因为B 和Revert "B" 的顺序没有任何影响，所以您可以将任何提交移过它，同时只创建可以解决的合并冲突。
• 当 rebase 因合并冲突而停止时，将 git mergetool 与可自动解决琐碎冲突的工具一起使用，并让这些工具执行此操作。
• Rebase 将再次停止，让您编辑压缩提交的提交消息。根据您的喜好进行编辑。
• git rebase --continue 就完成了。

Answer 2

你想要的是：

1. pick
2. squash
3. fixup
4. pick
5. squash
6. squash
7. fixup

然后，当编辑器中出现新的组合提交时，删除所选提交的行并保留修复。生成的功能补丁应该包含该系列中最后一次提交的提交消息。

Answer 3

Vampire's answer 是对的，但我想提供不同的观点。我认为这是你让自己过度紧张的地方：你开始：

假设我想保留提交 3、4 和 7。

然后添加：

• 1 和 2 进入 3。
• 4 次入住
• 5 和 6 进入 7

但这意味着您希望保留 1、2、3、4、5、6 和 7 的（内容）所有 ...而不是作为单独提交。交互式 rebase squash 并不意味着“扔掉”，甚至也不是“扔掉提交消息”，它只是意味着“组合”。如果动词是“组合”或“融合”或“混合”或类似的，可能会更好。所以顺序（pick、squash、squash）意味着：保留所有三个，同时按顺序应用它们，然后从它们中做出一个大提交。

如前所述，一旦 Git 从它们中做出一个大提交，Git 会给你另一个机会将三个组合的提交消息编辑成一个大提交消息。

rebase 完成后，您还没有保留 任何 的原始提交。相反，您进行了 new 提交。你的新的第一次提交是如何从各个部分组装的并不重要，重要的是最终的来源是什么，以及你在一个大的提交信息中放了什么。

Answer 4

如果可行，您还需要对提交进行重新排序，以便待保留的提交位于待压缩的提交之前。

如果这不可行，因为你会遇到不想解决的冲突，那就去做吧

1. pick
2. squash
3. squash
4. pick 
5. pick
6. squash
7. squash

压缩完成后，您可以编辑提交消息以包含您希望最终提交包含的消息。易如反掌。 :-)

你甚至可以做到

1. pick
2. fixup
3. squash
4. pick 
5. pick
6. fixup
7. squash

然后我认为应该只启动一次提交消息编辑器，就像 fixup 一样，只需在不启动编辑器的情况下获取先前的提交消息。

当提交消息编辑器触发时，在 squash 上，您还会同时获得两个提交消息，即来自 to-be-squashed-into 和 to-be-squashed 提交的消息，因此您可以简单地删除您没有提交的提交消息不想保留。