V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
yeqizhang
V2EX  ›  git

git 搞分支的问题

  •  
  •   yeqizhang · 2020-09-10 10:33:09 +08:00 · 3900 次点击
    这是一个创建于 1533 天前的主题,其中的信息可能已经有所发展或是发生改变。

    你们平时开发是像 github 一样 fork 后再 clone 这个仓库开发?

    还是 clone 原仓库,基于原仓库的 master 开一个分支开发?

    我们项目几十号人,我给了他们 fork 权限,发现部分人是 fork 后进行开发的,一个月都没 pull 到原仓库了。

    第 1 条附言  ·  2020-09-10 11:27:20 +08:00
    谢谢大家的回复,解决了我的疑惑~
    26 条回复    2020-09-11 09:20:41 +08:00
    erwin985211
        1
    erwin985211  
       2020-09-10 10:39:06 +08:00   ❤️ 1
    虽然我不太懂,但是你们开发前都不合并一下最新代码的吗,这样做你们是怎么合并代码上线的
    linxb
        2
    linxb  
       2020-09-10 10:41:12 +08:00   ❤️ 2
    不需要 fork 吧,拉取原仓库代码,开发的时候每个人基于 master 主干 checkout 分支做开发
    aimaodeyuer
        3
    aimaodeyuer  
       2020-09-10 10:44:27 +08:00   ❤️ 3
    1.clone 原仓库
    2.master 拉新开发分支
    3.开发完了往 dev 固定分支合并测试
    4.dev 通过后上 QA,开发分支合到 QA 的 release 分支测试
    5.QA 验证通过,用 release 部署线上
    6.master 回合 release
    7.周而复始
    goodboy95
        4
    goodboy95  
       2020-09-10 10:44:43 +08:00   ❤️ 1
    fork 的好处是能做代码审查,如果不放心他们的代码质量就 fork,提交的时候让他们提 merge request 。
    如果没啥不放心的就直接 clone 吧。
    zaul
        5
    zaul  
       2020-09-10 10:45:08 +08:00   ❤️ 1
    拉取原仓库代码,开发的时候每个人基于 master 主干 checkout 分支做开发
    KuroNekoFan
        6
    KuroNekoFan  
       2020-09-10 10:47:17 +08:00
    githubflow 加一个平行于 master 的 test/dev 分支
    swulling
        7
    swulling  
       2020-09-10 10:52:11 +08:00 via iPhone   ❤️ 1
    你要用 github,那就是 fork 多代码库加 pull request,或者多分支加 pull request

    但是我个人更喜欢 gerrit 的 cr 模式
    floyda
        8
    floyda  
       2020-09-10 10:55:34 +08:00   ❤️ 1
    fork 就用 PR 的方式提交代码, 对审核者不太友好, 面临冲突的可能比较多.
    如果人多, 不建议在同一个分支上并行开发, 这样相当于把解决冲突的任务分散到组员身上, XJB 乱改就不好了.

    如果十几个人, 可以按功能划分 submodule

    不 pull 那就是管理的问题了
    hakono
        9
    hakono  
       2020-09-10 10:56:50 +08:00 via Android   ❤️ 1
    又不是给开源项目贡献代码,fork 实在是太麻烦了

    基本都是 clone 后建分支然后 pull request

    如果不信任的话设置好权限和用户组就行了
    yeqizhang
        10
    yeqizhang  
    OP
       2020-09-10 11:08:30 +08:00
    @floyda 嗯,已经是很多子模块,冲突不大可以直接拉分支弄的。跨部门的多个项目,他们 fork 后不 pull 倒是问题不大,就是我找了挺久都没看到他们最新有提交代码,我都怀疑他们另起炉灶去搞了仓库,没想到是 fork 派生了
    ghostcode
        11
    ghostcode  
       2020-09-10 11:11:15 +08:00   ❤️ 1
    按照 git flow
    chendy
        12
    chendy  
       2020-09-10 11:19:36 +08:00   ❤️ 2
    自家项目还 fork 个啥,控制分支权限,主干分支必须 pr 就行了
    leopod1995
        13
    leopod1995  
       2020-09-10 11:30:16 +08:00
    保持良好习惯,fork 之后的好处在于自己的 repo 想怎么玩怎么玩你
    xhinliang
        14
    xhinliang  
       2020-09-10 12:08:16 +08:00
    1. Git Flow
    2. GitHub Flow
    3. GitLab Flow
    4. TBD

    一般就这四种,三楼那个我觉得是不太规范的。
    j2gg0s
        15
    j2gg0s  
       2020-09-10 12:28:08 +08:00
    https://nvie.com/posts/a-successful-git-branching-model/ 建议走 feature,在同一个 repo 开发就好
    oneisall8955
        16
    oneisall8955  
       2020-09-10 12:36:13 +08:00 via Android
    master checkout 出 dev,dev 按需求名称和日期 checkout 出需求分支,相关人都在需求分支开发,不同需求不同分支,qa 时候用 dev 合并对应需求分支,qa 验证过合到 master,master 上生产,我司大致流程这样
    yeqizhang
        17
    yeqizhang  
    OP
       2020-09-10 12:51:23 +08:00 via Android
    @erwin985211 我们是多个子工程独立的,只是有一个 common,所有子工程都放在一个仓库里而已。一般不会在 common 模块写东西,各个部门之间基本上不会有冲突,只部署自己的那个引用 common 模块的工程。
    gromit1337
        18
    gromit1337  
       2020-09-10 14:59:58 +08:00
    我现在的公司一个版本一个分支的开发,现在已经不知道有多少个分支了,不敢说话🙊
    maichael
        19
    maichael  
       2020-09-10 15:04:11 +08:00
    @goodboy95 #4 切分支也一样可以 review 的。
    maichael
        20
    maichael  
       2020-09-10 15:05:52 +08:00
    其实没有本质上区别,你 fork 出来一个仓库其实也是一个分支,重点都还是看你们项目代码的主分支是怎么管理的。
    Cola98
        21
    Cola98  
       2020-09-10 15:07:36 +08:00
    clone 项目
    check 分支
    push 分支
    这个样子
    whileFalse
        22
    whileFalse  
       2020-09-10 15:39:21 +08:00
    @aimaodeyuer 请问为什么部署的代码和 master 不是同一个分支呢?
    我是想问,为什么不先把 release 合并到 master,然后依照 master 更新生产呢 /
    c4fun
        23
    c4fun  
       2020-09-10 15:55:10 +08:00   ❤️ 1
    分支本身的策略大家都说了很多,基本上大家都偏向于一个仓库,使用 git flow 的方式来拉分支。
    一般一个月都没有 pull 的话,那是敏捷和 CI/CD 的思路没有贯彻好,这种比较容易出现各种合并冲突,并且也不利于问题的早期发现。
    1. 建议 2~4 周一个迭代,每一个迭代开始,就取一个类似于 sprint-001 这样的分支作为主开发分支,用户在这个迭代主分支上面拉 feature 分支开发,并且基本每个 feature 完成之后都要合并到 sprint-001 中(可以用 github action 来做 CI,这样实现每次提交自动触发流水线,及时发现问题)
    2. 要发布的时候,可以拉出一个对应的 release 分支,可以在这个分支上面维护 release_note 等。
    3. release 分支正式发布之后,合并回 master 分支,同时打 tag 。
    4. 循环下一个迭代。
    VDimos
        24
    VDimos  
       2020-09-10 15:59:50 +08:00 via Android
    用 gerrit
    sxlzll
        25
    sxlzll  
       2020-09-10 20:17:16 +08:00
    fork 是因为开源项目,肯定不能给所有人静默开写权限
    内部项目那么麻烦干嘛
    yanue
        26
    yanue  
       2020-09-11 09:20:41 +08:00
    人多 多版本同时进行开发 按照 git flow 流程容易管理些
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1053 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 42ms · UTC 19:29 · PVG 03:29 · LAX 11:29 · JFK 14:29
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.