2

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

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

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

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

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

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

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

4

1 回答 1

4

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

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

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

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

你必须决定：

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

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

于 2012-10-17T21:37:48.877 回答