我有一个包含master和alt分支的git存储库。 alt分支包含master代码的修改版本，我正在尝试将master之间的更改合并到alt，如下所示：
git merge --squash master
合并冲突结果：
Auto-merging myproject/foo/bar
CONFLICT (content): Merge conflict in myproject/foo/bar
Squash commit -- not updating HEAD
Automatic merge failed; fix conflicts and then commit the result.
在我解决冲突并提交更改后，一切似乎都很好，但是当我再次运行git merge --squash master时（不对任何分支进行任何更改）我将得到相同的冲突错误。
为什么？我错过了什么？
答案 0 :(得分：30)
通过squash合并，您创建了一个具有但不是真正合并效果的提交。
也就是说，工作树具有您期望的修改，但元数据不会：最重要的是，提交没有两个父项（一个在master上，一个在alt上因此后来的合并无法找出最后的共同祖先。
squash master。我会将任何有用的信息累积到压缩的提交中，但特别是不希望此功能的增量开发历史记录污染master提交时间线。rebase -i来压缩它们的提交，但这更容易squash 您希望保持历史记录和祖先元数据完整的任何合并，例如，只要您希望重复递归合并正常工作，特别是 OP正在尝试。
squash只是不是一个好的默认值，这就是为什么它不是默认值。
答案 1 :(得分：1)
要添加到“壁球合并的无用使用”中：Git 2.29（2020年第四季度）说明了带有merge --squash的陷阱：
请参见commit 087c616的commit 409f066，commit 5065ce4，brian m. carlson (bk2204)（2020年9月20日）。
（由Junio C Hamano -- gitster --在commit c5a8f1e中合并，2020年9月29日）
docs：解释为什么壁球合并会被长时间运行的分支破坏签名人：brian m。卡尔森
在许多项目中，通常使用壁合并，主要是为了在不使用逻辑上独立的，可二等分的提交的开发人员面前保持整洁的历史。
就目前的情况而言，由于缺少任何新的合并基础，当使用南瓜合并来合并长期运行的分支时，这往往会导致严重的问题。
即使是非常有经验的开发人员也可能会犯此错误，所以让我们添加一个FAQ条目，解释为什么这有问题，并说明应该使用常规的合并提交来合并两个长期运行的分支。
gitfaq现在包含在其man page中：
合并和重新定基
将长寿分支与南瓜合并合并会发生什么问题？
通常，使用壁球时可能会出现各种问题 合并以多次合并两个分支。
这些可能包括看到额外的 使用GUI或使用git log表示法在...输出中提交 表达范围，以及需要重新解决冲突的可能性 一遍又一遍。当Git在两个分支之间进行正常合并时，它将恰好考虑三个 要点：两个分支和第三个提交，称为 merge base ，即 通常是提交的共同祖先。
合并的结果是总和 合并基数和每个标题之间的变化。合并两个 具有常规合并提交的分支，这将导致新的提交 当它们再次合并时，最终会成为合并基础，因为现在有了新的 共同祖先。
Git不必考虑更改之前发生的更改 合并基础，因此您不必重新解决之前解决的任何冲突。执行南瓜合并时，不会创建合并提交；相反， 一侧的更改将作为常规提交应用到另一侧。
这意味着这些分支的合并基础不会改变，所以当Git 去执行下一个合并，它会考虑它所有的更改 考虑了最后一次加上新的更改。
这意味着可能需要重新解决任何冲突。
同样，在...，git diff中使用git log表示法或GUI的任何操作都将显示自原始合并库以来的所有更改。因此，如果您想重复合并两个长期分支，那就是 最好始终使用常规合并提交。