如何正确使用 git merge --squash答案

【问题标题】：How to properly use git merge --squash如何正确使用 git merge --squash
【发布时间】：2016-07-26 01:49:19
【问题描述】：

我对 git 还很陌生，只能自己工作，所以我没有使用它可以做的许多功能，但我遇到了一个过程，要么我想错了，要么做错了什么。

我有一个带有 1 个提交 (init) 的主分支。

我有一个包含 180 次提交的开发分支。

今天我终于准备好将develop分支合并到master中，我做了一些阅读并发现了关于squash的信息。这似乎很有用，因为我不会使用与开发分支中相同的 WIP 提交污染主分支。

所以我跑了

git checkout master
git merge --squash develop
git commit

从这里一切看起来都如我所料，master 有 2 个提交，develop 仍然有 180 个。我现在在脑海中再次检查 develop 并继续工作。我推到bitbucket 并查看了我的项目以查看此合并并注意到以下内容：

1 commit(s) on master and not on develop
179 commit(s) on develop and not on master

这只是预期的行为，我应该忽略它还是我做错了什么。

【问题讨论】：

【解决方案1】：

当您在 Git 中压缩提交时，它会将它们合并为一个提交。但是，当您想将多个提交的更改合并到一个新的提交中时，您可以合并。

就您而言，我相信您打算做的是没有“快进”的合并。通过这种合并，您最终将在 master 中进行 2 次提交（初始和合并），在 dev 中进行 180 次提交。

代码将是（在 dev 中最后一次提交之后）：

git checkout master
git merge dev --no-ff

【讨论】：

这听起来确实像我想要的，但我只是试了一下，结果都是 180 次提交。
如果合并是快进的，就会发生这种情况。使用 no-fastforward，180 个提交保留在 dev 中，而在 master 中，您有一个提交，所有更改都被压缩。您是否尝试了确切的代码？
是的，确切的代码在 master 中产生了 181 次提交，在开发中产生了 180 次提交。验证人git rev-list --count HEAD
合并创建一个新的提交，它基于所有父级的新树。它不仅仅是“将几个提交组合成一个新的提交”。它使用历史中的一个新（附加）节点来执行此操作（因此，如果您从 n 次提交开始，那么您现在有 n+1 用于合并）。合并是将来自其他分支的补丁应用到当前分支+树。并跟踪这是如何发生的。跟踪（而不是挤压或挑选）的好处在于，当 Git 更清楚地知道真正发生了什么变化时，合并会变得更加简单。但是合并也很难理解。让您的合并发挥作用。

【解决方案2】：

这是意料之中的，因为 git 会将您的所有提交合并为一个提交，与您的开发分支中的提交相比，这将是一个不同的提交。将提交视为一组更改的容器，如果您更改内容，您将拥有不同的内容。

您要么必须接受这种情况，要么可以通过在功能分支中工作来调整您的工作流程，例如主 - 开发 - 功能分支。

一旦功能完成，您可以从功能分支进行 squash-merge 以开发和删除功能分支。现在您可以在没有所有 WIP 提交的情况下进行从开发到主的合并，例如当您发布新版本时。

【讨论】：