前端小纠结--集成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 flowrelease流程只是把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 flowstandard-version搭配使用

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

git flow流程中standard-version使用

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

git flowstandard-version冲突的tag功能

git flowstandard-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 flowrelease finish阶段是把release/*分支合并到masterdevelop,所以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"
复制代码
  1. hotfix分支流程中运行

hotfix finish阶段和release非常像是把hotfix/*分支合并到masterdevelop但是是否在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-versiongit flow不同流程阶段注意的问题

  1. standard-versionrelease流程中注意事项:

    • 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-versionhotfix流程中注意事项:

    • 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

你可能感兴趣的:(前端小纠结--集成gitflow和standard-version使用)