分支类型：

主分支：master、develop、release 功能分支：hotfix、feature(根据项目实际需要新增)

分支策略规则：

仅master分支承担发布任务，每次发布完成后追加tag（发布日期）。release/hotfix分支测试完成并代码封版后，先进行合并、灰度回归后再进行产线发布。develop、release作为“持续集成”分支。初始化/新建/合并等操作均需由配管（技术经理）完成。

代码提交规则：

所有人每天至少一次向主分支（develop、release）提交代码，除非没有开发新功能或者没有修复bug 每次提交都会触发自动的代码走查、UT、IT等工作 每当任一步骤报错，第一优先解决集成问题

版本命名规则：

release命名格式：“release_1.0.0_yyddmm"Hotfix命名格式："hotfix_1.0.1_yyddmm"复制代码

分支类型详细说明：

主分支：

中心代码库永远维持着三个主要的分支

master承担发布任务，并跟踪最新产线发布记录（tag）。develop 当前规迭代需求开发release 提测时进行当前迭代的bug修复工作复制代码

功能分支

hotfix 分支feature 分支复制代码

用于帮助团队成员并行处理每次追踪特性、准备发布、快速修复线上问题等开发任务。这些分支的生命周期都是有限的，它们最终都会被删除掉（可选）。每一种分支都有一个特别的目的，并且有严格的规则，诸如起始分支、合并的目标分支等。

release 分支：用于支持常规研发迭代需求测试使用

创建自：develop（代码已提测） 分支命名规范：release1.*.*mmyydd 更新版本依赖（与release版本保持一致） 此分支仅允许修复缺陷的代码提交 测试完成且封版后合并至除其之外的所有动态分支。

hotfix 分支：用于支持紧急需求、产线缺陷修复生产环境发布

创建自：master 分支命名规范：hotfix1.0.*mmyydd（master分支最近发布tag第三位+1） 更新版本依赖（与hotfix版本保持一致） 此分支仅允许紧急需求或生产缺陷的代码提交 测试完成且封版后合并至除其之外的所有动态分支：develop/master（Tag）/release 代码合并后删除分支（可选） 特殊情况说明：

如果此时已经存在了一个 release 分支，那么 hotfix 的改变需要合并到这个 release 分支，而不是 develop 分支。因为把对 bug 的修复合并回 release 分支后，release 分支发布后最终合并至 develop 分支。如果在 develop 分支中立刻需要对该 bug 的修复，且等不及 release 分支合并回来，可以直接合并回 develop 分支。

feature 分支（非必须）：用于支持多迭代并行开发

创建自：develop 必须合并回：develop 分支命名规范：feature1.*.*mmyydd Feature 分支用来开发包括即将发布或远期发布的新特性。Feature 分支生命周期和新特性的开发周期保持同步，但是最终会合并回 develop或被抛弃。Feature 分支通常仅存在于开发者的代码库中，并不出现在 origin 里，除非是长时间存在超过两个版本并行开发的情况。

分支策略参考：

a-successful-git-branching-model