前端小糾結--集成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的菜單

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