git merge --squash 会导致跨分支合并时头疼吗？

Question

4

我在一个正在成长并且使用git的团队中工作。通常情况下，我们都是在自己的分支上进行工作。

我从另外一个同事的存储库中拉取了一些更改。他的更改最终被添加到并合并到主分支中，采用了压缩提交的方式。

当我试图从主分支中获取并合并时，出现了许多冲突。我认为这是由于压缩合并以及它会混淆合并跟踪所导致的。有没有轻松的方法解决这个问题？

其次，如果开发人员正在处理多个分支，并且可能需要彼此的更改才能进入主分支，有没有一种方法来处理这个问题，同时继续采用主分支上的压缩提交。

经常提到Rebase。但是我不知道如何在有多个根分支的情况下运作？

- Jeremy French

2个回答

2

我想补充的是，只有当分支是公共的时候，压缩才会造成混乱。如果开发人员在本地工作于一个带有混乱提交（例如“哦糟糕，又出问题了”、“好了！”、“糟糕，又坏了”、“好了，现在修好了”）的分支上，可以轻松地将它们压缩成一个提交，并添加一条关于代码更改的好信息（在推送到远程仓库或共享之前）。

一旦推送到远程仓库，这将与未压缩的单个常规提交看起来完全相同，就像开发人员编写代码时天使在保证他所做的一切都是完美的一样，然后开发人员可以自由地在本地使用git进行增量更改，我发现这对于找出我最近在代码中破坏了什么很有用。

我的看法是：压缩是一个适用于本地工作流程的绝佳工具，即一个开发人员。一旦提交被共享，就不应该压缩。

- Fire Crow

这篇文章提供了一种解决合并冲突的方法：将压缩后的提交合并回其他分支。但如果您不想将整个分支合并回去，您就必须创建一个中间分支... - Tobias Kienzler

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Amber · Accepted Answer

是的，压缩会对重复合并造成破坏。最好的建议是不要压缩 - 具体来说，不要压缩公共内容。在与他人分享之前，重新编写自己的提交记录，但一旦分享，它们应该保持原样，使用常规的合并提交。

您仍然可以通过使用git log --first-parent来获得合理的日志输出，将已合并分支的日志压缩为仅包含合并提交，同时保持实际历史记录不变。