1.1 git分支管理规范
git分支管理规范
所有使用了本规范的项目，必须严格规范操作，否则不予以合并代码、提测、打包上线等后续操作。
branch使用规范
分支约定
Git Flow有主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动；辅助分支组织为了解决特定的问题而进行的各种活动 主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和develop分支。
主分支
master分支
master分支存放的是随时可供在生产环境中部署的稳定版本代码
master分支保存官方发布版本历史，release tag标识不同的发布版本
一个项目只能有一个master分支
仅在发布新的可供部署的代码时才更新master分支上的代码
每次更新master，都需对master添加指定格式的tag，用于发布或回滚
master分支是保护分支，不可直接push到远程仓master分支
master分支代码只能被release分支或hotfix分支合并
develop分支
develop 为开发分支，一般包含正在开发的所有新特性
develop分支不能与master分支直接交互
develop分支衍生出各个feature分支
develop分支是保护分支，不可直接push到远程仓库develop分支
一个项目只能有一个develop分支
辅助分支
辅助分支是用于组织解决特定问题的各种软件活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作、以及对版本代码的测试。这些分支与主分支不同，通常只会在有限的时间范围内存在。
辅助分支包括：
用于开发新功能时所使用的feature分支
用于辅助版本发布的release分支
用于修正生产代码中的缺陷的hotfix分支
以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说，这些分支与Git其他分支并没有什么区别，但通过命名，我们定义了使用这些分支的方法。
feature分支
使用规范：
命名规则：
feature/*develop分支的功能分支
feature分支使用develop分支作为它们的父类分支
以功能为单位从develop拉一个feature分支
每个feature分支颗粒要尽量小，以利于快速迭代和避免冲突
当其中一个feature分支完成后，它会合并回develop分支
当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支
feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里
feature分支只与develop分支交互，不能与master分支直接交互
如有几个同事同时开发，需要分割成几个小功能，每个人都需要从develop中拉出一个feature分支，但是每个feature颗粒要尽量小，因为它需要我们能尽早merge回develop分支，否则冲突解决起来就没完没了。同时，当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支。
release分支
使用规范：
命名规则：
release/*，“*”以本次发布的版本号为标识release分支主要用来为发布新版的测试、修复做准备
当需要为发布新版做准备时，从develop衍生出一个release分支
release分支可以从develop分支上指定commit派生出
release分支测试通过后，合并到master分支并且给master标记一个版本号
release分支一旦建立就将独立，不可再从其他分支pull代码
必须合并回develop分支和master分支
release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。 成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。
hotfix分支
使用规范：
命名规则：
hotfix/*hotfix分支用来快速给已发布产品修复bug或微调功能
只能从master分支指定tag版本衍生出来
一旦完成修复bug，必须合并回master分支和develop分支
master被合并后，应该被标记一个新的版本号
hotfix分支一旦建立就将独立，不可再从其他分支pull代码
除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。 当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。 这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。
bugfix分支
修补分支：软件发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补
修补bug分支是从master或release分支上面分出来的。修补结束以后，再合并进master和develop以及release对应版本分支。它的命名，可以采用 fixbug- * （日期）的形式。
分支责任分工
分支
职责描述
master
开发经理 ：统一创建、维护， 运维人员： 部署,
develop
开发经理 ：统一创建， 开发人员： 维护， 部署
release
开发经理 ： 统一创建、维护， 运维人员：部署
feature
开发人员 ：各模块自行创建、维护
fixbug
开发经理 ：统一创建、部署、维护， 开发人员 ：修复bug，协助解决自动merge中发生的冲突
分支对应的环境
分支
环境
Master/fixbug/hotfix
线上(release环境)
develop
开发(alpha环境)
release
测试(beta环境)，预发布(RC环境)
tag使用规范
版本号(tag)命名规则：
主版本号.次版本号.修订号，如2.1.13。(遵循GitHub语义化版本命名规范)版本号仅标记于master分支，用于标识某个可发布/回滚的版本代码
对master标记tag意味着该tag能发布到生产环境
对master分支代码的每一次更新(合并)必须标记版本号
仅项目管理员有权限对master进行合并和标记版本号
代码提交规范
基本要求
所有commit必须有注释，内容必须简洁明了的描述本次commit涵盖了哪些内容。严禁注释内容过于简单或不能明确表达提交内容的！
合理控制提交内容的颗粒度，一次commit含一个独立功能点。严禁一次提交涵盖多个功能项。
正确为每个项目设置Git提交用到的user.name和user.email信息，以公司邮箱为准，不可随意设置以影响无法正确识别。
git Commit 日志规范
根据 angular 规范提交 commit， 这样 history 看起来更加清晰，还可以自动生成 changelog。
type
提交 commit 的类型，包括以下几种
feat: 新功能
fix: 修复问题
docs: 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等
style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
refactor: 代码重构，没有加新功能或者修复bug
perf: 优化相关，比如提升性能、体验
test: 测试用例，包括单元测试、集成测试等
chore: 改变构建流程、或者增加依赖库、工具等
revert: 回滚到上一个版本
scope
修改文件的范围（包括但不限于 doc, middleware, core, config, plugin）
subject
用一句话清楚的描述这次提交做了什么
body
补充 subject，适当增加原因、目的等相关因素，也可不写。
footer
当有非兼容修改(Breaking Change)时必须在这里描述清楚
关联相关 issue，如
Closes #1, Closes #2, #3如果功能点有新增或修改的，还需要关联文档
doc和egg-init的 PR，如eggjs/egg-bin#123
示例:
查看具体文档
项目权限
Git权限分管理员、开发者、浏览者三种类型
浏览者只能浏览代码，无push、pull request等所有写权限
开发者拥有浏览、push非主分支、提交pull request工单权限
管理员拥有建立和管理Git项目、合并分支和代码、给master打tag版本号等权限
分支使用
每个Git项目固定含有上述所有分支类型。主分支master和develop是保护分支，只能进行合并请求，均不可直接提交代码。
功能需求或常规Bug修复，请从develop拉取feature分支；线上紧急问题修复，请从master拉去hotfix分支。
代码提交
一个提交就代表解决一个问题
大问题适当地分解为多个小问题，以便每次小型提交都更易于理解
最后更新于
这有帮助吗？