git workflow 規範

[TOC]

git workflow 規範

概要說明

分支管理和開發流程

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

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

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

• 從 develop 拉一個 feature/dev_xxx 分支，相關開發需求都提交到 dev_xxx 上，開發完了以後，merge 到 develop 部署測試環境

  • dev_xxx 分支合併到 develop 上以後刪除 dev_xxx 分支
  • dev_xxx 分支通常都是臨時功能開發用，合併後就沒有保留的必要了

• develop 分支開發完了之後，基於 develop 分支開一個 release/$version 的分支，部署測試環境驗證ok後，將 release/$version 合併到 master驗證一下，而後打 tag 上線

其餘說明：

• master 分支是最穩定的，在 develop 分支開發穩定後，開一個 release 分支後 merge 到 master 上打tag
• dev_xxx 是功能開發分支，單人協做的時候，通常 merge 就能夠。 若是是多人協做，那麼通常本身本地的分支上開發提交，可是不 push 到遠程，可是每次提交都 rebase 一下遠程的 dev_xxx 分支。兩個好處：
  • git log 的線會好看不少，少不少，看起來更方便
  • 衝突的機率會少不少，rebase 的時候，也不至於把本身的 commit 穿插到別人中，這樣本身以前的 commit 在 rebase 後就是一個新的 commit 時間線

基準規範

基本分支規範

• 首先基於 master 分支建立 develop 分支
• 而後在 develop 分支基礎上開一個 feature/xxx 的分支用來作開發
• 開發完新特性後 merge 到 develop；而且同時刪除 feature/xxx
• develop 開發完了以後，基於 develop 建立一個 release/$version 支；用來 部署到 dev、pre 環境作測試
  • release/$version 的 version 就是版本號名
• 測試 ok 以後，merge 到 master ，而後打 tag 上線

hotfix 規範

• 基於以前release/xxx 檢出新的 hotfix/xxx 分支，而後修復驗證後合併到 er 和 develop 分支
• 而後基於 master 再打 tag 上線

代碼提交

• 提交的信息，所有采用英文
• 經過 commitizen 工具來提交（git cz 代替 git commit）
• 經過 standard-version 作版本發佈和自動生成 Changelog

代碼 code review

• feature/xxx 須要合併到 develop 的時候，經過 gitlab 建立一個 merge request ，而後指定其餘同時或者上級領導，進行代碼合併

• feature/xxx，要求儘量少的代碼提交，當一個小的功能完備後就須要 MR。

  • 若是有大的功能特性，須要分步提交，方便 review

【"歡迎關注個人微信公衆號：Linux 服務端系統研發，後面會大力經過微信公衆號發送優質文章"】