Git squash merge或git force push?

时间:2012-10-16 12:43:51

标签: git project-management git-merge git-rebase gitlab

我们正在使用gitlab。主分支受到保护,只有项目所有者可以向主服务器提交/接受合并请求。其他开发人员发送合并请求以将其代码转换为主代码。

当我们发送合并请求(从功能分支到主服务器)时,其中一个开发人员会查看代码。如果有任何建议/意见,开发人员会更新他的代码,合并请求也会显示新的提交。

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

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

这是项目所有者和我发生矛盾的地方。我要求项目所有者做一个git merge --squash,但是他要求我通过将所有内容压缩到最后一次提交来强制我的分支并进行强制推送。由于分支将在此之后死亡,他的论点是,它不太可能造成任何麻烦。

那么,这是最好的方式吗?

P.S。没有GUI选项可以在gitlab中进行压缩合并,只有可用的选项是按原样合并所有提交。

1 个答案:

答案 0 :(得分:4)

两个操作的结果非常相似,在master和最终将死的功能分支之上提交。

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

之后,最终结果的唯一区别在于操作后功能分支的位置:

  1. merge origin/master, merge --squash:功能分支将指向一个最终将会死亡但仍会有些混乱的奄奄一息的分支:它已经合并了吗?
  2. rebase, force push, merge --ff功能分支将指向压缩提交。
  3. 你必须决定:

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

    恕我直言,篮板和力量推动毕竟是一个更清洁的解决方案。您可以处理潜在的冲突,并将参考文献从可能导致将来出现问题和/或混淆的垂死分支中移出。即使是现在看起来像错误的东西,也就是推力。