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