526互联

gitflow 使用规范

发布时间 2023-06-02 16:12:24作者: 浅唱z2

Gitflow使用规范

一. 简介

GitFlow 是构建在 Git 上的一个组织软件开发活动的模型, 是在 Git上构建的一项软件开发最佳实践

2010年Vincent Driessen提出了A Successful Git Branching Model分支模型，用来帮助开发人员在大型软件项目中追踪feature，hotfix和release。Gitflow使整个分支模型自动化完成，更加易用。

To conclude, always remember that panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself.

引用Vincent的反思笔记：永远记住不存在灵丹妙药，考虑你的实际情况。不要讨厌它，请自行决定。

二. 分支模型中各分支概念

分支说明

  1. 主分支: master 与 develop 分支为主分支, 是受保护分支, 只有master权限才可以操作, 只接受代码合并, 不接受代码提交
  2. 辅助分支: feature 功能分支, bugfix 功能修复分支, release 发布分支, hotfix 热修复分支均为辅助分支, 完成相应的功能后, 与主分支合并, 并删除当前辅助分支

主分支说明

image-20230602153233880

gitflow 定义了两个主分支, 是长期支持分支, 不会被删除. 主分支只接受代码合并, 不接受代码提交

  1. master 分支

    We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

    master分支上的代码始终指向生产就绪状态, 即生产环境上实际使用的代码.

    master分支规定:

    • 和生产端的代码保持一致
    • 仅在上线前才更新master分支上的代码
    • 每次更新mater, 都需要对其添加tag, 用于发布 或 回滚
    • master分支为保护分支, 不可以直接进行push操作
    • master只可以被 release/ hotfix分支合并, 拒绝其他分支的合并请求

    综上: master分支上的代码, 可以随时部署到生产环境使用

  2. develop分支

    We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.

    develop分支为下一个发布的最新交付代码, 叫做'集成分支', 即 develop分支为主要开发分支, 下个版本的发布应该基于develop分支, 为所以功能的集成分支

    develop分支规定:

    • develop 不能与 master 分支直接交互

文章到目前为止, 我们会产生以下疑问:

  1. develop是开发分支, 但是又不能提交代码, 那么后续应该如何开发?
  2. master 分支是生产分支, develop分支开发完成后, 无法直接交互, 那么生产环境如何更新?
  3. 如果代码不能合并, 功能不能及时上线, 那么后续的开发该怎么进行?
  4. 生产环境如果产生了bug, 又该如何进行修复?

这时候就引出了我们的辅助分支

辅助分支

辅助分支, 是为了辅助团队进行并行开发, 功能追踪, 线上快速修复, 与主分支不同, 这些辅助分支不是长期分支, 功能开发完成后, 就回删除该分支.

这些分支每个都有特定的目的, 必须遵循关于分支的起始分支以及合并目标分支的规则.

辅助分支有:

  • feature 功能分支
  • bugfix 缺陷修复分支(在原文[1]中并未提及，但是avh版本git-flow包含此分支)
  • release 发布分支
  • hotfix 热修复分支
  • support 长期支持分支

image-20230602153311539

  1. feature分支

    【强制】出自：develop分支
    【强制】合并回：develop分支
    【强制】命名规范：/feature/[英文功能名称]

    本质: 只要功能处于开发状态, 他就会存在, 最终会合并会develop分支或者被丢弃

    feature分支规定:

    • 以功能为单位从develop拉一个feature分支
    • 每个feature的分支颗粒要小, 利于快速迭代, 避免冲突
    • 本地测试以及review通过后, 在gitlab发起合并到develop分支的申请
    • 合并前, 先拉取develop分支最新的代码, 然后把最新的develop分支代码合并到本地的功能分支, 然后发起合并申请
    • feature只与develop分支发生交互, 不与master发生交互

    他解决了第一个疑问, 不在develop分支开发功能, 而是在feature分支开发

  2. release分支

    【强制】出自：develop分支
    【强制】合并回：develop和master分支
    【强制】命名规范：/release/[发布版本号]

    发布分支为下一个生产版本，只允许小错误的修复和准备发布的元数据(版本号，发布日志，日期等)的修改。最终发布版本号，在发布分支决定。

    发布分支我们规定:

    1. 生成release分支，首先修改版本号，以区别develop分支的版本
    2. 只存在一个发布分支(需要多版本同时维护时, 可以定义多个发部分支)
    3. 当需要为发布新版做准备时，从develop衍生出一个release分支
    4. release分支也可以从develop分支上指定commit派生出
    5. release分支测试通过后，合并到master分支并且给master标记一个版本号
    6. release分支一旦建立就将独立，不再从其他分支合并代码
    7. 必须合并回develop分支和master分支或废弃

    发布分支解决了我们的第二第三个疑问, master分支通过release分支和develop分支进行交互, 使用release分支, 即可以进行发布前的独立校验, 又可以不影响develop分支的后续开发活动

  3. bugfix 分支

    【强制】出自：develop分支
    【强制】合并回：develop分支
    【强制】命名规范：/bugfix/[bug-英文缺陷名称或者bug编号]

    用于修复develop分支中出现的bug

  4. hotfix 分支

    【强制】出自：master分支
    【强制】合并回：master分支 和 [develop分支 release分支]
    【强制】命名规范：/hotfix/[发布版本号]

    热修复分支, 用于修复生产环境出现的bug.

    当线上版本出现了不得不立即修复的缺陷时，可以从master分支新建热修复分支。修复完成之后，更改版本号，合并回master分支以及develop分支。

    注意，当在热修复之前已经发布了下一个发布版本的时候，此时热修复分支应该合并回master和release分支，release分支完成之后，会把热修复的分支合并回develop分支。

    hotfix分支规定：

    1. hotfix分只用来快速给已发布产品修复bug或微调功能
    2. 只能从master分支指定tag版本衍生出来
    3. 一旦完成修复bug，必须合并回master分支和develop分支
    4. master被合并后，应该被标记一个新的版本号
    5. hotfix分支一旦建立就将独立，不可再从其他分支pull代码

    热修复分支解决了我们上文中提到的最后一个问题, 生产环境中的bug由hotfix分支修复

    以下图片为整个gitflow的模型图[2]

image-20230602160134987

  1. http://nvie.com/posts/a-successful-git-branching-model/ A Successful Git Branching Model ↩︎

  2. 图片引用自: https://www.jianshu.com/p/d46da933c180 ↩︎