git merge——挤压（分支）产生错误

目前我有一个

1-user-model

分支

然后，我从这里签出并创建了一个

1-user-model-squash

分支

然后，当我尝试运行git merge--squash 1-user-model时，我得到了这个错误

致命：你不能结合——挤压——没有ff

我还尝试签出到

master

，然后运行相同的命令，但仍然出现了错误

---

有什么线索吗？

无法将

--no ff

与

--squash

组合的原因是挤压合并不是合并

挤压合并不是合并！ 我知道这听起来很奇怪也很错误。更糟糕的是，当您运行

git merge--squash时，您正在合并

结果不是“合并”

这怎么可能？合并的行为怎么会导致非合并的结果

在某种程度上，这是一个术语问题。Git将merge用作动词（表示合并某些代码更改的操作）和形容词（表示特定类型的提交：合并提交）。包括我在内的人把这个形容词形式缩短为“合并”，把它变成一个名词

通过执行git merge--squash

得到的提交不是合并提交 在Git中，合并提交是至少有两个父提交的提交

这是合并提交的定义。它清晰而简单。这意味着，将来，当人们（也许是你自己，也许是其他人）再次查看此存储库中随时间发生的历史时，他们会发现提交，他们将能够看到：“啊哈，此提交是一个合并，它是通过合并这两个父提交实现的。”

命令

git merge--squash

不会进行这些提交。相反，它运行常规合并代码，然后停止并强制您进行自己的提交，即使合并成功。当您进行该提交时，它是一个普通的、非合并的单亲提交

因此，

git merge--squash

可以合并（code），但不会产生合并

同时，

--no ff

标志表示“进行合并” 如果运行常规的非挤压类型，

git merge

，git有两个选项，其中一个选项有时可用。Git可以进行真正的合并，或者如果真正的合并很简单，它可以完全跳过合并，并对当前分支名称进行“快进”

快进也不是合并 这是Git奇怪术语的另一个障碍。称之为“快进合并”会适得其反：我们不仅没有得到合并提交，甚至没有得到任何合并操作。动词动作“合并”从未发生，名词形容词“合并”也不会产生。相反，我们只是在提交图中得到一个标签（分支名称）。1

在任何情况下，有时候Git都可以进行简单的合并，只是快速前进一个标签，但您确实希望Git进行真正的合并。特别是，如果要将开发或功能线合并到发行版或主分支中，通常需要将沿袭（提交的历史记录）分开。快进操作连接历史记录，而不是将它们分开。这就是为什么

git merge

拥有

--no ff

：强制它进行真正的合并，即使git可以做一个假的合并，只是快速向前分支

将

--no ff

（或者，就此而言，

--ff only

）与

--squash

组合是没有意义的，因为

--squash

意味着“调用合并机制，但不进行提交，也不为将来的提交记录合并操作。”-运行

git merge--squash

后进行的提交不是合并提交

简而言之，挤压合并不是合并

---

1当您执行

git push

时，这种提升是您想要的，有时也是在成功执行

git fetch

后您想要的。如果您有一些上游分支，比如

origin/master

，而其他人向上游添加了提交，那么您可以

git fetch

这些提交。然后，您通常希望将自己的工作重新设置为

git基础，但如果您还没有自己的新工作，您只需将
master
快速前进即可

执行此操作的命令是
git merge
，这很烦人，因为如果您有自己的工作，您可能应该使用
git-rebase
。幸运的是，您可以运行
git-rebase
；当您没有工作时，这对分支名称的影响与快进合并相同

或者，您可以运行
git merge--ff only
，尝试快进，如果不可能，则会失败。这有点长，所以我自己用了一个别名，
git mff
，其中
m
代表“合并”或“移动”，而
ff
代表“快进”。我还有第二个别名，
lin
，用于记录/查看传入的内容。制作这两个别名非常简单：

git config --global alias.lin "log ..@{u}"
git config --global alias.mff "merge --ff-only"

现在我可以运行
git fetch
，然后运行
git lin
来查看出现了什么，然后
git mff
如果我只需要快速前进，或者
git show
特别有趣的部分，创建一个新分支和/或
git rebase
，如果需要，等等