前端小纠结–集成`gitflow`和`standard-version`使用

请看上一篇前端小纠结–约定式提交和自动生成changelog

`git flow`工作流对比

Git工作流指南

`git flow 介绍`

git flow源自这篇文章a-successful-git-branching-model，大神！！！。

关于git flow的使用，请看以下链接，非常多的文章，写的非常好。

如何正确的使用git flow

git-flow 备忘清单

git-branching-model 如图

`git flow`常用的分支

以下部分内容来自如何正确的使用git flow博客和gitflow-examples

develop : 这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
release/* : 当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
master : 也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release，这个分支只能从其他分支合并，不能在这个分支直接修改
hotfix/* 当我们在生产环境(master)发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
feature/* : 这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release

git Flow如何工作

所有在Master分支上的Commit应该Tag

`feature`分支

分支名 feature/*

Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支

`release`分支

分支名 release/*

Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)

发布Release分支时，合并Release到Master和Develop，同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。

minor版本发布

major版本发布

`hotfix`分支

分支名 hotfix/*

hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag

hotfix修复分支

`support`分支

GitFlow没有真正涵盖support分支，如果需要同时维护多个主要版本，则必不可少。您也可以使用support分支来支持minor版本。如果您只是支持major，命名support/<major>.x，minor版本为support/<major>.<minor>.x

多版本hotfix修复

多版本的release

多版本的git flow的release流程只是把master替换为需要维护的分支。

`git flow`工具的使用

windows和mac建议使用sourcetree客户端，内置了git flow流程，具体的使用方法，请自行搜索.

当然windows下的git for windows(git bash中)也内置了gitflow-scripts，请参考升级版git-flow-completion完成自动补全功能

如果使用linux，内置了gitflow-scripts（不知道是那个版本），很不负责任的建议使用升级版gitflow-avh.

关于使用git flow工具使用可以参考如何正确使用Git Flow这篇博客文章

sourcetree-git-flow

上图是sourcetree中git flow的菜单

`git flow`和`standard-version`搭配使用

请务必在熟悉git flow的基础上集成使用standard-version，因为两个工具的使用不当，会造成冲突。

`git flow`流程中`standard-version`使用

standard-version的作用就是生成changelog更新package.json和package.lock.json中的version字段。所以它在git flow中使用受git flow的流程限制。
目前我的经验是只能在git flow的release/*和hotfix/*分支中使用。
因为只有这两个分支涉及到发版流程，而changelog只有在发版时刻才生成。

`git flow`和`standard-version`冲突的tag功能

git flow和standard-version在使用的过程中，都有自动打tag的功能，但是两者都支持跳过tag阶段，所以这也是这两个工具冲突的地方，建议从两者中选取其一。

强烈推荐 standard-version 自动 tag，不推荐使用git flow的tag功能

使用git flow自动tag必须保证tag格式standard-version能够识别，standard-version使用git-semver-tags解析tag，参考git-semver-tags支持的格式

如果standard-version识别tag出现遗漏，会造成生成的changelog内容重复。standard-version默认的tag前缀是v，可以自定义。

standard-version跳过tag方法

// 方法一： package.json添加配置
{
    "standard-version": {
        "skip": {
            "tag": true
        }
    }
}

1 2	# 方法二：命令行中添加参数 standard-version -r minor --skip.tag

git flow跳过tag的方法

1 2	# 跳过tag，并且可以自定义commit message(为了让commit message符合约定提交的格式规范) git flow release finish v0.2.0 -n -m "chore(release): 0.2.0"

`standard-version`运行时机

release 分支流程中运行

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

# 1. 模拟一个release流程
git flow release start v0.2.0

# 2. 做一些修改或者commit
git commit -m 'fix(src): 修复问题'

# 3. （可选）如果需要在release/* 分支生成beta测试阶段的changelog
npx standard-version -p beta

# 4. release finish 之前
# 强烈推荐 standard-version 自动tag，不推荐使用git flow的tag功能
npx standard-version -r v0.2.0

# 5. 正式发布release，自定义commit message为了符合约定式提交的格式
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"

hotfix分支流程中运行

hotfix finish阶段和release非常像是把hotfix/*分支合并到master和develop，但是是否在hotfix分支生成changelog还需要自行决定（有冲突的风险）

# 1. 模拟一个hotfix流程
git flow hotfix start v0.2.1

# 2. 做一些修改或者commit
git commit -m 'fix(src): 修复问题'

# 3. hotfix finish 之前
# 强烈推荐 standard-version 自动tag，不推荐使用git flow的tag功能
npx standard-version -r v0.2.1 
# patch版本号可以使用 patch 替代
# npx standard-version -r patch

# 正式发布hotfix，自定义commit message为了符合约定式提交的格式
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`不同流程阶段注意的问题

standard-version在release流程中注意事项：
- release中生成beta版本的changelog
  前置条件：
  - release 在hotfix之前创建
  - hotfix中生成changelog
  - release中生成beta版的changelog
  release分支的创建时机很重要，git flow流程中release在hotfix之后创建
  
  如果创建release分支之后，出现并修复hotfix并且在hotfix生成changelog，hotfix finish之后release finish就会造成release合并到master和develop时出现冲突.
  
  解决方案：
  
  release 分支包含hotfix内容（release 分支在hotfix之后创建，或者hotfix提取成patch，在release分支上apply）（git flow流程中hotfix是包含在next release中的）
  - 如果有更好的方法请告诉我 ~):
standard-version在hotfix流程中注意事项：
- hotfix中生成changelog
  - release分支在hotfix finish 之前建立，会出现在release分支一样的问题
- hotfix分支不生成changelog
  - release分支在hotfix finish 之前建立，会造成hotfix修复的的日志无法出现在changelog中
解决方法：

release 分支包含hotfix内容（release 分支在hotfix之后创建，或者hotfix提取成patch，在release分支上apply）
standard-version不带参数使用
1
2
# 如果直接在分支上，使用
standard-version
如果不指定参数直接使用standard-version命令，standard-version会自动分析commit message类型，如果包含patch就累加patch，有feat就自动累加minor，有break change就自动生成 major版本号，风险较大，建议指定参数。