如何在不使用交互式 git 变基的情况下将两个 git 提交合并为一个提交？

Question

我正在开发一个也被其他团队使用的功能分支，他们有很多开发人员，所以从他们的末端发生了很多提交。 我最后一次提交是在大约 10 天前，我计划今天再次提交，但我想确保从我的最后一次提交。

我知道我可以使用“git rebase -i HEAD~n”来实现这一点，但我不知道用什么数字代替 n，因为在这 10 天内有来自其他团队的超过 20 次提交。这个命令很好如果您有连续提交，但它不适合我的场景。

虽然我已经完成了 git 提交的哈希码，但除了 git 交互式变基之外，还有什么方法可以使用我的 git 中的一个作为“.pick”。 它将为我省去 20 多次 git 提交的麻烦。

Answer 1

不使用git rebase -i也可以达到您想要的结果。 值得研究该方法，以便您真正了解git rebase的作用，无论您是否使用-i选项。

完全达到您想要的结果可能是不明智的，尽管只有您和您的同事才能真正确定这一点。

手动执行此操作的一种方法是git checkout出特定提交，并创建一个指向此提交的新分支名称。 您在此处选择的提交应该是有问题的两个提交之前的那个。

然后，您将git cherry-pick -n您想要压缩为一个新提交的两个提交，并使用git commit提交结果。

现在您面临另外使用git cherry-pick将每个后续提交复制到新分支的问题。 这并不是那么困难——事实上，只要给定正确的 hash ID，就应该自动完成所有 go。 您只需找到正确的 hash ID。

完成后，您需要说服您的同事放弃现有的功能分支并使用您重新构建的新功能分支。 这个新分支具有原始提交的副本，但它们是新的和改进的，因为它们是基于您对原始两个提交的压缩替换而构建的。

如果这听起来有点令人费解，那么它与您的git rebase -i所做的相同 - 除了当您使用git rebase -i执行此操作时，您必须说服您的同事放弃名为feature/foo的分支feature/foo支持名称仍然为feature/foo的新分支，这有点令人困惑！

---

要使用git rebase -i做到这一点，而不必计算提交（如在HEAD~20中），请使用：

git log --decorate --oneline --graph

好好看看你打算变基的提交。 您将获得带有缩写 hash ID 及其提交主题的提交的单行列表，以及提交图的 ASCII 图形。 确保它在您将复制的提交中没有分支和合并模式（或者如果有，则丢弃所有合并也没关系）——在这种情况下，这意味着它只是一系列*标记在您打算复制和替换的提交之前。 然后，而不是count ，使用：

git rebase -i <hash>

其中hash是您不会复制或修改的第一个提交。

请注意，像这样的变基的最终结果是一系列新的提交，即使您使用旧的分支名称来识别它。 这就是为什么这通常是一个坏主意：您将丢弃和替换的不仅仅是您的提交，还有其他人正在使用并且现在仍在进行的其他提交。 所以他们也必须切换到你对他们的提交所做的这些新副本。

Answer 2

在这种情况下（功能分支有很多其他人的更改），我所做的总是通过始终执行git pull --rebase将我未推送的提交保持在其他提交的“顶部”。 这将按原样获取服务器上的分支，并将我的本地提交放在首位。 请注意，这将更改我的本地分支历史记录，但不会更改远程分支历史记录，因此在推送时无需使用--force :)。

然后，当您准备好使用一个提交将您的工作发送到服务器时，您可以通过查找顶级服务器提交的 hash 来简单地压缩，并且：

git reset --soft HASH_BEFORE_MY_FIRST_LOCAL_COMMIT

这将使您本地提交的所有更改都已暂存。 您只需使用git commit -m "..." 、 git gui或您喜欢的工具指定新消息来提交它们。 请注意，此时您不会收到每条消息，因此如果您需要它们，最好在重置 git 之前获取它们。

这种方法的缺点：当您使用git pull --rebase git 将一个一个地应用您的每个本地提交。 如果发生冲突，您必须解决它并使用git rebase --continue 。 不利的一面是，根据本地提交的数量，您可能会多次发生冲突。