分支管理
分支命名
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 # 從dev建立特性分支 (feature/xxx)$: blabla # 開發 (feature/xxx)$: git add xxx (feature/xxx)$: git commit -m 'commit comment' (dev)$: git merge feature/xxx --no-ff # 把特性分支合並到dev 復制代碼修復緊急bug
(master)$: git checkout -b hotfix/xxx # 從master建立hotfix分支 (hotfix/xxx)$: blabla # 開發 (hotfix/xxx)$: git add xxx (hotfix/xxx)$: git commit -m 'commit comment' (master)$: git merge hotfix/xxx --no-ff # 把hotfix分支合並到master，並上線到生產環境 (dev)$: git merge hotfix/xxx --no-ff # 把hotfix分支合並到dev，同步代碼 復制代碼測試環境代碼
(release)$: git merge dev --no-ff # 把dev分支合並到release，然后在測試環境拉取並測試 復制代碼生產環境上線
(master)$: git merge testing --no-ff # 把testing測試好的代碼合並到master，運維人員操作 (master)$: git tag -a v0.1 -m '部署包版本名' #給版本命名，打Tag 復制代碼
日志規范
在一個團隊協作的項目中，開發人員需要經常提交一些代碼去修復bug或者實現新的feature。而項目中的文件和實現什么功能、解決什么問題都會漸漸淡忘，最后需要浪費時間去閱讀代碼。但是好的日志規范commit messages編寫有幫助到我們，它也反映了一個開發人員是否是良好的協作者。
編寫良好的Commit messages可以達到3個重要的目的：
- 加快review的流程
- 幫助我們編寫良好的版本發布日志
- 讓之后的維護者了解代碼里出現特定變化和feature被添加的原因
目前，社區有多種 Commit message 的寫法規范。來自Angular 規范是目前使用最廣的寫法，比較合理和系統化。如下圖：
Commit messages的基本語法
當前業界應用的比較廣泛的是 Angular Git Commit Guidelines
具體格式為:
<type>: <subject> <BLANK LINE> <body> <BLANK LINE> <footer> 復制代碼- type: 本次 commit 的類型，諸如 bugfix docs style 等
- scope: 本次 commit 波及的范圍
- subject: 簡明扼要的闡述下本次 commit 的主旨，在原文中特意強調了幾點 1. 使用祈使句，是不是很熟悉又陌生的一個詞，來傳送門在此 祈使句 2. 首字母不要大寫 3. 結尾無需添加標點
- body: 同樣使用祈使句，在主體內容中我們需要把本次 commit 詳細的描述一下，比如此次變更的動機，如需換行，則使用 |
- footer: 描述下與之關聯的 issue 或 break change，詳見案例
Type的類別說明：
- feat: 添加新特性
- fix: 修復bug
- docs: 僅僅修改了文檔
- style: 僅僅修改了空格、格式縮進、都好等等，不改變代碼邏輯
- refactor: 代碼重構，沒有加新功能或者修復bug
- perf: 增加代碼進行性能測試
- test: 增加測試用例
- chore: 改變構建流程、或者增加依賴庫、工具等
Commit messages格式要求
# 標題行：50個字符以內，描述主要變更內容 # # 主體內容：更詳細的說明文本，建議72個字符以內。 需要描述的信息包括: # # * 為什么這個變更是必須的? 它可能是用來修復一個bug，增加一個feature，提升性能、可靠性、穩定性等等 # * 他如何解決這個問題? 具體描述解決問題的步驟 # * 是否存在副作用、風險? # # 如果需要的化可以添加一個鏈接到issue地址或者其它文檔 復制代碼參考鏈接
作者：VincentSea
鏈接：https://juejin.im/post/5b4328bbf265da0fa21a6820
來源：掘金
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
Git 分支命名規范
分支: 命名: 說明:
主分支 master 主分支，所有提供給用戶使用的正式版本，都在這個主分支上發布
開發分支 dev 開發分支，永遠是功能最新最全的分支
功能分支 feature-* 新功能分支，某個功能點正在開發階段
發布版本 release-* 發布定期要上線的功能
修復分支 bug-* 修復線上代碼的 bug
主分支 Master
首先，代碼庫應該有一個、且僅有一個主分支。所有提供給用戶使用的正式版本，都在這個主分支上發布。
Git主分支的名字，默認叫做 Master 。它是自動建立的，版本庫初始化以后，默認就是在主分支在進行開發。
開發分支 Dev
主分支只用來分布重大版本，日常開發應該在另一條分支上完成。我們把開發用的分支，叫做 Dev
這個分支可以用來生成代碼的最新隔夜版本（nightly）。如果想正式對外發布，就在 Master 分支上，對 Dev 分支進行”合並”（merge）。
Git創建 Dev 分支的命令：
git checkout -b dev master
將 Dev 分支發布到 Master 分支的命令：
切換到 Master 分支
git checkout master
對 Dev 分支進行合並
git merge –no–ff dev
這里稍微解釋一下，上一條命令的–no–ff參數是什么意思。默認情況下，Git執行”快進式合並”（fast-farward merge），會直接將 Master 分支指向 Dev 分支。
使用–no–ff參數后，會執行正常合並，在 Master 分支上生成一個新節點。為了保證版本演進的清晰，我們希望采用這種做法。
功能分支 Feature
功能分支的名字，可以采用feature- * 的形式命名。
創建一個功能分支：
git checkout -b feature-x dev
開發完成后，將功能分支合並到dev 分支：
git checkout dev
git merge –no-ff feature-x
刪除feature分支：
git branch -d feature-x
預發布分支 Release
第二種是預發布分支，它是指發布正式版本之前（即合並到 Master 分支之前），我們可能需要有一個預發布的版本進行測試。
預發布分支是從 Dev 分支上面分出來的，預發布結束以后，必須合並進 Dev 和 Master 分支。它的命名，可以采用release- * 的形式。
創建一個預發布分支：
git checkout -b release-1.2 dev
確認沒有問題后，合並到master分支：
git checkout master
git merge –no-ff release-1.2
對合並生成的新節點，做一個標簽:
git tag -a 1.2
再合並到dev 分支：
git checkout dev
git merge –no-ff release-1.2
最后，刪除預發布分支：
git branch -d release-1.2
修補分支 Bug
最后一種是修補bug分支。軟件正式發布以后，難免會出現bug。這時就需要創建一個分支，進行bug修補。
修補bug分支是從 Master 分支上面分出來的。修補結束以后，再合並進 Master 和 Dev 分支。它的命名，可以采用fixbug- * 的形式。
創建一個修補bug分支：
git checkout -b fixbug-0.1 master
修補結束后，合並到master分支：
git checkout master
git merge –no-ff fixbug-0.1
git tag -a 0.1.1
再合並到dev 分支：
git checkout dev
git merge –no-ff fixbug-0.1
最后，刪除”修補bug分支”：
git branch -d fixbug-0.1
git tag usage
# 添加
git tag -a V0.1.110811 -m"基本部署完成，有BUG待做"
＃刪除
git tag -d V0.1.110811
#推送到遠程
git push origin V0.1.110811
git push –tags
---------------------
作者：扯文藝的猿
來源：CSDN
原文：https://blog.csdn.net/qq_33858250/article/details/81047883
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！