工作流

期待的工作流。

使用多分支（branch）开发，用标签（tag）作为定义版本，所以依据tag部署程序。

想办法看明白我表达的想法
指出文章描述不清晰的地方
指出我的误区
提出你的建议

---

• Git工作流
  • 5种场景（操作）
  • 5种场景分别对应5种分支（branch）
  • 5种场景分别对应5种tag部署
  • 5种场景分别对应5个“流程图”
• 部署流程

Git工作流

Git工作流将“开发”规范为5种场景（操作），并提供每种场景的流程图。

既然是5种规范的场景，理论可以实现5个脚本规范“开发者”的操作。

5种场景（操作）

1. 开发“新功能”
2. 修复“不紧急bug”
3. 集成代码&测试（长期集成场景1，场景2，场景4的代码）
4. 修复“紧急bug”（需要立即发版）
5. 集成代码&上线“新版本”（集成场景3，场景4的代码，打稳定版tag）

5种场景分别对应5种分支（branch）

1. 开发“新功能” -> feature-x
   • 临时分支。
   • 开发“新功能”。
   • 开发完，并测试后合并到develop分支。
2. 修复“不紧急bug” -> bug-x
   • 临时分支。
   • 修复“不紧急bug”。
   • 修复后合并到develop分支。
3. 集成代码&测试 -> develop
   • 永久分支。
   • 集成（合并）feature-x、bug-x、hotfix-x的代码。
   • 长期测试保证稳定。
   • 规划时间定期发布版本。
4. 修复“紧急bug” -> hotfix-x
   • 临时分支。
   • 修复“紧急bug”。
   • 修复后尽快上线（不等develop分支）。
5. 集成代码&上线“新版本” -> master
   • 永久分支。
   • 集成（合并）develop和hotfix-x的代码。

5种场景分别对应5种tag部署

1. 开发“新功能” -> a.b.c-feature-x.timestamp
   • 部署到测试环境
2. 修复“不紧急bug” -> a.b.c-bug-x.timestamp
   • 部署到测试环境
3. 集成代码&测试 -> a.b.c-alpha.timestamp
   • 部署到测试环境
4. 修复“紧急bug” -> a.b.c-hotfix.timestamp
   • 部署到测试环境
5. 集成代码&上线“新版本” -> a.b.c
   • 部署到生产环境

5种场景分别对应5个“流程图”

下图是一一对应“5种场景”的流程图

gitflow.png

部署流程

依据Git工作流定义的tag部署程序。下图是“部署流程图”

deploy.png