永恒的码流

万物皆流，无物常驻

0%

版本管理之GitFlow

发表于 更新于 分类于

一个基于Git的分支管理策略。
注意：Git Flow并没有涵盖开发流程中的所有步骤，其中不包含代码审查等，这些步骤需要另外处理。

结构示意与说明

Git Flow

Git Flow包含两个永久性分支（master和develop）和三类暂时性分支（feature、release和hotfix）

  1. master分支。用于发布版本。每次发布版本后都需要建立一个tag，如0.10、0.11、1.0等。
  2. develop分支。从master分出来的，所有的开发都在这个分支上做。
  3. feature分支。从develop分出来的，开发特定的功能，开发完后合并到develop，并删除该分支。命名格式feature-*。
  4. release分支。从develop分出来的，预发布分支。用于发布版本之前的测试，测试无误后合并到develop和master，最后删除该分支。命名格式release-*。
  5. hotfix分支。从master分出来的，修补bug分支。用于修补已经发布的版本的bug，修补分支确认无误后，合并到develop和master，最后删除该分支。命名格式hotfix-*。

流程与操作

  1. 创建develop分支。创建Git项目后默认会创建master分支，在master上创建并切换到develop分支

    1
    $ git checkout -b develop

  2. 开发功能。创建并切换feature分支，开发完后合并到develop，最后删除feature。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    # 创建并切换feature分支
    $ git checkout -b feature-x develop
    $ git add .
    $ git commit -m "xxx"

    # 合并到develop分支
    $ git checkout develop
    $ git merge --no-ff feature-x -m "xxx"

    # 删除 feature
    $ git branch -d feature-x

  3. 发布版本。创建并切换release分支，测试无误后，合并到develop和master。在master打tag并发布版本。最后删除release。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    $ git checkout -b release-1.2 develop
    $ git add .
    $ git commit -m "xxx"

    # 合并到 master
    $ git checkout master
    $ git merge --no-ff release-1.2 -m "xxx"
    $ git tag -a 1.2

    # 合并到 develop
    $ git checkout develop
    $ git merge --no-ff release-1.2 -m "xxx"

    # 删除预发布分支
    $ git branch -d release-1.2

  4. 修复bug。在上次发布的1.2版本中发现了一个bug，必须修复。创建并切换hotfix分支，测试无误后，合并到develop和master。在master打tag并发布版本。最后删除hotfix。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    $ git checkout -b hotfix-1.2 master
    $ git add .
    $ git commit -m "xxx"

    # 合并到 master
    $ git checkout master
    $ git merge --no-ff hotfix-1.2 -m "xxx"
    $ git tag -a 1.2.1

    # 合并到 develop
    $ git checkout develop
    $ git merge --no-ff hotfix-1.2 -m "xxx"

    # 删除hotfix
    $ git branch -d hotfix-1.2

实践心得

之前有一个项目由我和另外两个小伙伴开发，使用了Git Flow策略，代码托管在GitLab上。项目包含master分支、develop分支、三个功能分支（每人一个）。部分心得如下：

  1. 功能分支的划分问题。创建功能分支的时候是按照业务逻辑大致划分的，并没有仔细分出他们的边界，最后导致功能分支之间有部分耦合，如feature-a和feature-b有部分逻辑依赖于feature-c。这样的话，feature-c需要经常合并到develop分支，合并后，其他两个分支需要将develop合并到自己的分支上，以更新代码。这与以上的功能分支合并策略有部分出入。Git Flow策略对于功能分支的划分是很理想的，要求多个并行开发的功能分支之间没有关联，但如果划分不仔细就难以做到这点。因此，对于功能分支的划分需要考虑周全，尽可能划分得小，减少耦合。
  2. 分支权限控制。我将master分支和develop分支设置为受保护的，其他两个小伙伴没有权限在这两个分支上做提交。当他们想要把功能分支合并到develop上时，需要在GitLab上提交Merge Request，经常代码审核后由我来合并代码，这样可以发现部分逻辑bug以及保证代码规范。
  3. 每次提交都应该是一个比较完整的功能点：比如优化某个方法、增加一个界面、删除一个接口等。
  4. 每次提交前，检查更改的文件，不要更改与自己无关的文件。不要随意格式化他人代码。
  5. 分支的删除。开发者自己创建的短期分支，在合并以及测试无误后，需要及时删除 
1
2
3
4
5
6
7
8
// 查看所有分支 
git branch -a 
// 删除本地
git branch -d <分支名> 
// 删除远程 
git push --delete origin <分支名> 
// 刷新本地索引 
git fetch --all —prune

参考

  1. 阮一峰-Git分支管理策略
  2. A successful Git branching model