一、git原理介紹

1.git的四個工作區域

　　Git有四個工作區域：工作目錄（Working Directory）、暫存區(Stage/Index)、資源庫(Repository或Git Directory)、git倉庫(Remote Directory)。

2.檔案的四種狀態

　　Untracked:未跟蹤, 此檔案在資料夾中, 但並沒有加入到git庫, 不參與版本控制. 通過git add 狀態變為Staged.

　　Staged:暫存狀態. 執行git commit則將修改同步到庫中, 這時庫中的檔案和本地檔案又變為一致, 檔案為Unmodify狀態. 執行git reset HEAD filename取消暫存,檔案狀態為Modified;

　 Mosified:檔案已修改, 僅僅是修改, 並沒有進行其他的操作.

　　Committed:檔案已提交修改；

3.git的目錄結構：

　　進入隱藏的 .git 目錄之後可以看到如上圖所示結構

　　核心檔案：config，objects，HEAD，index，refs 這 5 個資料夾

• config：這裡儲存專案的一些配置資訊，比如是否以 bare 方式初始化，remote 資訊等。git remote add 新增的遠端分支資訊就儲存在這裡
• objects：這裡儲存 git 物件，git 中的一些操作以及檔案都會以 git 物件形式儲存在這裡，git 物件分為BLOB，tree，commit三種類型，比如 git commit 就是 commit 型別變數，各個版本之間通過版本樹進行組織，比如 HEAD 指向某個 commit 物件，而 commit 物件又會指向幾個 BLOB 物件或者 tree 物件。objects 資料夾中有很多子資料夾，其中 git 物件儲存在以其 sha-1 值的前兩位為子資料夾後 38 位為檔名的檔案中，此外 git 為了節省儲存物件所佔用的磁碟空間，會定期對 git 物件進行壓縮和打包，其中 pack 資料夾用於存放打包壓縮的物件，info 資料夾用於從打包的檔案中查詢 git 物件
• HEAD：該檔案指明瞭本地的分支結果，如本地分支是 master，那麼 HEAD 就指向 master，分支在 refs 中就會表示成refs:refs/heads/master
• index：該檔案 stage 暫存區資訊，也就是 add 之後儲存到的區域，內容包括它指向的檔案的時間戳，檔名，sha1 值等
• refs：該資料夾儲存了指向分支的提交物件也就是 commit 物件的指標，其中的 heads 資料夾儲存了本地每一個分支最近一次提交的 sha-1 值，即 commit 物件的 sha-1 值，每個分支一個檔案；remotes 資料夾則記錄你最後一次和遠端倉庫的通訊，也就是說這裡會記錄最後一次每個分支推送到遠端的值；tags 資料夾儲存分支別名

二、專案中如何選擇分支模式

　　在專案開發的過程中，選擇一個合適的分支模式來管理程式碼至為重要，那麼如何根據這身的業務特點和團隊規模來選擇合適的分支模式呢？這部分將對幾種主流的Git分支模式進行介紹，下邊將介紹TBD（主幹開發模式）、Git-Flow模式、Github-Flow和Gitlab-Flow模式。

1.TBD(主幹開發模式)

　　TBD，即主幹開發模式，所有的開發都在一個開發分支上進行協作開發，只保留一條長期穩定的開發分支，不允許新建任何長期存在的開發分支，任何程式碼的變更都更新到主幹分支上，當需要釋出時，建議根據版本號拉一個release分支進行釋出，可以通過merge或者cherry pick將程式碼弄到釋出分支上。

TBD模式注意點：

　　1.因為所有的改動及變更都在主幹分支上，所以確保改動足夠小，每次的改動都是可控的，能段時間完成驗證；

　　2.每次主幹分支上的改動能得到快速驗證，有完善的團隊協作及自動化測試，隨時做好上線的準備，避免引主幹上的功能缺陷而影響釋出。

　　因為主幹開發要求每次變更提交都要小，並且要快速驗證完，保證主幹是處在可釋出狀態。對於一些處在開發過程中的特性，如每次變更提交，並非意味著完整特性的完成，為了隔離“特性半成品”對主幹的影響，一般會採用特性開關（Feature Toggle）的方式進行隔離。即頻繁的程式碼變更提交，可以先做整合及驗證，但是在釋出的角度，通過（Feature Toggle）先隱藏相關特性，只有當特性都完成之後，才打開開關，特性完全透出。

TBD模式優點：

　　1.分支少，合併衝突小，實踐簡單；

　　2.適合持續交付及部署，簡單密集需求交付

TBD模式缺點：

　　1.對團隊協作及成熟度合整合測試有很高的要求；

　　2.不適合開發一些持續時間長的需求及功能複雜的業務；

2.Git-Flow模式

　　隨著敏捷開發的廣泛使用，越來越多的團隊協作完成某一特性或者分別完成不用的使用者故事，根據不同的特性或者使用者故事來建立開發分支就應運而生。最有代表性的就是Git-Flow模式。

　　Git-Flow模式很好解決了不同特性之間並行開發需要的工作方式。每一個特性都能同時開工，結合敏捷開發的例子，每個迭代開始時從主幹分支拉出一個特性分支，命名結構參考feature/xxx-232，所有關於此特性的開發都在此分支上進行，當開發完成後把特性分支合併回主幹分支上，測試通過後進行釋出。

Git-Flow模式一般有以下分支結構：

• feature分支：開發者進行特性功能開發的分支；
• develop分支：開發主幹分支，包含所有的特性功能；
• release分支：版本釋出分支；
• master分支：穩定分支，儲存最新的已釋出程式碼；
• hotfix分支：線上問題缺陷修復分支；

　　下面是一些工作流程：

　　在開發者接到一個開發需求時，從develop分支拉一個feature分支進行開發，最好已ID進行命名，避免重複，為了減少後邊合入develop的衝突，最好在開始coding前把develop分支合到feature分支上再進行開發；

　　當在feature分支完成開發並驗證通過後，將feature分支合入develop分支；

　　develop分支用於整合功能驗證，當整合測試成功後將基於develop分支拉一個release版本分支進行釋出，如果在release上測試發現bug則在release上修復，之後將程式碼合入develop，當上線完成後將release合入master分支進行最新上線程式碼儲存；

　　如果線上發現bug,則基於master拉一條hotfix分支進行修復，修復完成後將hotfix分支合入master進行釋出，最後將hotfix程式碼也同步到develop上。

　　注意：對一些已完成的feature分支及hotfix分支進行及時刪除。

Git-Flow模式的優點

　　1.特性並行開發，效率高，程式碼獨立；

　　2.支援複雜業務、大團隊協同開發；

　　3.支援多版本釋出；

Git-Flow模式的缺點

　　1.分支多，合併衝突較為頻繁

　　2.需要進行維護分支，對分支程式碼進行更新

3.Github-Flow 模式

　　Github-Flow就是簡化版的Git-Flow，更輕量，減少分支。對於 GitHub-Flow 來說，釋出應該是持續地，當一個版本準備好，它就可以被部署，feature跟hotfix本質上都是一樣的，都屬於特性分支，並移除了release分支。

分支情況如下：

　　在master分支上的程式碼都是最新的，可部署的；

　　在特性分支合到master分支時需要發起Pull Request程式碼評審，評審後方可合入master；

　　在master上進行持續版本釋出。

優點：

　　1.支援並行開發；

　　2.分支結構簡單，有明確的規則定義，持續整合持續部署

缺點：

　　1..對測試要求高，一些功能複雜的需求需要持續長的時間驗證或者中斷則影響整個計劃；

　　2.不能很好的處理一些很緊急的上線需求；

4.Gitlab-Flow模式

　　GitLab-Flow 相比於 GitHub-Flow 來說，在開發側的區別不大，只是將 pull request 改成了 merge request，而 merge request 的用法與 pull request 類似，都可以做為程式碼評審、獲取反饋意見的一種溝通方式。
最大的區別體現在釋出側，即引入了對應生產環境的 production 分支和對應預發環境的 pre-production 分支（如果有預發環境的話）。這樣，master 分支反映的是部署在整合環境上的程式碼，pre-production 分支反映的是部署在預發環境的程式碼，production 分支反映的最新部署在生產環境的程式碼。
　　當一個特性開發完成，提交 merge request，將特性開發的程式碼合併到 master，並部署到整合環境進行驗證；當驗證通過之後，提交 merge reqeust，合併 master 到 pre-production 分支，並部署到預發環境，進行預發環境上驗證；當預發環境驗證成功之後，再提交 merge request，將 pre-production 分支上的程式碼合併到 production 分支上。

三、分支總結

　　根據每個專案的實際情況的不同選擇不同的分支模式：

　　1.git-flow模式對於開發週期長的專案是比較好的選擇，可以很好解決新功能開發，版本釋出，線上問題修復等問題；

　　2.如專案釋出週期短，需持續釋出維護，功能較為簡單，TBD和GitHub-flow是個不錯的選擇；

　　3.如果對一些複雜功能的上線前增加一些驗證，可選gitlab-flow模式。

　　還有一些其他的分支策略，比如定義一個主幹分支，然後每個成員已自己名字命名的開發分支等等，結合我們的業務需求選擇分支策略最為重要。

本文參考：

公眾號：阿里技術，作者：張燎原，如何選擇Git分支模式？