GIT:如果我在一个分支上压缩所有提交，然后将其合并到master上，那么之前从master进行的合并会发生什么？

Question

我有一个我已经工作了很长时间的分支，定期将主分支合并到其中。因此，此分支的历史记录也包含来自主分支的所有提交。我想在分支上将所有的提交都压缩到一个提交中，然后将这个分支合并回master。这会影响master上的提交历史记录吗？

Answer 1

总体思路是保留VCS中的历史记录。因此，如果您只是简单地添加另一个提交，则不会有任何结果。

但是在git中，如果你愿意，你可以重写一段历史。如果您已经发布了原始历史，而其他一些人依赖于它(即，他们在您的基础上创建了自己的提交)，那么这样的历史重写将给他们带来一些痛苦-他们将不得不在新历史的基础上重新建立他们的更改。

但如果历史记录仍未发布，或者您可以与您的同行协商，并且他们同意更改，那么您可以自由地采取行动。

更新：由于修改的分支与主分支有一些合并，我认为提交的初始图片看起来有点像这样：

 A ---> B ---> C ---> D ---> E --> F (master)
  \             \            \
    --> BA --> BM1 -> BB --> BM2 --> BC (branch)

其中，<letter>是master提交，B<letter>是“自己的”branch提交，BM<number>是master到branch的合并。

现在，您想要挤压分支中的提交，这样最终的图片将如下所示：

 A ---> B ---> C ---> D ---> E --> F (master)
  \                          \
    -----------------------> BZ (branch)

并且BZ提交的文件树与BC文件树完全相同。

关于合并提交，git rebase的默认行为是展平历史记录，删除合并记录，但重播由相应合并引入的更改。因此，如果您简单地发出git checkout branch; git rebase -i A并将提交压缩到单个提交，您将收到如下内容：

 A ---> B ---> C ---> D ---> E --> F (master)
  \                          
    -----------------------> BZ (branch)

(注意E和BZ之间缺少的链接)

所以我们需要在rebasing上施展一些魔法。要简化此任务，请创建标记tagA标记提交A、tagE标记提交E和tagBC BC。当工作完成后，可以安全地删除这些标记。

现在我们可以继续了。发出git rebase -i tagA。您将看到一个类似如下的列表：

pick 515de5f commit BA
pick 1c749c6 commit B
pick 4490402 commit C
pick 4da9e96 commit BB
pick 6d9dc01 commit D
pick 7e469d6 commit E
pick 861038b commit BC

在列表的顶部插入假合并，并用fixups替换所有的picks，这样你就会得到类似这样的结果：

exec git merge -s ours -m "The resulting commit" tagE
fixup 515de5f commit BA
fixup 1c749c6 commit B
fixup 4490402 commit C
fixup 4da9e96 commit BB
fixup 6d9dc01 commit D
fixup 7e469d6 commit E
fixup 861038b commit BC

现在保存文件并退出。在应用序列之后，您将获得所需的提交结构。测试BZ (重写的branch的头部)是否与前一个(标记为tagBC)相同，它应该是相同的，并且您已经完成了。

适用于git rebase的所有标准实践:如果出现问题，您始终可以使用git rebase --abort重新启动。如果发生一些冲突，您需要解决它们，并继续使用git rebase --continue，依此类推。

Answer 2

你绝对可以这么做。您可以对您的分支上的所有提交进行压缩。执行git pull --rebase origin master以确保一切正常。解决所有冲突，然后合并到master。

注意:通常情况下，当你在一个分支上工作时，比如branch_a based of off比如master，建议你在每次rebase on merge时关闭master而不是merge master。