前端小纠结--集成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/.x，minor版本为support/..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的菜单

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
          }
      }
  }
  复制代码

  # 方法二：命令行中添加参数
  standard-version -r minor --skip.tag
  复制代码

• git flow跳过tag的方法

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

standard-version运行时机

1. 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"
复制代码

2. 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. finish 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不同流程阶段注意的问题

1. 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中的）

     • 如果有更好的方法请告诉我 ~):

2. standard-version在hotfix流程中注意事项：

   • hotfix中生成changelog

     • release分支在hotfix finish 之前建立，会出现在release分支一样的问题

   • hotfix分支不生成changelog

     • release分支在hotfix finish 之前建立，会造成hotfix修复的的日志无法出现在changelog中

   解决方法：

   release 分支包含hotfix内容（release 分支在hotfix之后创建，或者hotfix提取成patch，在release分支上apply）

3. standard-version不带参数使用

   # 如果直接在分支上，使用
   standard-version
   复制代码

   如果不指定参数直接使用standard-version命令，standard-version会自动分析commit message类型，如果包含patch就累加patch，有feat就自动累加minor，有break change就自动生成 major版本号，风险较大，建议指定参数。

建议

工具和流程模型都是根据使用场景，灵活多变的，所以不要局限于工具和流程模型，实践出适合自己的流程模型才是最重要的。

参考

a-successful-git-branching-model

原版git flow scripts弃坑状态不建议使用

原版git-flow-completion

升级版gitflow-avh

升级版git-flow-completion

约定式提交规范

git-flow 备忘清单

git-flow-standard-version

git-flow-conventional-commits

如何正确使用Git Flow

git rebase保持代码树整洁

集中式工作流

功能分支工作流

Gitflow工作流

Forking工作流

comparing-workflows gitflow-examples