开发笔记(3):GitFlow前端

Git分支模型(Git Branching Model)

feature  develop   relese     hotfixes   master
branchs    |       branchs       |          |
|          |          |          |          |
|          |          |          |          |Tag 0.1
|          |          |          |          |
|          |          |          |          |Tag 0.2
|          |          |          |          |
|          |          |          |          |

Git Flow工作流程详解

1. master分支

• 所有在master分支上的commit都应该打tag
• 注意major和minor版本号区分

        v0.1        v0.2         v0.3          v1.0 
master:   • -------→ • --------→ • --------→ • ---- +∞

2. feature分支

• 分支名feature/*
• feature分支做完后,必须合并develop分支,且合并完成之后一般会删除这个feature分支

        v0.1        v0.2         v0.3          v1.0 
master:   • -------→ • --------→ • --------→ • ---- +∞
          |                                  ↑
          ↓                                  |
develop:  • -------→ • --------→ • --------→ • ---- +∞
          |          |           ↑           ↑
          |          ↓           |           |
feature:  |          • --------→ •           |
          |                                  |
          ↓                                  |
feature:  • -------→ • --------→ • --------→ •

3. release分支

1. 分支名release/(版本号)
2. release分支是基于develop分支创建的,打完release分支之后,我们可以在这个release分支上进行测试,修改bug等.
3. 同时,其他开发人员可以基于此,去开发新的feature分支.
4. 原则是:
5. 打了release分支之后,不要再从develop分支上合并新的改动到release分支.
6. 如果是合并到master分支,记得打个tag记住relese版本号,然后可以删除这个分支了

        v0.1        v0.2         v0.3          v1.0 
master:   • -------→ • --------→ • --------→ • ---- +∞
          |                                  ↑?
release:  |                      • --------→ •     
          ↓                      ↑           ↓?
develop:  • -------→ • --------→ • --------→ • ---- +∞
          |          |           ↑           ↑
          |          ↓           |           |
feature:  |          • --------→ •           |
          |                                  |
          ↓                                  |
feature:  • -------→ • --------→ • --------→ •

4. hotfix分支

1. 分支名hotfix/*
2. hotfix分支基于master分支创建,开发完后需要合并回master和develop分支,同时在master上打一个tag

        v0.1        v0.2         v0.3          v1.0 
master:   • -------→ • --------→ • --------→ • ---- +∞
          |          ↓           ↑           ↑
          |          • --------→ •           |
          |          |                       |?
release:  |          |           • --------→ •     
          ↓          ↓           ↑           ↓?
develop:  • -------→ • --------→ • --------→ • ---- +∞
          |          |           ↑           ↑
          |          ↓           |           |
feature:  |          • --------→ •           |
          |                                  |
          ↓                                  |
feature:  • -------→ • --------→ • --------→ •

5. support分支

1. Git Flow没有真正涵盖support分支,但是如果需要同时维护多个主要版本,则是必不可少的.
2. 同时,也可以使用support分支来支持minor版本.
3. 如果只是支持major,命名support/<major>.x,minor版本为support/<major>.<minor>.x

GIt Flow工具使用

客户端工具

• windows和mac: sourcetree客户端,内置Git Flow流程.
• windows:git bash(git for windows)中内置了gitflow-scripts.
• linux:内置giflow-scripts.

npm工具standard-version

作用

• 作用:1.生成changelog 2.更新package.json和package.lock.json中的version字段.
• changelog只在发版本的时候生成.

注意:Git Flow和standard-versiontag功能的冲突.

• Git Flow和standard-version在使用的过程中,都有自动打tag的功能.但是两者都支持跳过tag阶段.

• 建议两者任选其一:

• 跳过standard-version打tag

• 方法一: package.json

{
  "standard-version": {
    "skip": {
      "tag": true
    }
  }
}

• 方法二:command line

standard-version -r mirror --skip.tag

• 跳过git flow打tag
  • command line

git flow release finish v0.2.0 -n -m "chore(release): 0.2.0"

运行时机

• 场景1: release分支流程中的运行

• Git Flow在release finish阶段是把release/*分支合并到master和develop.
• 所以standard-version就是要在finish结束之前运行生成changelog.

# 1. release开始阶段
git flow release start v0.2.0
# 2. commit并附带message,可以使用git cz替代
git commit -m 'fix(src): 修复问题' 
# 3. (可选) 如果需要在release/* 分支上,生成beta测试阶段的changelog 
npx standard-version -p beta
# 4. standard-version不打tag,使用git flow的tag功能 
npx standard-version -r v0.2.0 
# 5.  release结束阶段
git flow release finish v0.2.0 -m "chore(release): 0.2.0" 
# 如果你使用了standard-version的tag功能，git flow应该跳过tag 
# git flow release finish v0.2.0 -n -m "chore(release): 0.2.0"

• 场景2: hotfix分支流程中运行

与release合并到master和develop一样, 但是是否需要生成hotfix需要审慎决定(因为有可能会存在冲突的风险).

# 1. hotfix开始阶段
git flow hotfix start v0.2.1 
# 2. commit并附带message,可以使用git cz替代 
git commit -m 'fix(src): 修复问题' 
# 3. standard-version不打tag,使用git flow的tag功能
npx standard-version -r v0.2.1
# 为了防止版本号冲突我们可以使用patch自增版本号 
# npx standard-version -r patch 
# 4. hotfix结束阶段
git flow hotfix finish v0.2.1 -m "chore(release): 0.2.1" 
# 如果你使用了standard-version的tag功能，git flow应该跳过tag 
# git flow hotfix finish v0.2.0 -n -m "chore(release): 0.2.1"

standard-version在Git Flow不同流程阶段注意的问题

• 在release流程中注意事项:
  • 原则: 在Git Flow流程中release应该在hotfix之后创建:
  • 场景: release在hotfix之前创建 & hotfix中生成changlog & release中生成beta版的changelog.
  • 问题:
    • 如果在创建release分支之后,出现并修复hotfix并生成了changelog.
    • 那么hotfix finish之后release finish就会造成release合并到master和develop时出现冲突.
  • 解决:
    • 原理: 使release分支包含hotfix内容
    • 方案1: release分支在hotfix之后创建.
    • 方案2: hotfix提取成patch,在release分支上apply.
• 在hotfix流程中注意事项:
  • 场景1: hotfix中生成changelog
  • 注意: 如果release分支在hotfix finish之前建立,会出现release分支一样的问题
  • 场景2: hotfix中不生成changelog
  • 注意: 如果release分支在hotfix finish之前建立,会造成hotfix修复的日志无法出现在changelog中
  • 解决:
    • 原理: 使release分支包含hotfix内容
    • 方案1: release分支在hotfix之后创建.
    • 方案2: hotfix提取成patch,在release分支上apply.
• standard-version不带参数使用:
  • 如果不指定参数直接使用standard-version命令,standard-version会自动分析commit message类型.
  • commit message中,如果包含:
    • patch就累加path,
    • 有feat就自动累加minor,
    • 有break change就自动生成major版本号.
  • 风险较大建议指定参数.