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

各位大佬你们团队开发 git 是如何管理的?

  •  
  •   liuchengfeng1 · 138 天前 · 7870 次点击
    这是一个创建于 138 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最好是 10 个人以上的技术团队,你们面对 版本协作开发、版本上线顺序前后不一致、开发途中穿插需求或是解决 bug 、如何减少代码冲突等等,是怎么处理的呢?有什么比较好的 git 管理方法

    目前我们是这样:

    从 prod 单独拉一个 release 分支,然后 4 、5 个人在这个分支上开发,按功能区分模块,完成后让某个人合到 dev 、test

    但是有个问题,开发的人一多,这样特别容易造成代码冲突

    image.png

    75 条回复    2024-08-09 17:45:42 +08:00
    weixind
        1
    weixind  
       138 天前   ❤️ 4
    https://nvie.com/posts/a-successful-git-branching-model/

    就这个。feature 多 rebase develop 分支。
    miaotaizi
        2
    miaotaizi  
       138 天前
    差不多都是这样吧
    Xu3Xan89YsA7oP64
        3
    Xu3Xan89YsA7oP64  
       138 天前
    gitflow ,代码分支自上而下的同步得写脚本之类的自动进行
    冲突在所难免,超过 500 行代码就该提交下进行冲突处理和 code review 了
    liuchengfeng1
        4
    liuchengfeng1  
    OP
       138 天前
    @miaotaizi 就是想知道还有没有最优解
    iMusic
        5
    iMusic  
       138 天前
    我是这样的,比如大家代码都合并到 develop 分支。
    开发新需求我在本地创建一个新分支比如 feat
    开发完后切换到 develop 分支拉取最新代码,然后切换回 feat 分支,合并 develop 代码,有冲突解决冲突
    再次切换到 develop 分支,合并 feat 代码,最后推上去

    develop> git co -b feat
    啪啪啪写代码
    feat> git co develop
    develop> git pull
    develop> git co feat
    feat> git rebase develop
    啪啪啪解决冲突,add, rebase --continue
    feat> git co develop
    develop> git merge feat
    deveop> git push
    aababc
        6
    aababc  
       138 天前
    服务端开发,我们就比较简单了,开发的起点是 master ,从 master 创建 feature 分支,不同的项目需求创建不同的分支,然后合并到 test 进行测试,上线的时候后把 feature 直接合并到 master 。不过这么做也有一个小问题,大家在功能测试的时候比较容易互相影响,但是总体还是可控的。
    catinsides
        7
    catinsides  
       138 天前   ❤️ 3
    如果避免不了很多人修改同一个文件同一处代码,项目结构也得调整吧,靠 git 可能无法解决
    justplaymore
        8
    justplaymore  
       138 天前   ❤️ 6
    “开发的人一多,这样特别容易造成代码冲突”

    这个和 git 分支策略没有太大关系,根本问题是在项目本身的结构设计是否合理,功能模块划分是否清晰,每个类的职责是否足够单一。

    冲突是在分配开发任务的时候就决定了的,而不是在做分支策略的时候决定的。
    如果这些任务对应的代码是不够独立清晰的,那么冲突就是必然的。
    liuchengfeng1
        9
    liuchengfeng1  
    OP
       138 天前
    @aababc 俺们也是这样
    DamonLin
        10
    DamonLin  
       138 天前
    开发前多拉开发分支的代码,不要一次性提交太多代码,多人开发冲突是难以避免的,解决冲突还是要细心。
    liuchengfeng1
        11
    liuchengfeng1  
    OP
       138 天前
    @weixind 不太适合呀,就是一个项目迭代太多了。I won’t talk about any of the projects’ details, merely about the branching strategy and release management.(我不会谈论任何项目的细节,只会谈论分支策略和发布管理。)
    liuchengfeng1
        12
    liuchengfeng1  
    OP
       138 天前
    @weixind 就是不太适合呀,就是一个项目里迭代太多了。I won’t talk about any of the projects’ details, merely about the branching strategy and release management.(我不会谈论任何项目的细节,只会谈论分支策略和发布管理。)
    liuchengfeng1
        13
    liuchengfeng1  
    OP
       138 天前
    @DamonLin 真的是 事在人为😂
    isnullstring
        14
    isnullstring  
       138 天前
    一开始老项目换 Git 时候也遇到类似问题,后面重新整理代码,拆分功能
    各自管各自的,冲突也减少,即使有紧急 BUG 或者需求要上都不影响
    qxhnks
        15
    qxhnks  
       138 天前 via iPhone
    Google 搜 trunk-based development
    yanqing07
        16
    yanqing07  
       138 天前
    @liuchengfeng1 #4 都是在这基础上变,适合自己项目就好。代码冲突是无解的,所以才要将功能拆分到不同文件,用现在的话说,就是分模块。
    举例,如果两个人同时要在一个页面做开发,这个页面有个入口文件(index.ts|js),他们各自写自己模块( a.ts,b.ts ),在 index.ts 引入这两个文件。基本上冲突就只在 index.ts 出现,只要没人在 index 写大段业务逻辑,可以说基本冲突为零。
    weixind
        17
    weixind  
       138 天前
    @liuchengfeng1 #11 冲突是必然的,要想办法减小冲突的粒度。开发分支要多 rebase develop 分支,多次解决冲突,不要最后堆到一块解决。同时项目模块划分要更清晰。
    miaotaizi
        18
    miaotaizi  
       138 天前
    可以试试 dev 分支 更新了之后要求 各个 feature 分支将 dev 合并到自己分支内部会不会好些
    xuld
        20
    xuld  
       138 天前   ❤️ 1
    按上线计划拆分分支,而不是一个功能一个分支,也不是一个人一个分支。假定上线计划是一周一发布,那 dev 分支放本周需要上线的内容,如果有内容需要本周开发,但不知道什么时候上线,或者你们上线计划经常变化,那建立单独 dev 分支。每个功能做完之前拉代码,做完立即提交。每个人都这样做,问题就不会太大。
    amon
        21
    amon  
       138 天前
    随着人数增加和项目复杂度的提升,解决代码冲突已经不是 Git 范筹的问题,要从项目和人员的组织架构上调整,以及工作流程的重新定义。
    - 代码结构要更松散,减少耦合。比如拆分文件和项目,如微服务
    - 工作内容的重新划分,比如由以前的一坨进行水平或垂直拆分;由以前的水平拆分,变成垂直拆分;或由以前的垂直拆分变成水平拆分
    horizon
        22
    horizon  
       138 天前
    gitlab flow
    yagamil
        23
    yagamil  
       138 天前
    尽量少动别人的代码,动了之后就要马上提交,写好注释。
    vx7298
        24
    vx7298  
       138 天前
    开发:
    1 , 每个人只能从 dev 合并到自己
    2. 功能开发 ok 后,才合并到 dev ,并且有专人审核,必须 build ok

    bug:
    1 , 牵头人,拉分支
    2 , 所有相关人员的改进,必须有由牵头人负责审核合并,
    gorvey
        25
    gorvey  
       138 天前
    冲突是必然的,你们尝试过用插件统一格式吗,比如前端项目的 eslint/prettier 。

    如果每个人的编辑器配置不同,哪怕只修改一部分代码,整个文件的格式都会乱,这样冲突会更多
    vx7298
        26
    vx7298  
       138 天前
    @gorvey ,,对,,冲突是必然的,多人开发,没有不冲突的,不要从内心里排斥冲突,而是从架构角度管控和解决冲突,git 相当强悍和完美,一旦冲突凌乱无从下手,八成是架构上没理解到位,多人之间目前和方案严重对立,这时候,就是开会了,哈哈,,统一思想
    fields
        27
    fields  
       138 天前
    每个人新增功能/处理 bug 就建一个个人分支呀,每个个人分支只做一个相关功能的 bug 修复或只增加一个新特性,然后 review 合并到 dev 分支上,之后删除自己的个人分支,循环往复。

    如果有 ci/cd 的话,就每天出个包给到测试那边,测试那边去回归测试

    最后从 dev 建个 release 分支,给测试用来做稳定性测试、系统测试等等
    tom
        28
    tom  
       138 天前   ❤️ 2


    1 个固定分支:

    - **master**:主分支。所有的 feature 和 bugfix 分支都从该分支创建。该分支受保护,不允许直接向该分支提交代码

    3 个短期分支,完成功能开发之后需要删除:

    - **feature/\***:功能分支。用于开发新的功能,不同的功能创建不同的功能分支,功能分支开发完成并自测通过之后,需要合并到 master 分支,之后删除该分支
    - **bugfix/\***:bug 修复分支。用于修复不紧急的 bug ,普通 bug 均需要创建 bugfix 分支开发,开发完成自测没问题后合并到 master 分支,之后删除该分支
    - **release/\***:发布分支。用于代码上线准备,该分支从 master 分支创建,创建之后发布到测试环境进行测试,测试过程中发现 bug 需要开发人员在该 release 分支上进行 bug 修复,所有 bug 修复完后,在上线之前,需要合并该 release 分支到 master 分支。release 分支可以长期保留
    me1onsoda
        29
    me1onsoda  
       138 天前
    代码冲突处理在现代 IDE 已经不算个事了吧,图形化操作
    mioktiar56
        30
    mioktiar56  
       138 天前
    直接往 master 干,反正就一个人
    zackzergzeng
        31
    zackzergzeng  
       138 天前
    我们比较简单粗暴,就在 master 上开发提交,然后 release 的时候再从 master 拉出 release 分支,修 bug 的时候把提交 cherry-pick 到各个需要修复的 release 版本
    gitrebase
        32
    gitrebase  
       138 天前
    公共的就一个 master 分支,有新功能或者 bugfix 就自己基于 master checkout 一个新分支,写完后、测试后 merge 到 master ,打个 tag ,根据 tag 走发布
    Ravenddd
        33
    Ravenddd  
       138 天前
    使用 github flow ,其实就是社区玩法,再融合一些企业特点的改变。
    master 、release 、test 、dev:分别是部署环境的分支,需要部署才合并上来
    n 个 feature 分支:需求开发的分支,理想状态下,需要每个 feature 测试完成再合并到 release 和 master ,但是实际的企业环境可能是多需求单测试环境,所以可以以下操作:
    - 开发:测试自己的代码,但是由于依赖其他服务,feature 合并到 dev 分支,部署自测/联调
    - 测试:feature 合并到 test 环境,给测试人员过测试用例
    - 预发部测试:feature 合并到 release ,部署测试
    - 正式发布:feature 合并到 master ,部署

    PS:注意每次修复 bug ,到需要在 feature 分支修复,再合并到部署分支,因为需求可能随时回滚,部署分支可能会回退。这个工作流基本满足大部分开发团队和需求情况。
    coderzhangsan
        34
    coderzhangsan  
       138 天前
    我也想走标准的 git-flow 流,奈何我司是小公司,迭代非常快,要支持这种场景,我司的 git 管理是这样的:只保留 master 这一个维护分支,不设置 dev 分支,多个 feature 分支
    declandragon
        35
    declandragon  
       138 天前
    前端 12 个开发分支,后端 3 个开发分支,一个需求占一个,上线之前把 master 合并到当前的开发分支就行
    coderzhangsan
        36
    coderzhangsan  
       138 天前
    不小心按了 enter ,重发:
    我也想走标准的 git-flow 流,奈何我司是小公司,迭代非常快,要支持这种场景,我司的 git 管理是这样的:只保留 master 这一个维护分支,不设置 dev 分支,一个 test 分支(支持多个 feature 分支并行测试,冲突是难免的),test 分支需要周期性删除,重新从 master 分支 checkout ,保证 test 分支不至于过于混乱,测试完毕后,feature 直接合 master 分支。
    jaylee4869
        37
    jaylee4869  
       138 天前
    每一个 需求/bug 一个分支,遵循 [type]/[title] 的分支名:

    feat/add-user
    feat/enable-rbac
    feat/support-kubernetes-deployment
    fix/issue-233
    fix/npe-error
    feat/JIRA-SERVICE-197
    hotfix/JIRA-20240808

    测试的时候都往某个专门的分支上 merge 或者走 pull request
    developer A: branch feat/add-user merge into test
    developer B: branch fix/issue-233 merge into test

    此时 developer A 早已经准备上线了:
    developer A: branch feat/add-user merge into prod (这时候其实可以 git tag )

    上线没问题,feat/add-user 就可以直接删了,或者放着不动,后续如果这个需求有 bug 了,一定不要继续用这个分支,直接从上次发布的分支上 checkout ,继续往返前面的操作就可以了。

    永远不要使用自己的个人分支,不要把分支想象的一个很长远的东西;除了主要用于 发布 的分支,其他一切分支都视作临时的分支。你越是用自己个人固定的分支,冲突就越多,因为你总是要把 prod 分支往自己分支上 pull ,何必呢,看着都累。

    之前在某美企,分支全都是用的 JIRA ID ,十多年的老项目,几万个历史分支,十几个人的团队,遇到冲突的情况很少。
    arischow
        38
    arischow  
       138 天前
    GitLab Flow + Atomic MR ,小步快跑
    qeqv
        39
    qeqv  
       138 天前
    @coderzhangsan 你这个 test 分支感觉和 dev 差不多
    br_wang
        40
    br_wang  
       138 天前
    冲突多,看看是不是代码结构不太合理,为什么很多人要同时改动同一个文件?
    jiangzm
        41
    jiangzm  
       138 天前
    @horizon 这个图一看就有问题, 至少要有一个对应线上版本的分支不能每个分支都是一直变动的,可以是 master 也可以是其他。
    假如 master 是对应线上版本的,那 master 只能接受来自发布分支(release&hotfix)的合并,原则就是没上线的功能不能合到 master 。hotfix 和 release 可能是并行存在的,那 hoftix 发完同时要合并到 master 和 release ,那这样中间再开 hotfix 以及发布和新开 release 分支均不会漏 hotfix 内容。
    NessajCN
        42
    NessajCN  
       137 天前
    学 Linus 呗
    每个部门自己拉一个 branch
    部门内部再从部门的 branch 拉各自的 feature
    完成了就 commit 自己的 feature, 部门负责人就负责 review 然后把 feature merge 到部门 branch
    CTO 就负责从部门 branch merge 到 master

    如果另外还需要 test 或 release 就都从 master 分
    feiyan35488
        43
    feiyan35488  
       137 天前
    @liuchengfeng1 复杂的有 git workflow
    简化版 github flow
    没有最优解,flow 最终会取决于实际的组织结构
    horizon
        44
    horizon  
       137 天前
    @jiangzm #41
    release 或者 hotfix 对应线上的
    master 作为 upstream branch 保持最新
    allecnm
        45
    allecnm  
       137 天前
    开发从 master 拉 ft , 然后测试环境 test ,最后上线用 release
    Exxfire
        46
    Exxfire  
       137 天前
    我们领导喜欢不同分支间用 beyond compare 合并代码。
    jiangzm
        47
    jiangzm  
       137 天前
    @horizon #44 图里面 release 是作为发布分支,master 看着像开发/测试分支。
    发布分支在发布阶段还可能是变动的怎么可能对应的是线上呢?
    master 保持最新是开发功能的最新吗?那就是常规 dev/test 分支功能了,这个没问题很多团队在 master 上开发。
    名字其实无所谓,只要有特定的分支做测试/特定的分支做发布/特定的分支对应线上版本 就够了。

    这个图里面 feature 从 master 开出来,然后又合并到 master ,理论上就是作为 dev/test 分支功能作为集成测试分支。如果是作为开发/测试分支用,那 feature 分支就不能从 master 开出来了, 一定是一个对应线上版本的分支。
    xsen
        48
    xsen  
       137 天前
    1. 拆。项目、服务、模块进行拆分,不同代码库
    但个代码库避免过多人维护,一般一个代码库 2-3 人维护;若不满足,则拆分代码库

    2. master/dev 分支,dev 为开发分支,每个人开发都是直接在 dev 开发
    a ) 1 天至少从 dev pull 一次代码(合并,基本不会冲突),子功能开发完(单元测试通过或编译通过),提交 dev
    b )测试后,dev 合并至 master
    xsen
        49
    xsen  
       137 天前
    @xsen 另,个人一般要求团队成员 1-2 天必须提交一次代码
    horizon
        50
    horizon  
       137 天前
    @jiangzm #47
    release 所以带日期的呀,又不是只有一个 release 分支
    日期对应发布时间的哈
    你再理解一下,这套模型支撑过 20 多个人一起开发,没问题的哈。
    0xD800
        51
    0xD800  
       137 天前
    个人经验:冲突可以从代码设计上解决,而不是 git 工作流上优化,有一些冲突是无法避免,如果经常遇到同一个文件的冲突,我建议从代码结构上进行拆分优化。
    sungx1202
        52
    sungx1202  
       137 天前
    永远从 master 新切分支,dev 是一个测试汇总池子,所有改 bug/迭代的分支 等汇聚 dev ,发布 pro 时按需 mr (合并请求) mster ,编译打包发布,永远不从 dev 合并 master 。
    linzhe141
        53
    linzhe141  
       137 天前
    @gorvey 这个肯定要统一 eslint 或者 prettier 的配置文件
    liuchao719
        54
    liuchao719  
       137 天前
    @0xD800 说的太对,耦合太重了,或者文件太大导致一个人搞不定。
    qxdo1234
        55
    qxdo1234  
       137 天前
    没有比较好的方案,实际上 git 只是个工具,还是要靠人治,制定 git 工作流,其他的分支 要多从源分支反合并,才能减少冲突,而且也无法确保一定就不出错,git 工具是不会出问题的,只要有人参与做的事情,出问题都是人的问题,
    ChangJingli
        56
    ChangJingli  
       137 天前
    建议了解下主干分支+特性开关管理模型,最近两个大项目实践下来感觉还不错。

    https://mp.weixin.qq.com/s/m4N8ugQEM-StNRHV2XJ8KA
    hqpsoft
        57
    hqpsoft  
       137 天前
    每天自动把主干分支反向 merge 到各个 feature 分支, 有冲突尽早解决.
    mark2025
        58
    mark2025  
       137 天前
    如果是多版本发布策略,用 1 楼图片那种,如果是单版本滚动发布就用 gitlab flow
    yb2313
        59
    yb2313  
       137 天前
    每个小时合并一次主开发分支, 这样就很轻松了
    maninfog
        60
    maninfog  
       137 天前 via iPhone
    TBD + Feature Toggle
    fkname
        61
    fkname  
       137 天前
    一个 master 分支,一个 dev 分支,开发都在 dev ,自己 fork 一个仓库提 mr 合 dev ,有 committer 和特性责任人检视,自验完打 tag 出包转测试,每个人提交代码要保证自验和正常启动,每次提交不能超过 500 行。发布时从 dev 合 master 。
    线上补丁从 master 拉分支出来修改后双合 master 和 dev 。
    csys
        62
    csys  
       137 天前
    参考 Releaseflow https://suraciii.github.io/posts/release-flow/

    重点:
    * 一个主干
    * 快速集成
    * 自动化测试
    * 不要合来合去的
    csys
        63
    csys  
       137 天前   ❤️ 1
    多说一句,gitflow 已经成为了现代软件的一种灾难
    wupher
        64
    wupher  
       137 天前
    简单的项目 gitflow

    更快速或者高效的团队可以考虑 github-flow 或者 gitlab-flow 。

    有奇葩要求的,也可以自己团队商量一套实践。

    但是、但是,总会有 2B 的领导或者不写代码的“技术牛人”,跳出来要求“统一”“规范”,最后搞出个缝合怪。
    southsala
        65
    southsala  
       137 天前
    你这个等所有人在一个分支上开发

    你可以在 release 上多分出几个分支,一个 feat 或者一个组分配一个 release 的子分支,结合 gitflow 看看
    p1gd0g
        66
    p1gd0g  
       137 天前
    还是能力问题,git 本身够简单了。有的同事死活搞不懂,已合并就覆盖别人。习惯太差
    shijingshijing
        67
    shijingshijing  
       137 天前   ❤️ 1
    对于中小公司,真心一劝,像 svn 那样中心化来用 git 是最好的,在满足自身业务版本控制需求前提下,流程越简单越好,血泪教训。
    godwinma
        68
    godwinma  
       137 天前
    我觉得多人一起开发的时候冲突不可避免,谁后提交,谁解冲突。哈哈。
    panda1001
        69
    panda1001  
       137 天前 via Android
    我好奇这种做完立即提交,算不算 svn 的方式使用 git ,比直接 svn 好在哪儿了呢
    @xuld
    xuld
        70
    xuld  
       136 天前
    @panda1001 手下:报告长官,后方发现有敌人来袭。
    你:从后方过来算不算偷袭呢?偷袭是不是不道德?偷袭会遗臭万年的。
    lasuar
        71
    lasuar  
       136 天前
    有“经常冲突” 这个问题说明 代码组织结构 有优化空间。
    panda1001
        72
    panda1001  
       136 天前 via Android
    @xuld 我不是说这样不可以,只是说在项目版本控制的选型上,如果考虑 op 情况和你提供的建议,还选型 git 是想到了哪些优点
    stonesirsir
        73
    stonesirsir  
       136 天前 via Android
    建议用 rebase ,不要用 merge ,后期会明了很多
    jiangzm
        74
    jiangzm  
       136 天前
    @horizon #50 带不带日期没啥区别,带日期难道就不是发布分支了吗。发布分支在发布阶段还是有可能有 bugfix 。
    不是我不理解你那个图一看就明白,确实有问题。应该是你没明白我的意思或者你确实不太懂分支管理流程(对叫流程不叫模型)。

    还有不规范不代表一定会有问题,一个分支也可以玩,既然用了 gitflow 流程不妨就对齐标准。1 楼的图是很经典的虽然每个公司会有点差异但核心原则要保持一致的。
    horizon
        75
    horizon  
       136 天前
    @jiangzm #73
    我那个写的不是 gitlab flow ?
    不争论了,确实我比较菜吧。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3566 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 05:03 · PVG 13:03 · LAX 21:03 · JFK 00:03
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.