V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
paranoiagu
V2EX  ›  GitLab

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

  •  
  •   paranoiagu · 2017-09-27 08:06:25 +08:00 via Android · 5961 次点击
    这是一个创建于 2374 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

    13 条回复    2017-10-30 08:13:24 +08:00
    momocraft
        1
    momocraft  
       2017-09-27 08:18:04 +08:00
    这样做等价于你替他们 rebase -i,你有时间就没问题。
    mcfog
        2
    mcfog  
       2017-09-27 08:33:17 +08:00 via Android
    公司内部用 fork 的价值在哪里?统一发 pr 的话,pr 应该是有意义的,比如新版本 /patch 发布,多不是问题,问题是没有意义吧

    分支命名不规范就要求大家规范啊,如果你负责源码管理,那这就是你的锅。发邮件+开会说清楚分支命名要求,然后第二天起不合规范的 request 一律打回,over
    happypy1
        3
    happypy1  
       2017-09-27 08:40:10 +08:00
    设置命名规范,统一 merge 流程,merge 之前至少两个人 review,不合规范的不准 merge,基本上就可以杜绝这些情况了。。
    HangoX
        4
    HangoX  
       2017-09-27 08:46:00 +08:00 via Android
    不让用 merge 就好了,只能用 rebase
    Hstar
        5
    Hstar  
       2017-09-27 09:20:09 +08:00
    公司内部 fork 毫无意义+1
    mritd
        6
    mritd  
       2017-09-27 09:22:05 +08:00 via iPhone
    rebase 一下,然后走 gitflow

    参考这里 https://mritd.me/2017/09/05/git-flow-note/
    jk2K
        7
    jk2K  
       2017-09-27 09:23:18 +08:00
    公司内部没必要用 fork, 阮一峰有一篇文章讲的是 Git 协作流程的, http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
    SoloCompany
        8
    SoloCompany  
       2017-09-27 09:50:08 +08:00
    你可以用 EE,支持 rebase 和 squash 工作流
    但我们采取的做法是手工合并,也完全能满足需求
    SoloCompany
        9
    SoloCompany  
       2017-09-27 09:52:27 +08:00
    还有就是公司内部不要用 fork,fork 了的话,merge request (push request) 一般因为权限问题是无法修改的,公司内部(或组内)应该采用 branch - merge 工作流,这样就没有权限问题,merge request (push request) 上就可以多人协作连续打补丁了
    SoloCompany
        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 才有的功能
    paranoiagu
        11
    paranoiagu  
    OP
       2017-09-27 16:10:58 +08:00
    @momocraft
    @mcfog
    @happypy1
    @HangoX
    @Hstar
    @mritd
    @jk2K
    @SoloCompany

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

    总之谢谢各位了,有啥好点子继续提供。
    superwater
        12
    superwater  
       2017-10-28 10:27:06 +08:00
    1. 内部的话确实 fork 的必要性不大。更多的库,整体开销更大。
    2. 如 @SoloCompany 所述,Gitlab EE 针对 merge 的选项更丰富些。此外分支名称等等也可以设置规则,不符合规则的无法推送。
    3. Rebase 会对 history 有影响,慎用
    paranoiagu
        13
    paranoiagu  
    OP
       2017-10-30 08:13:24 +08:00 via Android
    @superwater 谢谢。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3041 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 14:39 · PVG 22:39 · LAX 07:39 · JFK 10:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.