公司今年开始用 git，用的是 gitlab，每个人 fork 后在自己的库上改，然后发 merge request，最后 root 合并到 root 主项目上。
但是问题是最后的日志中太多 merge 日志了。另外也有同事提交上来的 merge request 中有 merge root 的日志。还有开发分支名字取的不规范，最后 merge 后，更晕了。
现在突发奇想，能不能这样，同事发了 merge request 后，我不合并，我只看根据里面的 commit ID，全部直接 cherry-pick 到 root 的主分支。这样日志就干净了。
现在请教大家，如果这么做有什么问题吗？有什么后遗症吗？
 |
1
momocraft Sep 27, 2017
这样做等价于你替他们 rebase -i，你有时间就没问题。
|
 |
2
mcfog Sep 27, 2017 via Android
公司内部用 fork 的价值在哪里？统一发 pr 的话，pr 应该是有意义的，比如新版本 /patch 发布，多不是问题，问题是没有意义吧
分支命名不规范就要求大家规范啊，如果你负责源码管理，那这就是你的锅。发邮件+开会说清楚分支命名要求，然后第二天起不合规范的 request 一律打回，over |
 |
3
happypy1 Sep 27, 2017
设置命名规范，统一 merge 流程，merge 之前至少两个人 review，不合规范的不准 merge，基本上就可以杜绝这些情况了。。
|
 |
4
HangoX Sep 27, 2017 via Android
不让用 merge 就好了,只能用 rebase
|
 |
5
Hstar Sep 27, 2017
公司内部 fork 毫无意义+1
|
 |
6
mritd Sep 27, 2017 via iPhone
|
 |
7
jk2K Sep 27, 2017
公司内部没必要用 fork, 阮一峰有一篇文章讲的是 Git 协作流程的, http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
|
 |
8
SoloCompany Sep 27, 2017
你可以用 EE，支持 rebase 和 squash 工作流
但我们采取的做法是手工合并，也完全能满足需求 |
|
9
SoloCompany Sep 27, 2017
还有就是公司内部不要用 fork，fork 了的话，merge request (push request) 一般因为权限问题是无法修改的，公司内部（或组内）应该采用 branch - merge 工作流，这样就没有权限问题，merge request (push request) 上就可以多人协作连续打补丁了
|
|
10
SoloCompany Sep 27, 2017
参考
https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html squash / rebase / fast-forward merge 是 EE 才有的功能 |
 |
11
paranoiagu OP |
 |
12
superwater Oct 28, 2017
1. 内部的话确实 fork 的必要性不大。更多的库，整体开销更大。
2. 如 @SoloCompany 所述，Gitlab EE 针对 merge 的选项更丰富些。此外分支名称等等也可以设置规则，不符合规则的无法推送。 3. Rebase 会对 history 有影响，慎用 |
|
13
paranoiagu OP @superwater 谢谢。
|
Select Language