GIT分支策略

GIT分支策略

GIT是目前主流的版本控制軟件，其分佈式的架構，讓程序員脫離網絡也能實現版本控制的功能。但是，最好的軟件，也需要能盡其所能，才能達到好的效果。要使用好GIT進行協作開發，最主要的是靈活運用GIT的分支，GIT是鼓勵多分支的。在開發中，爲了讓各開發單位之間的影響降到最低，我們應根據功能進行相應的分支創建，那是隨便建分支嗎？肯定不是，分支的創建管理也有其自身的策略。下面是GIT分支策略圖：

這些分支各是用來放置什麼內容呢？

Master分支

此分支用來放置上線版本的內容，在開發中，此分支是別的分支的基點，此分支往往設置爲保護分支，只允許管理人員或分支創建者去合併Hotfix分支和Release分支，絕不允許直接push代碼到此分支。

 

Develop分支

此分支來源於Master分支，用來放置開發期間的內容，可以認爲此分支出來的版本是開發版。在實際開發中，此分支往往也設置爲保護分支，只允許管理人員把功能分支(Feature)、Bug修復分支(Hotfix)、正式版分支(Release)合併進來，也不允許直接提交代碼到此分支。

 

下面是各種場合的分支創建策略：

Feature分支

當接到一個新的功能模塊開發任務後，我們要在Develop分支上創建新的功能分支(Feature)，分支的名稱最好以功能來命名，這樣便於後續的任務識別。有關聯的模塊最好放置在同一個分支，便於調用。另外，分支可以由多個程序員來維護，但是，由一個來創建，然後push到遠程倉庫，同分支下別的程序員pull分支內容下來，然後一起協同開發。

此功能開發完了，怎麼處理？

功能開發完了，不僅僅是功能實現了，還必須要保證單元測試了且沒有問題，業務邏輯沒有問題，本功能測試沒有問題，這時候就可以向管理者發佈一個合併到Develop分支的請求，管理人員收到合併請求後，最好要進行代碼的審覈，沒有問題了再合併，合併完成後，就可以刪除原功能模塊分支，開發團隊完成了此功能的開發。

 

Release分支

當設計的功能完整後，需要給客戶使用了，這時候需要對項目進行完整的功能測試，這時候，需要在Develop分支上新建一個正式版分支(Release)，表示正式版的功能就是目前開發版的完整功能，然後開發版可以繼續添加新功能，但是，在目前正式版中是沒有的，要下個版本才提供。在正式版上要對項目進行嚴格的測試，發現Bug，直接在此分支上解決。直到測試發現的BUG都解決，沒有問題了，相關負責人就向Master分支管理員發送合併到Master的請求，Master分支管理員收到請求後，經審覈在合併，然後在此基礎上編譯出一個正式版運行項目，部署到相關的生產環境中。另外，要把此分支併入到Develop分支中，以解決掉Develop分支中代碼的Bug。

 

Hotfix分支

正式版發佈後，用戶在使用中發現Bug，怎麼處理？這時候，我們要在Master分支上去創建Hotfix分支，然後解決Bug，解決完後再併入到Master分支以及Develop分支。

 

使用Git的目的就是協作，減少互相之間的負面影響。