合并不带壁球与带壁球选项的提交答案

【问题标题】：Merge commit without squash vs with squash option合并不带壁球与带壁球选项的提交
【发布时间】：2018-04-15 20:09:24
【问题描述】：

在日常工作中，我使用SmartGit 作为选择的客户。然而，我的团队成员坚持使用 git 本机、非商业 GUI。我们发现我们的合并提交看起来有些不同。

这些是SmartGit 在请求合并分支时提供的选项：

在下图中，您可以看到我的示例 SmartGit 图形输出，其中包含：

单master分支
使用merge commit 选项将一个分支合并到master
一个分支与simple commit 选项合并

其中一个分支 (with_merge_branch) 正在通过 line 将分支与 master 连接来可视化合并操作。第二个 (normal_commit_branch) 没有。

问题是，如何在本机 git 命令中强制执行这两种行为？ IE。这两个提交有什么区别？

【问题讨论】：

In git, what is the difference between merge --squash and rebase?的可能重复
我从来没有使用过它，但是带有 squash 选项的 git merge 删除了存在第二个父分支的任何痕迹。如果您点击重复链接，您会看到一些示例，说明您可能想要使用它的原因。不带 squash 选项的合并是 git merge 的默认行为。

标签： git merge version-control smartgit

【解决方案1】：

merge commits 只是commit，但不同的是他们有不止一个父母。如您所知，提交可能有也可能没有父提交，实际上merge commit 是有多个parent commit 的commit。

【讨论】：

【解决方案2】：

两种合并的区别只是提交历史记录不同（正如您在图表中显示的日志）。

让我们用图表来说明。假设合并前的提交历史如下：

A---B---C---D  master
     \
      E---F---G  develop

合并提交（多父）：

使用的命令是git merge branchname。这是合并两个分支的默认方式。

当您在 SmartGit (git merge develop) 中通过 Merge commit 将 develop 分支合并到 master 分支时，提交历史将为：

A---B---C---D---M  master
     \         /
      E---F---G    develop

简单提交（一个父级，“squash”）：

它使用--squash选项合并两个分支，使用的命令是git merge branchname --squash。

--squash

生成工作树和索引状态，就好像发生了真正的合并（合并信息除外），但实际上并不进行提交、移动 HEAD 或记录 $GIT_DIR/MERGE_HEAD（导致下一个 git commit 命令来创建一个合并提交）。这使您可以在当前分支之上创建一个提交，其效果是与合并另一个分支相同（如果是章鱼则更多）。

当您在 SmartGit (git merge develop --squash) 中通过 simple commit 将 develop 分支合并到 master 分支时，它会将 develop 分支中的更改作为新分支获取到 master 分支普通提交（好像发生了真正的合并），提交历史将是：

A---B---C---D---M  master
     \                 
      E---F---G    develop

【讨论】：

只是为了补充@Marina 的精彩回答，如果一旦使用-squash 提交到父分支，内部合并请求系统将无法检测到合并分支。因此，一方面您的历史记录更清晰，但合并来源的检测有点困难
我认为，需要发出警告：Squash 提交丢失历史！ 如果合并，git 将知道导致功能集成的所有中间步骤，并且git bisect 将能够确定任何回归到这些中间步骤之一。如果你 squash，你的特性分支变成了 git 的黑盒子，git bisect 将只能指出包含整个特性开发的一个 squash 提交。最好全心全意拥抱git的DAG历史模型，它会为你省去很多麻烦。