美文网首页
版本控制系统(GIT)分支管理规范

版本控制系统(GIT)分支管理规范

作者: 张志_koen_zhang | 来源:发表于2019-02-20 08:53 被阅读0次

    转载

    GIT工作流简介

    功能驱动开发

    "功能驱动式开发"(Feature-driven development,简称FDD).

    它指的是,需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该分支就合并到主分支,然后被删除。

    如果我们开发的内容在功能的角度上就存在不相容,无法合并,则这种工作流未必合适.从项目设计上讲应该尽量避免这种情况的出现,否则,建议分割项目来解决.

    Git flow(Git 工作流)

    Git工作流比喻项目像流水一样顺畅自然的向前流动,不会发生冲击,对撞,甚至漩涡.

    image.png

    目前用的比较广泛的工作流有三种:

    • Git flow
    • Github flow
    • Gitlab flow

    针对目前的项目状况,本文采用的是最早诞生,并得到广泛应用的Git flow。

    Git flow

    首先,项目存在两个长期分支。

    主分支master
    开发分支develop
    前者用于存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的分布版;后者用于日常开发,存放最新的开发版。

    image.png

    其次,项目存在三种短期分支。

    功能分支(feature branch)
    补丁分支(hotfix branch)
    预发分支(release branch)
    一旦完成开发,它们就会被合并进develop或master,然后被删除。

    GIT Flow总览

    image.png

    主分支Master

    首先,代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本,都在这个主分支上发布。

    对应到目前团队中使用的Gitlab,我们建议使用Master作为主分支并设置分支保护(默认设置),每次发布打上Tag,如: 0.1, 0.2或0.3

    image.png

    开发分支Develop

    主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做Develop。

    image.png

    如果想正式对外发布,就在Master分支上,对Develop分支进行"合并"(merge)。

    由于Gitlab中默认对Master设置了分支保护(这个设置允许取消,如果存在多人开发的项目,不建议取消),所以,当需要合并到Master的时候需要在Gitlab里提交合并申请,由项目管理员合并.

    功能分支

    功能分支属于临时性分支,一般合并完就会删除.

    它是为了开发某种特定功能,从Develop分支上面分出来的。开发完成后,要再并入Develop。

    功能分支的名字,可以采用feature-*的形式命名。

    比如我们正在开发分支中开发小宇睿联的需求,这个过程中来了5M微循环的迁移任务,这个时候,就可以从Develop分支中拉出一个5M的功能分支进行开发,避免两个需求开发重叠.

    可能大家还会有疑问,开发分支里已经有一部分小宇睿联的内容,拉出来分支会不会有影响,这种情况可以评估下,如果存在冲突的话可以从Develop分支中向上回溯到一个合适的Commit拉出功能分支来.

    某些情况下,新功能可能需要在线上的版本保持一致,可以从Master里拉出功能分支,也可以.

    image.png

    实际应用功能分支的时候,存在以下几种情况:

    1. 正常迭代,周期性的功能需求
    2. 产品型需求,这种需求的周期很长,需求和项目的主线有很大偏差,同时要求不跟着主板本迭代,如: 本地化部署

    第一种情况,按照标准的feature分支工作流开展即可,不再赘述.

    产品型需求

    这种分支建议以production-分支定义,在功能迭代完成后直接在production-分支上拉出release分支提测,测试完成后,合并回production分支,同时在production分支上打上tag.

    由于这种分支并不合并到主干,所以上线的代码都体现在production分支上,如果线上有bug需要修复,在tag上拉出fixbug分支修复即可.

    这种分支实际上相当于一个独立的项目进行迭代,和本文阐述的分支管理主旨并不相符.

    [图片来不及画]

    预发布分支

    它是指发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。

    预发布分支是从Develop分支上面分出来的,预发布结束以后,必须合并进Develop和Master分支,合并完后删除分支。

    它的命名,可以采用release-*的形式。

    比如我们小宇睿联的需求已经开发完成了需要提测,这个时候我们可以从Develop中拉去一个预发布分支,提交测试.测试过程中出现了bug,就在这个分支里修复,当小宇睿联上线后,把分支合并回Develop,同时合并到Master分支,并在Master分支上打上Tag.

    修补bug分支

    软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。

    修补bug分支是从Master分支上面分出来的。修补结束以后,再合并进Master和Develop分支。它的命名,可以采用fixbug-*的形式。

    image.png

    bug分支在提交的时候,如果存在release分支,需要同时合并到release分支,避免release分支上线的时候,合并到master有冲突.

    Git合并的命令推荐

    |

    <pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;">git checkout develop Switched to branch 'develop' git merge --no-ff myfeature
    Updating ea1b82a..05e9557
    (Summary of changes)
    git branch -d myfeature Deleted branch myfeature (was 05e9557). git push origin develop</pre>

    |

    默认情况下,Git执行"快进式合并"(fast-farward merge),会直接将myfeature分支指向Develop分支。使用--no-ff参数后,会执行正常合并,在Master分支上生成一个新节点。为了保证版本演进的清晰,我们希望采用这种做法。

    image.png

    分支命名规范

    <colgroup><col><col><col></colgroup>
    | 分支类型 | 命名 | 说明 |
    | 主干 | master |
    |
    | 开发分支 | develop |
    |
    | 功能分支 | feature-* | 使用禅道的需求编号(如果对应的需求编号过多,也可以使用拼音缩写) |
    | 预发布分支 | release-* | 使用日期+版本号 , 如: 20181016-1.2 |
    | bug分支 | fixbug-* hotfix-* | 使用禅道的bug工单号,或者根据当前tag版本号增加 |
    | 产品分支 | production-* | 产品分支,对于独立进化的分支,如本地化部署 |

    新平台开发场景指引

    目前新平台开发场景大概有以下几种情形:

    1. 普通迭代
    2. 线上bug修复
    3. 功能提测
    4. 新的项目功能加入

    针对这几种情形,我们依次给出指引

    普通迭代

    日常的迭代我们一般推荐在Develop下正常开发即可,提测的时候拉出Release-xxx分支提交测试,测试完了,如果需要上生产则分别合并到Develop和Master,同时在Master上打上Tag(Tag-x.x.x)标记,删除Release分支.如果,暂时不上生产则合并回Develop,暂时保留Release分支,等待发布到生产.

    比如我们现在正在开发新能源迁移,这个时候并没有新的功能加入,我们只需要按照普通迭代开发即可.

    线上bug修复

    在Master分支里拉出bug-xxx分支修复bug,修复完成后提交测试,测试通过,分别合并到Develop和Master,再删除bug分支.

    功能提测

    提测的时候拉出Release-xxx分支提交测试,测试完了,如果需要上生产则分别合并到Develop和Master,同时在Master上打上Tag(Tag-x.x.x)标记,删除Release分支

    新的项目功能加入

    普通迭代过程中收到了新的需求开发,为了不造成影响,在Develop分支里拉出Feature分支开发功能需求,开发完成后,合并到Develop.提测的时候,在Develop中拉出Release-xxx分支提交测试,测试完毕参照功能提测.

    常见问题

    5M微循环作为一个独立分支,是面对客户独立部署,将来可能不希望跟着正常迭代走,在分支上该如何管理?

    这种情况,由于存在两个线上环境,实际上等于存在两个Master分支,其中一个是5M的分支,它最终也会作为一个长期分支存在,后续的功能开发,或者Bug修复都在这个分支上拉出功能分支来进行,完成测试后再合并回5M的分支,这个工作流有点像Github flow(详见参考文档).

    正常迭代过程中修复了一个bug可能涉及到其他功能分支,如何处理?

    保险起见,最好在不同的分支里分别提交,这样做不可避免的会带来一些麻烦,所以,我们在项目的迭代周期上,一定不要太长,否则遗留的功能/测试分支太多,会给开发人员的开发带来麻烦.

    新的功能开发完成提交了Release分支,如何保证旧的功能不会收新功能影响?

    这个问题本质上并不是工作流的问题,这里也拿出来讲一下,解决这个问题,还是需要从测试着手,而测试分为两块,白盒测试和黑盒测试.对于开发人员,项目中开发的功能都需要有单元测试能够覆盖到,当新的功能开发完成后,完整的执行一遍单元测试,可以检查对旧功能是否造成影响.同样测试人员也会针对上线功能进行完成测试.

    新能源迁移的功能分支,由于短期内无法上线,这些分支在测试完后,如何处理?

    这些分支在功能开发完成后,就合并到了Develop分支了,提测生成的测试分支,由于暂时无法上线,暂时不要合并到主干,可以先合并回Develop分支.

    新能源功能已经开发完成了,这个时候合并到了Develop,这个时候小宇睿联的又有新的需求需要开发,由于新能源短期内无法上线,目前线上的环境是小宇睿联的功能,如何处理?

    这种情况,建议从Master里拉出Bug分支进行开发,流程参考Fix-bug.

    Github flow工作流简介

    Github flow 是Git flow的简化版,专门配合"持续发布"。它是 Github.com 使用的工作流程。

    流程

    它只有一个长期分支,就是master,因此用起来非常简单。

    官方推荐的流程如下。

    image.png

    第一步:根据需求,从master拉出新分支,不区分功能分支或补丁分支。

    第二步:新分支开发完成后,或者需要讨论的时候,就向master发起一个pull request(简称PR)。

    第三步:Pull Request既是一个通知,让别人注意到你的请求,又是一种对话机制,大家一起评审和讨论你的代码。对话过程中,你还可以不断提交代码。

    第四步:你的Pull Request被接受,合并进master,重新部署后,原来你拉出来的那个分支就被删除。(先部署再合并也可。)

    扩展讨论

    1. 如何将现有代码切换过来
    2. 如何培训推广

    GEMINI修改分支样例

    迁移前分支状况

    master 最新迭代分支

    pro 生产环境分支

    fat 测试环境分支

    5m 5米微循环分支

    迁移计划

    1.从master新建一个develop分支

    |

    <pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;">git checkout master
    git checkout -b develop</pre>

    |

    2.把master分支重置到pro分支的分叉处,我的项目里查到的分叉处commit为 af8ac1ef66f3e2c932623eecd71296e19a2c2e9c

    |

    <pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;">git.exe reset --hard af8ac1ef66f3e2c932623eecd71296e19a2c2e9c
    git.exe merge remotes/origin/pro</pre>

    |

    最终达到的效果:

    1. master分支指向到了origin/pro
    2. develop分支指向到了最新代码
    image.png image.png

    参考文档

    Git工作流程

    A successful Git branching model

    Understanding the GitHub flow

    GitHub Flow

    相关文章

      网友评论

          本文标题:版本控制系统(GIT)分支管理规范

          本文链接:https://www.haomeiwen.com/subject/eclcyqtx.html