分支规范

• 分支规范

  每个公司都有自己的开发规范，其中代码工程的分支管理非常重要，好的规范能让团队协作变的更清晰，提升工作效率。

  00、分支定义
  开发分支：feature
  测试分支：feature
  发布分支：release
  紧急分支：hotfix
  主分支：master
  开发检出分支：develop

  01、分支依赖关系

  还是那句话：每个公司，每个团队都有自己的一套分支定义和管理规范。
  微云北京研发团队，在分支定义上，也遵循 Git-Flow 行业规范，国内的头部互联网公司，基本都是按这个规范来的。
  但是在分支发布上线的流程上，微云有所不同。
  这个不同，在遵守 Git-Flow 的分支依赖规范基础上，基于实际的【开发->测试->发布】流程，定义了微云自己的流程。

  普通的发布流程是：feature -> release -> master，线上环境永远是 master 分支。
  一旦产生代码回退，只能在 master 上执行。而 master 分支是主分支，我们要尽可能的保证它是干净的，没有 bug 的，毫无分支错乱疑义的。若频繁的 reset 操作，不可避免会受到污染，且依赖 master 检出的 hotfix 分支，也将处于危险中。
  虽然熟练 git 的技术人员可以完成基于 master 的回退。但此类事情的必然出现，会产生管理和维护成本。

  我们稍微调整了下发布流程：feature -> release 或 master -> hotfix 。
  生产环境只会部署 release 或 hotfix 分支。
  当产生代码回退，只需要在当前 release 或 hotfix 分支操作即可。
  当 release、hotfix 发布成功一段时间后，再将他们 finish 操作，干净和无疑义的代码将合并到 master 分支。