工作流

期待的工作流。

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

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

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
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

推荐阅读更多精彩内容