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.1、v1.0.0-beta.2，或v1.0.0-200910-beta等。