请教 gitlab 的一些问题，主要觉得太多 merge 的 commit
paranoiagu 2017-09-27 08:06:25 +08:00 via Android 6628 次点击这是一个创建于 3000 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司今年开始用 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 谢谢。 |
Select Language