将中间提交折叠为以后的提交，而不是更早的提交

如何解决将中间提交折叠为以后的提交，而不是更早的提交

假设我有三个提交

A --> B' --> B

Commit B' 表示中间状态，其中工作未完成且测试未通过。我可能已经提交 B' 以便从在我的家用机器上工作切换到我的工作机器上。

假设我在一个主题分支上，除了我之外没有人在看。但是所有三个提交都在远程，否则我无法使用 B' 将更改从一台机器传递到另一台机器。

如果我执行 git rebase -i <commit-before-A>（或者如果 A 是第一次提交，则 git rebase i --root），并且我选择 fixup 或 squash 提交 {{ 1}}，那么 B' 中的更改将被折叠到提交 B' 中。

但这不合适。我希望提交 A 和 A 来代表工作中的合理检查点，其中更改不会处于除了我之外没有人会理解的半途而废的状态。如果我 B 提交了 fixup，那么提交 B' 将留下 A 曾经拥有的半生不熟的更改。我希望提交 B' 被折叠到 B' 中，因为 B 代表提交 B' 的中间工作。

可能的解决方案：

1a。只需留下提交 B 并将其命名为“虚拟提交”，以便没有人注意它。它在我的主题分支上（即使它被推送到远程），所以谁在乎。

1b。如果我认为人们可能会看到我当前的主题分支并认为我不专业，请给 B' 自己的分支，我确定没有人关心，然后一旦 B' 准备好，提交并将其合并回原始分支，然后删除临时分支。所以它看起来像

B

2. 在我提交 BRANCH DELETED B' --> B'' / \ A ---------> B BRANCH REMAINING 之前去掉 B'。因此，如果 B 是为了切换机器，一旦我到达另一台机器，立即 B'，然后一旦我完成更改，提交 git reset --soft，然后 {{1 }} 到远程，然后当我回到第一台机器时，使用 B。很遗憾以这种方式“改写历史”，而且经常使用 git push --force 似乎是一种危险的习惯。
3. git pull --force 提交 --force 而不是 drop 或 B'。 Git 似乎并没有很明智地处理这个问题，即使 squash 显然是快进的更改，也需要合并解决方案。同样，您正在重写历史记录，并且会多次需要 fixup。
4. 如果两台机器在同一网络上，请改用文件共享。这在我看来很恶心，而且不灵活。
5. 执行其中一项并接受它；这是一个品味问题，你不可能取悦所有人。

请记住，这个问题的目的不是就品味问题展开争论；这是为了揭示我没有想到的利弊，或者让我接触到我没有想到的选择。

相关帖子：

• Is it possible to push a git stash to a remote repository?
• Git commit not finished but can't continue on that machine
• Should I use git stash to save ongoing changes of my project and push it to github to access in other computers?
• When to commit code?

解决方法

使用 git rebase -i 将 B 压缩为 B'。使用 squash 指令，以便您有机会编辑提交消息。

操作后，其他人（和你）只会看到一个新的提交B"，而B和B'很快就会被遗忘，你不用担心你“欺骗”并将 B 折叠成 B' 而不是反过来。

当然，您将不得不强制推动分支，但这没关系，正如您所说，您是唯一一个看着它的人​​。在这种情况下，经常用力推倒也不是什么坏习惯。