Git 壁球合并或 git force push？

Question

我们正在使用gitlab。主分支受到保护，只有项目所有者才能向主分支提交/接受合并请求。其他开发人员发送合并请求以将他们的代码放入 master。

当我们发送合并请求（从功能分支到主分支）时，其中一位开发人员会审查代码。如果有任何建议/cmets，开发人员会更新他的代码，合并请求也会显示新的提交。

然后 QA 开始在分支上进行测试，开发人员在同一分支中修复错误。一切就绪后，QA 会在合并请求中添加一条注释，说明它已经过测试。

由于有很多提交，但功能只有一个，为了便于管理，我们希望将其作为单个提交推送。

这里是项目所有者和我矛盾的地方。我要求项目所有者做一个git merge --squash，但他要求我通过将所有内容压缩到最后一次提交并强制推送来重新设置我的分支。既然分支在这之后会死掉，他的论点是，它不太可能造成任何麻烦。

那么，这里最好的方法是什么？

附：在 gitlab 中没有进行 squash 合并的 GUI 选项，唯一可用的选项是按原样合并所有提交。

Answer 1

这两种操作的结果非常相似，在 master 之上的提交和最终会死掉的特性分支。

合并 --squash 强制项目所有者处理可能出现的冲突。为了避免这个问题，你必须在合并之前在你的特性分支中合并 origin/master。

之后，最终结果的唯一区别是操作后的特征分支点在哪里：

1. 在merge origin/master, merge --squash 之后：特性分支将指向一个垂死的分支，该分支最终会死掉，但会有些混乱：它已经合并了吗？
2. 在rebase, force push, merge --ff 之后，功能分支将指向压缩的提交。

你必须决定：

• 强制您“删除”功能分支的过程，使其成为保留功能分支历史记录的明确选择（通过在变基之前创建新的 ref 并推送它 - 可能使用更新的名称：featureA_merged）
• 保留所有功能分支但强制您记住/管理已合并的分支的过程。

恕我直言，变基和强制推送毕竟是一种更清洁的解决方案。您需要处理潜在的冲突，并将引用移出垂死的分支，这可能会在未来引起麻烦和/或混乱。即使做一些现在看起来错误的事情，强制推动。