目錄
ー：分支命名
master 分支
- master 爲主分支，也是用於部署生產環境的分支，確保 master 分支穩定性
- master 分支一般由 develop 以及 hotfix 分支合併，任何時間都不能直接修改代碼
develop 分支
- develop 爲開發分支，始終保持最新完成以及 bug 修復後的代碼
- 一般開發的新功能時，feature 分支都是基於 develop 分支下創建的
feature 分支
- 開發新功能時，以 develop 爲基礎創建 feature 分支
- 分支命名: feature/ 開頭的爲特性分支， 命名規則: feature/user_module，feature/cart_module
release分支
- release 爲預上線分支，發佈提測階段，會 release 分支代碼爲基準提測
- 當有一組 feature 開發完成，首先會合併到 develop 分支，進入提測時，會創建 release 分支。
- 如果測試過程中若存在 bug 需要修復，則直接由開發者在 release 分支修復並提交。
- 當測試完成之後，合併 release 分支到 master 和 develop 分支，此時 master 爲最新代碼，用作上線。複製代碼
hotfix 分支
- 分支命名: hotfix/ 開頭的爲修復分支，它的命名規則與 feature 分支類似
- 線上出現緊急問題時，需要及時修復，以 master 分支爲基線，創建 hotfix 分支，修復完成後，需要合併到 master 分支和 develop 分支
二：常見任務（觀察分支名稱）
增加新功能，基於分支快速迭代
(dev)$: git checkout -b feature/xxx_module # 從 dev 建立特性分支 xxx_module ,並轉入對應的特性分支
(feature/xxx_module)$: blabla # 開發，添加代碼
(feature/xxx_module)$: git add xxx # 將開發的代碼添加到暫存區
(feature/xxx_module)$: git commit -m 'commit comment' # 提交暫存區的代碼到本地倉庫
(feature/xxx_module)$: git checkout dev # 從 xxx_module 分支切換至開發者分支 dev
(dev)$: git merge feature/xxx --no-ff # 把特性分支合併到 dev
修復緊急bug
(feature/xxx_module)$: git checkout master # 如果在新功能分支，先切換
(master)$: git checkout -b hotfix/xxx # 從 master 建立並轉到 hotfix 分支
(hotfix/xxx)$: blabla # 開發，添加代碼
(hotfix/xxx)$: git add xxx # 將開發的代碼添加到暫存區
(hotfix/xxx)$: git commit -m 'commit comment' # 提交暫存區的代碼到本地倉庫
# master 分支和 developer 分支都需要合併
(feature/xxx_module)$: git checkout master # 從 xxx_module 分支切換至開發者分支 master
(master)$: git merge hotfix/xxx --no-ff # 把 hotfix 分支合併到 master ，並上線到生產環境
(feature/xxx_module)$: git checkout dev # 從 xxx_module 分支切換至開發者分支 dev
(dev)$: git merge hotfix/xxx --no-ff # 把 hotfix 分支合併到 dev ，同步代碼
項目上線之前 release 測試環境代碼
(master)$: git checkout -b release # 從 master 建立並轉到 release 分支
(release)$: git merge dev --no-ff # 把 dev 分支合併到 release，然後在測試環境拉取並測試
生產環境上線
(master)$: git merge testing --no-ff # 把 testing 測試好的代碼合併到 master，運維人員操作，一般是爲測試好的 release 分支
(master)$: git tag -a v0.1 -m '部署包版本名' # 給版本命名，打Tag
日誌規範
在一個團隊協作的項目中，開發人員需要經常提交一些代碼去修復 bug 或者實現新的 feature。而項目中的文件和實現什麼功能、解決什麼問題都會漸漸淡忘，最後需要浪費時間去閱讀代碼。但是好的日誌規範 commit messages 編寫有幫助到我們，它也反映了一個開發人員是否是良好的協作者。
編寫良好的 Commit messages 可以達到3個重要的目的：
- 加快 review 的流程
- 幫助我們編寫良好的版本發佈日誌
- 讓之後的維護者瞭解代碼裏出現特定變化和 feature 被添加的原因
一般規則爲 【本次提交的主題，可以是優化（optimize）,可以是改 bug（debug）】【如果是修改 bug 後方可以跟禪道，jra 的 bug 編號】【之後可以編寫修改的詳情信息作爲備註】
git 也支持提供這種規則模板可以搜索下。