Git squash merge 还是 git force push？

Question

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

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

然后 QA 开始在分支上进行测试，开发人员在同一个分支上修复错误。当一切都完成并顺利进行时，QA 在 merge 请求中添加一条评论，说明它已经过测试。

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

这里是项目负责人和我矛盾的地方。我要求项目所有者执行 git merge --squash 但他要求我通过将所有内容压缩到最后一次提交并强制推送来重新设置我的分支。由于此后分支将死亡，他的论点是，它不太可能造成任何麻烦。

那么，跟随这里的最佳方式是什么？

附言在 gitlab 中没有用于进行压缩 merge 的 GUI 选项，唯一可用的选项是按原样 merge 所有提交。

Answer 1

这两个操作的结果非常相似，一个在 master 之上的提交和一个最终会消亡的特性分支。

merge --squash 强制项目所有者处理可能出现的冲突。为避免该问题，您必须在 merge 之前在您的功能分支中 merge origin/master。

之后最终结果的唯一区别是操作后特征分支指向的位置:

1. 在 merge origin/master 之后，merge --squash:feature 分支将指向一个垂死的分支，该分支最终会死亡，但会有些困惑:它已经 merge 了吗？
2. 在 rebase、force push、merge --ff 之后，功能分支将指向压缩的提交。

你必须决定:

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

恕我直言， rebase 和强制推送毕竟是一个更清洁的解决方案。您处理潜在的冲突，并将引用移出可能在未来造成麻烦和/或困惑的垂死分支。即使现在做一些看起来错误的事情，力量也会 push 。