GitFlow驱动的敏捷开发

GitFlow基础

• 分支模型

  Git开发的分支模型已经讲过很多次了，但是实践中仍然有很多误区以及很多没有实现的地方。

  分支模型文章：A successful Git branching model

  

• git flow 初始化

  • 命令行

    git flow init ：初始化一个git本地仓库。

    接着回答几个关于分支的问题。使用默认值即可，直接按回车键。

    $ git flow init
    
    Which branch should be used for bringing forth production releases?
        - master
    Branch name for production releases: [master]
    Branch name for "next release" development: [develop]
    
    How to name your supporting branch prefixes?
    Feature branches? [feature/]
    Bugfix branches? [bugfix/]
    Release branches? [release/]
    Hotfix branches? [hotfix/]
    Support branches? [support/]
    Version tag prefix? []
    Hooks and filters directory? [E:/NEWWORK/h5-inst-system/.git/hooks]

  • IDEA 插件

    Git Flow Integration ：安装插件即可

    

• 分支与常用命令

  • Master

    master分支只有一个。

    master分支上的代码总是稳定的，随时可以发布出去。

    平时一般不在master分支上操作，当release分支和hotfix分支合并代码到master分支上时，master上代码才更新。

    当仓库创建时，master分支会自己创建。

  • Develop

    develop分支只有一个。

    新特性的开发是基于develop分支的，但不直接在develop分支上开发，特性的开发是在feature分支上进行。

    当develop分支上的特性足够多以至于可以进行新版本的发布时，可以创建release分支的。

  • Feature

    可以同时存在多个feature分支，新特性的开发正是在此分支上面。

    可以对每个新特性创建一个新的feature分支，当该特性开发完毕，将此feature分支合并到develop分支。

    创建一个新的feature分支，可以使用以下命令：

    git flow feature start test

    执行以下命令后，feature/test分支会被创建。

    当特性开发完毕，需要将此分支合并到develop分支，可以使用以下命令实现：

    git flow feature finish test

    上面的命令会将feature/test分支的内容merge到develop分支，并将feature/test分支删除。

    feature分支只是存在于本地仓库，如果需要多个人共同开发此特性，也可以将feature分支推送到过程仓库。

    git flow feature publish test

    feature 分支的生命周期持续到特性的开发完毕，当完成特性的开发，你可以使用git的分支管理命令将此feature分支删除。

  • Release

    当完成了特性的开发，并且将feature分支上的内容merge到develop分支上，这时可以开始着手准备新版本的发布，release分支正是作为发布而开设的分支。

    release分支基于develop分支，在同一时间只有一个release分支，其生命周期较短，只是为了发布而使用。

    这意味着，在release分支上，只是进行较少代码修改，比如bug的修复，原有功能的完善等。

    不允许在release分支增加大的功能，因为这样会导致release分支的不稳定，不利于发布的进行。

    当release分支（例如，v.1.0）被创建出来后，develop分支可能正准备另一版本（例如，v.2.0），

    因此，当release分支merge回develop分支时，可能会出现冲突，需要手工解决冲突才能继续merge。

    通过以下命令来创建release分支：

    git flow release start v.1.0

    执行过完上面的命令，release分支release/v.1.0会被创建出来 ，并且切换到该分支。

    当完成release分支功能的完善或者bug的修复后，执行以下命令来完成release分支：

    git flow release finish v.1.0

  • Hotfix

    当发现master分支出现一个需要紧急修复的bug，可以使用hotfix分支。hotfix分支基于master分支，用来修复bug，

    当完成bug的修复工作后，需要将其merge回master分支。

    同一时间只有一个hotfix分支，其生命周期较短。

    可以使用以下命令来创建hotfix分支：

    git flow hotfix start v.1.0

    使用以下命令来结束hotfix分支的生命周期：

    git flow hotfix finish v.1.0

    这句命令会将hotfix分支merge到master分支和release分支，并删除该hotfix分支。
    注意，如果bug修复时，正存在着release分支，那么hotfix分支会merge到release分支，而不是develop分支。

更进一步

git flow + pull request + code review

我们现在做到的流程有：人工的git分支管理+比较随意的分支合并+滞后的code review

或许我们可以尝试一下，一步到位。

使用git flow来管理项目开发，开发完成之后pull request来做分支合并管理，收到request之后对合并的代码进行code review保证质量

流程规范

• Feature分支的周期及流程规范

  当客户产生新需求时，项目负责人应该拆分需求，不同的开发负责不同的任务，建立不同的Feature。

  Feature分支都是基于Dev分支的，当Feature分支开发完成之后，需要测试介入测试。

  说明：对于其他公司来说，可能一个Feature就有好几个在一起开发。我们公司项目比较多，人员比较少。

  可能一个Feature就两个人开发，一个后台+一个前端，但是我觉得任何可以由后台来负责整个Futura，把我自己Futura的进度。

  我们前面遇到的问题就是因为前后没有沟通，现在何不确认一个主次，让后端开发的人员来主动一点，跟进进度，负责Futura。

• Feature合并到Dev

  测试完成之后的Feature分支发pull request到Dev分支，项目负责人做code review并验收。

• Dev工作流

  当所有需求的新特性开发完成之后，测试做回归测试+验收测试，负责人发布版本到RELEASE。

• RELEASE工作流

  预上线版本。

挑战

• 开发人员

  对于开发来说，变化并不大。由原来的自建Futura分支改成了git flow的分支。可能原来的Futura分支会一直保存为邓浩梁分支。

  但是现在每一个Futura都只为功能服务，当某一个功能开发完成之后本Futura就会消失，等待下一个功能建立新的Futura。

• 测试

  测试的任务将会稍微变多一点。第一要测试所有的Futura，第二当所有Futura合并到Dev的时候要回归测试原来的Futura和综合测试最终的Dev。

• 项目负责人

  项目负责人将承担更多的责任，不仅有原来的任务分发，还有自身要参与的项目内容，最后还要负责每一个Futura的质量验收。

可能遇到的问题

• 每个feature都是一个独立的需求（或功能），一定要全部测试通过后才能合并到dev，否则后期就是大家都去dev上开发了。

• 在feature开发过程中发现develop上的代码有bug

  dev分支应该是共有的分支，每一个Futura都是基于dev的。所以每一天开发都应该在早晨pull一下dev。

  如果是周期短的项目，遇到bug情况，dev的开发者应该通知所有Futura的开发者pull代码。

• hotfix 问题,本问题已经讨论过，不在赘述。