标签：开发者 不能 ase 一个 部署 新功能 ESS 如何 状态
Git是一个很方便的版本管理工具，我所认识的大部分开发者都在使用Git，也正是由于其方便性，如果团队没有一个统一的分支管理策略，那么分支可能会非常混乱，开发者将因此花费额外的时间处理这方面的问题。在搜索引擎上搜索分支管理策略，大部分都指向Vincent Driessen提出的策略。我这里也记录一下，万一以后让公司让我写规范文档或者面试中问到，能够说的清楚系统一些。
这个策略将分支分为了两个部分:
主要分支有两个，长期存在。
Master是用于部署生产环境的分支，有且只有一条。一般由develop分支合并，任何时间都不能直接修改代码。
develop 为开发分支，始终保持最新完成以及bug修复后的代码；
当develop分支的源码到达了一个稳定状态待发布，所有的代码变更需要以某种方式合并到master分支，然后标记一个版本号（TAG）。所以，每次变更都合并到了master，这就是新产品的定义。在这一点，我们倾向于严格执行这一点，从而，理论上，每当对master有一个提交操作，我们就可以使用Git钩子脚本来自动构建并且发布软件到生产服务器。
辅助性分支有三个，用后即删。
开发新功能时，以Develop为基础创建feature分支，开发完成后，要再并入Develop。
分支命名: feature/ 开头的为特性分支；
命名规则: feature/user_module、 feature/cart_module；
release 为预上线分支，发布提测阶段，会release分支代码为基准提测；Release分支可能从develop分支分离而来，但是一定要合并到develop和master分支上，一般命名方式为：release/*。
当有一组feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支。如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。当测试完成之后，合并release分支到master和develop支， 此时master为最新代码，用作上线。
分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似，线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支；
规则的一个例外是： 如果一个release分支已经存在，那么应该把hotfix合并到这个release分支，而不是合并到develop分支。当release分支完成后， 将bugfix分支合并回release分支也会使得bugfix被合并到develop分支。（如果在develop分支的工作急需这个bugfix，等不到release分支的完成，那你也可以把bugfix合并到develop分支）。
这个管理策略的已经非常好了，可以直接拿来用，但是也没有必要完全照搬照抄，可以在此基础上或增或减，适合自己的项目和团队的才是最好的。用好分支管理，能够有效的提高版本管理的质量和效率，同时培养开发者思维习惯，让开发过程更优雅。
标签：开发者 不能 ase 一个 部署 新功能 ESS 如何 状态
原文地址：https://www.cnblogs.com/hanstrovsky/p/13192834.html
