gitflow工做流

1. 工做流程

项目开始（master、develop）

1. 开发组长，基于master主干建立develop分支。master和develop就做为仓库的两个主干，而且将它们的加权限限制，只有管理员可修改。

开发阶段（master、develop、feature）

1. 基于develop建立多个feature分支（如：feature/login），对应功能模块的开发人员，基于该分支开发新功能。
2. 开发人员，测试新功能完成之后，在git上发起pull request把代码合并到到develop分支上。
3. 开发组长，在确认代码没有问题后，经过该pull request 的合并请求。当全部的功能都开发完了，全部的feature分支都合并到develop上。

测试阶段-开始测试（master、develop、release）

1. 开发组长，基于develop分支建立一个release预发布分支（如：release/1.0.0)，并设置release分支只有管理员有权限修改。
2. 基于release/1.0.0分支的代码进行测试。

测试阶段-测试中（master、develop、release、bugfix）

1. 当测试发现bug时，基于当前release/1.0.0分支建立bugfix分支（如：bugfix/问题编号），开发人员基于该bugfix分支进行bug修复。
2. 开发人员在bug修复后，向release/1.0.0分支提交 pull request 申请。
3. 开发组长在确认bug修复完成后，经过该pull request 的合并请求。全部bug修复完成后，当前release版本下，全部bugfix分支都合并到release/1.0.0上。

测试阶段-测试完毕（master、develop、tag）

1. 开发组长发起pull request，把release/1.0.0代码合并到到master分支上。
2. 基于master分支建立一个里程碑版本(tag)名为1.0.0-Release，而且在github上发布一个Release，能够将当前master代码以及相关包存档。
3. 原则上只需保留master、develop两个分支，和1.0.0-Release里程碑版本（tag）。删除完成使命的其余分支：多个feature分支、多个bugfix分支和release/1.0.0。

线上bug-master（master、develop、hotfix）

1. 线上版本出现bug，能够基于最新版本（master）进行修复，能够基于master建立hotfix分支（如：hotfix/问题编号），开发人员基于该hotfix分支进行bug修复。
2. 开发人员在bug修复后，向master分支提交 pull request 申请。
3. 开发组长在确认bug修复完成后，经过该pull request 的合并请求。基于master分支建立一个里程碑修复版本(tag)，假如当前版本为1.2.0-Release，则修复版本为1.2.1-Release。

线上bug-历史版本（master、develop、tag、hotfix）

1. 用户基于某个里程碑版本tag（如：1.0.0-Release）提出bug，建立一个issue。若是master版本已经发布到1.0.0之后了（如：1.2.0-Release），可是该bug修复只能基于历史的1.0.0修复，就须要基于该里程碑版本(tag)1.0.0-Release，建立一个release/1.0.1分支，和hotfix分支（如：hotfix/问题编号），开发人员基于该分支修复bug。
2. 开发人员在bug修复后，向release/1.0.1分支提交 pull request 申请。
3. 开发组长在确认bug修复完成后，经过该pull request 的合并请求。基于release/1.0.1分支建立一个里程碑修复版本(tag)，名为1.0.1-Release。

示例代码（release/*）

# 开始 release

git checkout -b release/0.0.1 develop

# 完成 release

git checkout master

git merge --no-ff release/0.0.1

git push

git checkout develop

git merge --no-ff release/0.0.1

git push

git branch -d release/0.0.1

git push origin --delete release/0.0.1 

# 合并master/devlop分支以后，打上tag 

git tag -a v0.1.0 master

git push --tags

2. 分支说明

master

• master 分支为主分支，用于部署生产环境，须要确保master分支的稳定性。
• 此分支属于只读分支，只能从 release或hotfix 分支合并过来，任什么时候候都不能在此分支修改代码。
• 全部向master分支的推送，都要打上tag标签记录，方便追溯。
• 此分支只能前进，不能有回退操做。

develop

• develop 为开发环境主干分支，基于 master 分支检出。
• 此分支为只读分支，只能从master、release、feature分支合并过来，任什么时候候都不能在此分支修改代码。
• 此分支只能由开发人员提交 pull request（须要 code review），或者由管理员 merge release 分支。
• 在一个 release 分支没有建立出来时，develop 分支不能合并不包含 release 功能范围的 feature 分支。develop 分支在特殊状况下能够回退版本。

release/*

• release 分支为预上线分支，基于 develop 或 master 分支检出。用于准备发布新阶段版本或者修复线上bug版本。
• 此分支用于上线前bug测试，文档生成和其余面向发布任务。
• 此分支属于只读分支，只能由 master 分支或者 develop 分支检出，或者从 bugfix 分支、hotfix 分支合并过来，任什么时候候都不能在此分支修改代码。
• 此分支属于临时分支，在发布提测阶段，会以 release 分支代码为基准提测。当 release 分支测试验证经过后，最终会先被合并到 master 分支（发布新版本或者修复线上bug，要打tag标签），再被合并到 develop 分支（使其与 master 分支保持一致），最后删除此分支。
• 命名：release/<版本号>（例：release/1.0.0）

feature/*

• feature 分支为功能开发分支，由开发人员基于 develop 分支建立 feature/<功能模块> 分支。
• 此分支用于新功能开发，一个 feature 分支最大粒度只能到模块。
• 此分支为临时分支，最终会被合并到 develop 分支（新增功能），或者删除（放弃功能）。
• 此分支一般仅存在于开发人员本地存储库中，而不存在与远程origin。
• 一个新功能开发完成后，且在开发集成环境自测经过、单元测试经过、Sona扫描经过后，才能向 develop 分支提交 pull request （须要 code review）。

bugfix/*

• 预上线 bug 修复分支，基于 release 分支检出。
• 此分支用于上线前bug修复。
• 此分支属于临时分支，当提测阶段中存在 bug 须要修复，由开发人员基于 release 分支建立 bugfix/<bug名字> 分支，而后在 bugfix/<bug名字> 分支进行修复 bug 。 bug 修复完成后，而且在开发集成环境自测经过、单元测试经过、Sona扫描经过后，再向 release 分支提交 pull request 申请。bug修复完成 release 分支测试经过以后可删除此分支。

hotfix/*

• 生产环境 bug 修复分支，基于 master 分支检出。
• 属于临时分支，当生产环境出现 bug ，管理员基于 tag 建立 hotfix/<bug名字> 分支、 release/<版本号> 分支，由开发人员在hotfix分支修复bug，修复完成后，而且在开发集成环境自测经过、单元测试经过、Sona扫描经过后，再向 release 分支提交 pull request 申请。bug修复完成上线以后可删除此分支。

总结

• 只有 master 和 develop 两个分支是主干分支，一直存在的。其余分支都是功能性分支，在完成历史使命后会，能够被删除。
• master、develop 和 release/* 三种分支是被锁住的只读分支，只有管理员有权限修改。只能合并，不能直接提交，其余人想要合并只能提交 pull request。

3. 版本号

在前文不少地方都涉及到版本号，例如：release/* 分支、提交tags和发布Release版本等，版本号的命名也须要有必定的规范。

版本号（公开）

对外正式发布的版本号，通常只须要经过三位数字的版本号：主版本号.次版本号.修订号：

• 主版本号：作了一些不兼容的API修改，能够理解为一个大的产品更新。
• 次版本号：新增了一些功能，能够理解为合并了一个feature。
• 修订号：修复了一些bug，能够理解为合并了一个hotfix。

版本号（测试）

假如咱们想要发布 1.0.1 版本，在开发团队内部，可能会提交屡次的测试版本，交付给测试人员测试。这时候须要基于 1.0.1 版本号后面，加上一些其余的版本号。

• alpha：内测版，通常不向外部发布，bug会比较多，功能也不全，通常只有测试人员使用。
• beta：公测版，该版本仍然存在不少bug，但比alpha版本稳定一些。这个阶段版本还会不断增长新功能。
• RC：发行候选版本，基本再也不加入新的功能，主要修复bug。是最终发布成正式版的前一个版本，将bug修改完就能够发布成正式版了。
• Release：正式发布版，官方推荐使用的版本。在正式发布的时候，能够不加Release，即 1.0.1 等同于 1.0.1-Release

可能基于这些版本号还有更细致的划分，这个能够根据实际项目状况调整。例如：v1.0.0-beta.一、v1.0.0-beta.2，或v1.0.0-200910-beta等。