期待的工作流。
使用多分支（branch）开发，用标签（tag）作为定义版本，所以依据tag部署程序。
想办法看明白我表达的想法
指出文章描述不清晰的地方
指出我的误区
提出你的建议
Git工作流
Git工作流将“开发”规范为5种场景（操作），并提供每种场景的流程图。
既然是5种规范的场景，理论可以实现5个脚本规范“开发者”的操作。
5种场景（操作）
- 开发“新功能”
- 修复“不紧急bug”
- 集成代码&测试（长期集成场景1，场景2，场景4的代码）
- 修复“紧急bug”（需要立即发版）
- 集成代码&上线“新版本”（集成场景3，场景4的代码，打稳定版tag）
5种场景分别对应5种分支（branch）
- 开发“新功能” ->
feature-x- 临时分支。
- 开发“新功能”。
- 开发完，并测试后合并到
develop分支。
- 修复“不紧急bug” ->
bug-x- 临时分支。
- 修复“不紧急bug”。
- 修复后合并到
develop分支。
- 集成代码&测试 ->
develop- 永久分支。
- 集成（合并）
feature-x、bug-x、hotfix-x的代码。 - 长期测试保证稳定。
- 规划时间定期发布版本。
- 修复“紧急bug” ->
hotfix-x- 临时分支。
- 修复“紧急bug”。
- 修复后尽快上线（不等
develop分支）。
- 集成代码&上线“新版本” ->
master- 永久分支。
- 集成（合并）
develop和hotfix-x的代码。
5种场景分别对应5种tag部署
- 开发“新功能” ->
a.b.c-feature-x.timestamp- 部署到测试环境
- 修复“不紧急bug” ->
a.b.c-bug-x.timestamp- 部署到测试环境
- 集成代码&测试 ->
a.b.c-alpha.timestamp- 部署到测试环境
- 修复“紧急bug” ->
a.b.c-hotfix.timestamp- 部署到测试环境
- 集成代码&上线“新版本” ->
a.b.c- 部署到生产环境
5种场景分别对应5个“流程图”
下图是一一对应“5种场景”的流程图
gitflow.png
部署流程
依据Git工作流定义的tag部署程序。下图是“部署流程图”
deploy.png
