GitHub学习记录6

GitFlow工作流实战

在实际项目开发工作中，常常会有自测、联调、提测、线上紧急修复等多工作环节，对应可能需要本地、内测、开发、测试、生产等多环境部署代码的需求，对应每个环节会产生不同的分支。

Git-Flow⼯作流模型原理

  • Git-Flow模型解决什么问题?

    为了解决实际项⽬中代码开发、代码测试、bug修复、版本发布等⼀系过程列严重耦合从⽽产⽣各种问题，如冲突过度、版本混乱。

  • Git-Flow模型⼜是如何解决上述问题的呢?

    基于Git定义5种类型的分⽀，各分⽀严格定义其指责、起⽌点等，从⽽使开发、测试、发版等过程有条不紊进⾏。

Git-Flow流程图

每个角色在某个阶段需要关注的可能也就⼀两个分⽀，⽐如在开发阶段，开发⼈员只需关注⾃⼰的新功能分⽀（Feature分支）；release阶段，测试⼈员和开发⼈员都只需关注Release分⽀，各⾃的职责有所差异⽽已。

Git-Flow各分⽀的说明

分⽀名称 作⽤ ⽣命周期 提交or合并 起⽌点
Feature分⽀ ⽤于某个功能的 临时分 ⽀、开发 阶段 可提交代码 由Develop分⽀产⽣， 最终合并到Develop 分⽀
Develop分⽀ 记录历史开发功 能 贯穿整个 项⽬ 不能提交，由Feature分 ⽀、Bugfix分⽀、Release 分⽀、Hotfix分⽀合并代码 整个项⽬
Release分⽀ ⽤于本次Release 如⽂档、测试、 bug修复 临时分 ⽀、发版 阶段 可提交代码 由Develop分⽀产⽣， 最终合并到Develop 分⽀和Master分支
Hotfix分⽀ ⽤于解决线上bug 临时分 ⽀、紧急 修复阶段 可提交代码 由Master分⽀产⽣， 最终合并到Develop 分⽀和Master分支
Master（Production） 分⽀ 记录历史发布版 本 贯穿整个 项⽬ 不能提交，由Release、Hotfix分⽀合并代码 整个项⽬

不同角度理解各分支

提交代码 由Master分⽀产⽣， 最终合并到Develop 分⽀和Master分支
Master（Production） 分⽀ 记录历史发布版 本 贯穿整个 项⽬ 不能提交，由Release、Hotfix分⽀合并代码 整个项⽬

6.2.3 不同⻆度理解各分⽀

  • ⽣命周期

    Master分⽀和Develop分⽀贯穿项⽬；其他分⽀均为承担特定指责的临时分⽀。

  • 项⽬阶段

    开发阶段主要涉及Feature分⽀、Develop分⽀； 发布阶段 主要涉及Release分⽀、Production分⽀、Develop分⽀； 紧急修复阶段 主要涉及Hotfix分⽀、Production分⽀、Develop分⽀。

  • 成员关注点

    开发⼈员 关注Develop分⽀、Feature分⽀以及特殊阶段关注Hotfix、Release分⽀的bug修复； 测试⼈员 关注 Release分⽀、Hotfix分⽀的功能测试；项⽬经理 关注Production分⽀、Release分⽀。

另外要说明，项⽬阶段在时间纬度有可能重叠.⽐如:release阶段(当前版本)与下各版本的开发阶段可同时存在，因为：

  • 当前release阶段的发起同时也就意味着下⼀个release的开发阶段的开始；⼀旦线上出现bug(任何时候都可能出现)，紧急修复阶段就可能与开发阶段、发版阶段重叠…因此，要求团队成员都要理解Git-Flow⼯作流，以及⾃身所处的项⽬阶段.