Question

我的开发团队最近开始使用Gitlab。我曾建议，在合并请求中，我们需要压缩提交。我有很多反对意见，认为这样做并不安全。

典型的功能开发周期包括每日提交和推送功能分支。它还包括每天从主服务器获取一次git拉动，以与其他更改保持同步。有时，这涉及解决合并冲突。

他们相信所有这些都是从master进行合并，然后对master和squash提交执行合并请求可能导致未检测到的合并问题。

这有什么道理吗？我的假设是，无论如何压缩提交都是安全的。

Answer 1

当Git执行三向合并（这是默认的合并样式）时，它将考虑三点：合并基础（通常是共同祖先）和两个首部。它不会以任何方式考虑两者之间的任何提交。

因此，如果这些提交中的每个提交中的文件（根树）的状态相同，而无论您是壁球合并还是不壁球合并，那么结果将是相同的，并且合并冲突将不管好坏。

现在，发生合并冲突时是否很容易查看历史记录并查找预期的行为是另外一回事了；由于您所拥有的只是两侧的巨大压痕，因此找出正确的分辨率可能会更加困难。但是冲突本身应该没有什么不同。

Answer 2

没有理由害怕...很多人都用git rebase -i做IT。我个人遵循的替代方法是不遗余力，不涉及重新定基：

git checkout my-feature-branch
git pull # merge changes from upstream, do _not_ rebase.
# correct conflicts if they show up and finish merge
# after merge is finished/committed the only differences between your branch and upstream are related to _your_ feature and so....
git reset --soft the-upstream-branch # set branch pointer to upstream branch, all differences are set on index ready to be committed
git commit -m "the feature in a single revision"

合并请求壁球提交选项是否安全

2 个答案: