技术团队代码分支管理指南

2021年02月24日 阅读数:5
这篇文章主要向大家介绍技术团队代码分支管理指南,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

该篇文章最先发表在 LeanCloud 开发资源并发

介绍

这是咱们团队的 Git 分支管理规范。每一个人对工具的使用每每各有偏好,各类方法各有利弊,无所谓对错。但涉及团队协做的方面须要有一些一致的规范,因此请你们务必遵照。工具

除了一致性以外,这个规范的目的是如下几点:测试

  • 确保能够轻易肯定特定时间发布或运行的版本。在新发布的程序存在重大缺陷时,能够尽快 rollback 到上一个稳定版本。ui

  • 在须要修复紧急 bug 并尽快发布时,能够只发布必要的 bugfix 而不一样时发布还不该发布的其余改动。orm

branch 和 tag

每一个官方的 repo(leancloud/ 下的都是官方 repo)有且仅有如下的 branch 和 tag。资源

Branch: masterrelease。其中 master 对应目前的开发分支,全部的 pull request 都应该发到这个分支。release 是当前发布的分支,在这个分支只能增长从 master cherrypick 过来的 commit。详见本文后面的说明。开发

Tag: 对应每一个发布版本的 tag。SDK 和应用程序的 tag 遵守 <major>.<minor>.<patch> 的命名,如 2.5.1;服务端程序的 tag 以发布的日期命名,如 2014.11.13,若是有 bugfix,则在后面增长小写字母,如 2014.11.13 后是 2014.11.13a,而后是 2014.11.13b部署

目前还有部分 repo 包含多个独立部署的项目(如 uluru-platform)。在这样的 repo 打 tag 时须要附上项目名作前缀,如 bigquery-2.5.1。但咱们须要逐步把这些项目拆分到独立的 repo。get

发布新版流程

  • 确保全部要发布的 pull request 都已经 merge 到 masterleancloud

  • 使用 master branch 的代码进行测试,若是发现 bug,把对应的 bugfix merge 到 master

  • 删除旧的 release branch,并从当前的 master 建立新的 release branch;

  • 在 Jenkins 上从 release branch 发起新的 build 并发布;

  • 发布完成后在当前的 release branch 打上对应版本的 tag。

Bugfix 流程

这里的 bugfix 指的是修复已经发布的程序(release branch)中的缺陷。master 里的 bug 请直接 merge bugfix 到 master

  • 若是此缺陷在 master 中还存在,请先 merge bugfix 到 master,不然跳到下一步;

  • release branch 从 master cherrypick 修复该缺陷的一个或多个 commit;

  • 在 Jenkins 上发布当前 release branch;

  • 发布完成后在当前的 release branch 打上递增的 tag。好比,若是上一个 tag 是 2.5.1,这个 tag 应该是 2.5.2;若是上一个是 2014.11.13,这个就是 2014.11.13a

其余

并非每一个 bug 都有专门发布 bugfix 版的必要,对于不紧急的 bug,能够在 master 里 fix 后随下一个版本发布。

在一个官方 repo 下只应该有以上说的 branch 和 tag,在开发过程当中使用到的 feature branch 等请都放在我的的 fork,一概经过向 master 发 pull request 的方式给官方 repo 提交代码。介绍