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

Question

我也在其他团队使用的功能分支上工作，他们有很多开发人员，因此从他们的末端开始就发生了很多提交。我上次提交的时间大约是10天前，我计划今天再次提交，但是我想确保从一开始就进行一次提交。

我知道我可以使用“ git rebase -i HEAD〜n”来实现这一点，但是我不知道用什么数字代替n，因为在这10天内，其他团队的末端提交了20多次以上的提交。如果您有连续的提交，但不适合我的情况，这是一个不错的选择。

尽管我从头到尾都完成了git提交的哈希码，所以除了git交互式重新基准化之外，我可以将git哈希码之一用作“ pick”，将另一个git hashcode用作“ squash”。这将使我免于经历大约20多个git commit的麻烦。

Answer 1

无需使用git rebase -i，就可以实现所需的结果。值得研究一下该方法，以便无论您是否使用git rebase选项，您都能真正[[了解 -i的功能。要完全达到您期望的结果，[[可能不明智

，尽管只有您和您的同事才能真正确定这一点。

您手动执行此操作的一种方法是通过哈希ID git checkout进行特定的提交，并创建一个指向该提交的新分支名称。您在此处选择的提交应该是有问题的两个提交之一。然后，您将要压缩的两个提交git cherry-pick -n压缩为一个新提交，并使用git commit提交结果。

现在，您将面临另外使用git cherry-pick将每个

后续

提交复制到新分支的问题。这并不困难，实际上，只要具有正确的哈希ID，它就应该自动运行。您只需要找到正确的哈希ID。完成后，您需要说服您的同事放弃现有的功能分支，并使用新的，重建的功能分支。这个新分支具有原始提交的副本，但是它们是新改进的，因为它们是基于您压缩后的原始两个提交而构建的。

[如果听起来有点令人费解，那么，它与您的git rebase -i所做的相同–除非您使用git rebase -i进行此操作，否则必须说服您的同事放弃名为feature/foo的分支]改用名称为

still feature/foo

的新分支，这有点令人困惑！

要使用git rebase -i来执行此操作而不必进行[[count

次提交（如HEAD~20中一样），请使用：

git log --decorate --oneline --graph

可以很好地了解您打算重新确定的提交。您将获得一列带有缩写哈希ID及其提交主题的提交列表，以及提交图的ASCII绘图。确保它在要复制的提交中没有分支合并模式（或者，如果有，则丢弃所有合并都可以）–在这种情况下，这意味着它只是一系列[C0 ]标记之前要复制和替换的提交。然后，使用counting：

*

其中

git rebase -i <hash>

是您

不会

复制或修改的第一次提交中的一个。请注意，即使您使用

old

分支名称来标识它，像这样的rebase的最终结果也是

新的一系列提交

。这就是为什么它通常是一个坏主意的原因：您将丢弃并替换的不仅是[[your提交，还包括其他人正在使用并仍在进行的其他提交。因此，they也必须切换到由their提交的这些新副本。

在这种情况下（具有很多其他人的更改的功能分支），我所做的就是始终通过hash将未推送的提交保持在其他提交的“顶部”。这将按服务器上的方式获取分支，并将本地提交放在最前面。请注意，这将更改我的本地分支历史记录，但不会更改远程分支历史记录，因此在推送时将<< no>需要使用git pull --rebase：）。然后，当您准备仅使用一次提交将工作发送到服务器时，只需查找顶级服务器提交的哈希并：：--force

这将保留已上演的本地提交中的所有更改。您只需要通过使用git reset --soft HASH_BEFORE_MY_FIRST_LOCAL_COMMIT，git commit -m "..."或您喜欢的工具指定新消息来提交它们即可。请注意，目前您不会收到每条消息，因此，如果需要它们，最好在进行git reset之前获取它们。

Answer 2