[TOC]

git workflow 規(guī)范

概要說明

分支管理和開發(fā)流程

• 基本分支： master、develop、release/xxx、hotfix/xxx、feature/dev_xxx

• master/release 分支，用來上線，打tag

• 從 master 分支拉一個 develop 分支，用來開發(fā)演進，合并代碼，最終會 merge 到 master 上

• 從 develop 拉一個 feature/dev_xxx 分支，相關開發(fā)需求都提交到 dev_xxx 上，開發(fā)完了之后，merge 到 develop 部署測試環(huán)境

  • dev_xxx 分支合并到 develop 上之后刪除 dev_xxx 分支
  • dev_xxx 分支一般都是臨時功能開發(fā)用，合并后就沒有保留的必要了

• develop 分支開發(fā)完了以后，基于 develop 分支開一個 release/$version 的分支，部署測試環(huán)境驗證ok后，將 release/$version 合并到 master驗證一下，然后打 tag 上線

其他說明：

• master 分支是最穩(wěn)定的，在 develop 分支開發(fā)穩(wěn)定后，開一個 release 分支后 merge 到 master 上打tag
• dev_xxx 是功能開發(fā)分支，單人協作的時候，一般 merge 就可以。 如果是多人協作，那么一般自己本地的分支上開發(fā)提交，但是不 push 到遠程，但是每次提交都 rebase 一下遠程的 dev_xxx 分支。兩個好處：
  • git log 的線會好看很多，少很多，看起來更方便
  • 沖突的概率會少很多，rebase 的時候，也不至于把自己的 commit 穿插到別人中，這樣自己之前的 commit 在 rebase 后就是一個新的 commit 時間線

基準規(guī)范

基本分支規(guī)范

• 首先基于 master 分支創(chuàng)建 develop 分支
• 然后在 develop 分支基礎上開一個 feature/xxx 的分支用來做開發(fā)
• 開發(fā)完新特性后 merge 到 develop；并且同時刪除 feature/xxx
• develop 開發(fā)完了之后，基于 develop 創(chuàng)建一個 release/$version 支；用來 部署到 dev、pre 環(huán)境做測試
  • release/$version 的 version 就是版本號名
• 測試 ok 之后，merge 到 master ，然后打 tag 上線

hotfix 規(guī)范

• 基于之前release/xxx 檢出新的 hotfix/xxx 分支，然后修復驗證后合并到 er 和 develop 分支
• 然后基于 master 再打 tag 上線

代碼提交

• 提交的信息，全部采用英文
• 通過 commitizen 工具來提交（git cz 代替 git commit）
• 通過 standard-version 做版本發(fā)布和自動生成 Changelog

代碼 code review

• feature/xxx 需要合并到 develop 的時候，通過 gitlab 創(chuàng)建一個 merge request ，然后指定其他同時或者上級領導，進行代碼合并

• feature/xxx，要求盡可能少的代碼提交，當一個小的功能完備后就需要 MR。

  • 如果有大的功能特性，需要分步提交，方便 review