请教 gitlab 的一些问题，主要觉得太多 merge 的 commit

[paranoiagu]

公司今年开始用 git，用的是 gitlab，每个人 fork 后在自己的库上改，然后发 merge request，最后 root 合并到 root 主项目上。

但是问题是最后的日志中太多 merge 日志了。另外也有同事提交上来的 merge request 中有 merge root 的日志。还有开发分支名字取的不规范，最后 merge 后，更晕了。

现在突发奇想，能不能这样，同事发了 merge request 后，我不合并，我只看根据里面的 commit ID，全部直接 cherry-pick 到 root 的主分支。这样日志就干净了。

现在请教大家，如果这么做有什么问题吗？有什么后遗症吗？

[momocraft]

这样做等价于你替他们 rebase -i，你有时间就没问题。

[mcfog]

公司内部用 fork 的价值在哪里？统一发 pr 的话，pr 应该是有意义的，比如新版本 /patch 发布，多不是问题，问题是没有意义吧

分支命名不规范就要求大家规范啊，如果你负责源码管理，那这就是你的锅。发邮件+开会说清楚分支命名要求，然后第二天起不合规范的 request 一律打回，over

[happypy1]

设置命名规范，统一 merge 流程，merge 之前至少两个人 review，不合规范的不准 merge，基本上就可以杜绝这些情况了。。

[HangoX]

不让用 merge 就好了,只能用 rebase

[Hstar]

公司内部 fork 毫无意义+1

[mritd]

rebase 一下，然后走 gitflow

参考这里 https://mritd.me/2017/09/05/git-flow-note/

[jk2K]

公司内部没必要用 fork, 阮一峰有一篇文章讲的是 Git 协作流程的, http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

[SoloCompany]

你可以用 EE，支持 rebase 和 squash 工作流
但我们采取的做法是手工合并，也完全能满足需求

[SoloCompany]

还有就是公司内部不要用 fork，fork 了的话，merge request (push request) 一般因为权限问题是无法修改的，公司内部（或组内）应该采用 branch - merge 工作流，这样就没有权限问题，merge request (push request) 上就可以多人协作连续打补丁了

[SoloCompany]

参考
https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html

squash / rebase / fast-forward merge 是 EE 才有的功能

[paranoiagu]

@momocraft
@mcfog
@happypy1
@HangoX
@Hstar
@mritd
@jk2K
@SoloCompany

先谢谢各位，学习了。
总结一下：
1、一定要确定规范，现在已经在这么做了，团队人数不多，所以做不到 2 人 review，现在上必须 1 人 review 并点赞后我才会 merge。
2、公司内部是否 fork 的问题，我还要消化一下。
3、另外 merge 比较乱的话，确实可以规定多用 rebase -i，否则不合并就可以。

总之谢谢各位了，有啥好点子继续提供。

[superwater]

1. 内部的话确实 fork 的必要性不大。更多的库，整体开销更大。
2. 如 @SoloCompany 所述，Gitlab EE 针对 merge 的选项更丰富些。此外分支名称等等也可以设置规则，不符合规则的无法推送。
3. Rebase 会对 history 有影响，慎用

[paranoiagu]

@superwater 谢谢。