代码分支规范

为了规范代码库分支管理和版本管理,使代码分支及版本结构清晰,方便维护,同时避免出现由于维护造成的错误的版本发布等问题,特推行文中所述代码分支规范。

git-flow 的使用

  1. 方便地实现功能级别的粒度管理,让功能级的回滚更简单。
  2. 很好地隔离同时开发的功能代码,你可以同时本地 start 多个 feature,而新代码之间互不干扰。

双分支代码结构

双分支指项目推进过程中总是保持使用两个主分支:开发分支 (develop)、成品分支 (master)。

开发分支 (develop)

任何开发都必须从 develop 开始。

日常的开发工作都是围绕该分支进行。开发分支上的代码只有在版本发布的时候才会被合并到 master 分支。

本地的 develop 分支,开发人员在上面开发功能并提交,当完成一个完整的功能开发并通过测试时, 才能把代码 push 到远程的 develop 分支。

远程的 develop 分支上的代码,要求在任何时候总是可以通过编译,所以每次把代码 push 到服务器上之前, 需要确保自己的代码已通过编译并测试。远程的 develop 分支的代码会用于项目的自动构建。

成品分支 (master)

该分支上面的代码总是稳定的,成品级的。只有在每次发布新版本的时候,才会从 release 或 hotfix 分支上 把自上个版本开始到现版本的修改移到 master 分支,master 分支通过标签 (tag) 来区分不同的代码版本。 产品的实施人员所面对的总是该分支。

其它辅助分支

  • feature,用于开发新功能的分支,基于 develop,开发完成后 merge 回 develop;
  • release,用于提测发布版本的分支(测试环境用的),用来修复提测 bug。基于 develop 分支, 完成后 merge 回 develop 和 master 分支
  • hotfix,用于修复线上紧急 bug,等不及 release 分支就必须马上上线。基于 master 分支, 完成后 merge 回 master 和 develop 分支。

分支开发流程图

分支开发流程图
Figure: 分支开发流程图

分支命名规范

分支命名不仅关系到分支的管理,而且跟 Jenkins 上自动出包功能也有所关联。 按照下面的规范进行命名,有助于 Jenkins 自动打出相应版本的包,这是很重要的一个环节,必须严格落实。

feature 分支

feature 分支没有具体规定,只要名称跟分支内容一致即可。

feature 分支命名只允许使用英文和下划线。

release 分支

release 分支使用要发布版本的前两位数字来命名。

范例:如果本次提测的版本号为 1.12.0,则相应的 release 分支必须命名为 1.12.0。

release 分支命名不允许使用中文或英文字符。只能出现数字和 . 字符。

hotfix 分支

hotfix 分支使用要发布版本的所有数字来命名。

范例:如果本次提测的版本号为 1.12.33,则相应的 hotfix 分支必须命名为 1.12.33。

hotfix 分支命名不允许使用中文或英文字符。只能出现数字和 . 字符。

更多阅读材料

请参见: Git 分支的最佳实践

results matching ""

    No results matching ""