三張圖助你掌握Git分支管理！

一千個項目可能有一千種 Git 分支管理策略。
					——嚴士比亞·北
複製代碼

在不一樣的公司、項目裏跌打滾爬過，你是否每次總在適應團隊各類各樣的 Git 操做規範？做爲測試，若你的工做與持續集成有關，又是否由於不一樣的 Git 規範而頭痛？

即便是本文介紹的分支管理策略，也不必定適合你們的項目，但咱們長期使用下來，通過屢次優化升級，必定不會難用。

研發流程與部署環境

爲何先說研發流程呢？分支一般能夠對應研發流程中不一樣的部署環境：

• tag -> 生產環境（production）
• master -> 預發/灰度環境（pre-production/staging）
• develop -> 測試環境（test）
• feature -> 線下調試/開發環境

有不少同窗分不清預發環境與測試環境區別，預發環境一般數據與線上一致，上線前在該環境用真實數據迴歸全部功能；測試環境一般用來驗收feature。

使用標籤的必要性

不少人用 Git 只使用分支(Branch)，不使用標籤(Tag)。Git 官網對 Tag 的解釋以下：

Like most VCSs, Git has the ability to tag specific points in a repository’s history as being important. Typically, people use this functionality to mark release points (v1.0, v2.0 and so on).

像其餘版本控制系統（VCS）同樣，Git 能夠給歷史中的某一個提交打上標籤，以示重要。 比較有表明性的是人們會使用這個功能來標記發佈結點（v1.0 等等）。

我建議分支除了 master 與 develop 分支外，其餘分支都爲臨時分支，在開發完成後即刪除。過多的分支會給你查找目標分支帶來麻煩。

將版本與進行中的需求分開管理是標籤與分支存在的意義。

Git的三個常見場景

開發與上線

Master 是最原始的分支。剛開始開發時，須要從 master 分支 checkout 一個develop 分支做爲開發分支。Develop 分支相對 master 分支可能會存在一些 Bug，代碼不如 master 分支穩定；

當有新特性或須要解決 Bug，則從 develop 分支 checkout 一個 feature 分支進行開發；

每一個新特性開發完畢，就從 feature 分支發起 Merge request (MR) 請求合併到 develop 分支；

當全部特性開發完畢並在測試環境測試經過，從 develop 分支發起 MR 請求合併到 master 分支；

在預發環境測試經過後，打個標籤，正式發佈上線。

解決線上Bug

線上出現 緊急 Bug 就不能有太長的測試發佈流程了，一般能夠這麼作：

從 master 分支 checkout 一個 hotfix 分支，解決完 Bug 合併回 master 分支，在預發環境測試沒問題後打標籤發佈；

發佈完成後，不要忘了更新 develop 分支，由於此時 develop 分支落後於 master 分支，因此可讓 develop 分支 rebase master 分支。

解決feature分支衝突

這是最多見的一類場景，一個版本一般不止一個新特性。先開發完成的特性合併回 develop 分以後，會致使其餘 feature 代碼版本落後沒法合併至 develop。

比較常見的解決方法是將 develop 分支合併到 feature2 分支，這樣操做有個壞處，會產生冗餘的git 日誌：Merge branch 'develop' into feature2。

更好的方法是用 Rebase(變基） 。在分支落後狀況下，rebase develop 能夠將當前分支的改動「接在」 feature1 的改動以後。

注意：

1. rebase 會修改 Git 歷史提交記錄，操做不當存在必定風險。
2. rebase 後，須要 git push -ff (fast-forward模式) 才能將代碼推送到遠程倉庫

代碼流動原則

分支管理中，切記 代碼只可單路徑流動，意味着咱們須要嚴格遵照下面的操做：

1. 只能從 develop 分支 checkout feature 分支；
2. Feature 分支 只能合併入 develop 分支；
3. 有 hotfix 狀況下，develop 必須 rebase master 分支，保持代碼從 master 流動至 develop。

---