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

Question

假设我有三个提交

A --> B' --> B

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

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

如果我做 git rebase -i <commit-before-A>（或者如果 A 是第一次提交，那么 git rebase i --root），并且我选择 fixup 或 squash 提交B'，然后 B' 中的更改将被折叠到提交 A.

中

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

的中间工作

可能的解决方案：

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

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

  BRANCH DELETED
  B' --> B''
 /         \
A ---------> B
 BRANCH REMAINING

在提交 B 之前删除 B'。所以如果 B' 是为了切换机器，一旦我到达另一台机器，立即 git reset --soft，然后一旦我完成更改，提交 B，然后 [=41] =] 到远程，然后当我回到第一台机器时，使用 git pull --force。以这种方式“重写历史”是不幸的，并且经常使用 --force 似乎是一种危险的习惯。
drop 提交 B' 而不是 squash 或 fixup。 Git 似乎并没有非常明智地对待这一点，即使 A --> B' --> B 显然是快进更改，也需要合并解决方案。同样，您正在重写历史记录，--force 将被要求多次。
如果两台机器在同一个网络中，请改用文件共享。这对我来说似乎很恶心而且不灵活。
做其中之一并接受它；这是一个品味问题，你不可能取悦所有人。

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

相关帖子：

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?

Answer 1

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

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

当然，你必须强推分支，但这没关系，就像你说的，只有你在看它。在这种情况下，频繁的强推根本不是什么坏习惯。

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

Folding intermediate commits into later commits, not earlier

git

version-control

merge

github