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

时间 2019-11-17

标签前端纠结集成 gitflow standard version 使用栏目 Git 繁體版

原文原文链接

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

`git flow`工做流对比

Git工做流指南html

`git flow 介绍`

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

关于git flow的使用，请看如下连接，很是多的文章，写的很是好。java

如何正确的使用git flowlinux

git-flow 备忘清单git

git-branching-model 如图github

`git flow`经常使用的分支

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

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应该Tagsegmentfault

`feature`分支

分支名 feature/*windows

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的菜单

`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`运行时机

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. 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`不一样流程阶段注意的问题

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不带参数使用
```
# 若是直接在分支上，使用
standard-version
复制代码
```
若是不指定参数直接使用standard-version命令，standard-version会自动分析commit message类型，若是包含patch就累加patch，有feat就自动累加minor，有break change就自动生成 major版本号，风险较大，建议指定参数。