5.分支管理
5.1.分支使用場景和作用
通常在專案上線后，我們經常會同時面臨生產環境出現Bug和新需求正在開發的情形，如何將這些情形同時處理而又互不影響呢？這個時候就需要使用到版本控制系統的分支管理，
分支管理參考圖：
上圖針對不同時期的作業場景建立了不同的專案分支，分別處理不同場景下產生的問題，通過建立分支可以將作業同時分配給多個人員進行開展，作業人員各自處理不同場景的任務，并且各自之間沒有沖突，這不僅在效率和穩定方面都有很好的作用，
5.2.分支實戰運用
在實際的作業中一般中大型規格的軟體專案都會有一套分組管理機制，為專案不同的場景、不同的階段形成獨立的專案工程，促使讓專案的迭代根據流暢、生產環境運行更加穩定，嚴格的、清晰的實施分組管理機制是管理好專案必不可缺的一項作業，
以下根據個人的經驗，將分支劃分為如下的種類：
主干分支master
生產環境的源代碼，代碼功能的運行要和正在運行的生產環境完全一致，開發人員通常是無權限進行編輯操作的，
開發分支 develop
相當于主干分支的副本，“開發分支 develop”并不是在該分支上進行開發的，基于“開發分支”(最新的代碼)并根據新需求，通常將該分支作為母體進行擴展建立一個新的分支“功能分支”，例如，接到某個新的需求要開發一個在線聊天功能，此時開發人員就需要在該分支(開發分支 develop)上拉一個新的分支用于開發在線聊天功能，
功能分支 feature
一般對于周期較短的功能，我們可以斟酌下直接在“開發分支 develop”上進行完成，但是對于沖長期的開發功能模塊，通常設計、編碼、測驗會花上大量的時間，通常會在“開發分支 develop”上擴展出一個新的分支專門用于某個功能的開發，該分支就稱為“功能分支 feature”，
Bug分支 hotfix
主要用于解決生產環境下出現系統問題(Bug)，該分支通常是從“主干分支master”上擴展建立新的分支，該分支需要注意的一項是，在修復完畢并測驗上線后，最好將變更的內容同步合并到正在作業的其他分支，如開發分支、功能分支，以免造成其他分支上線覆寫掉了修復的內容，
合并預發布分支 MergeRelease
該分支的運用場景是，當我們開發好新功能或者修復好一個bug時，我們會用“主干 master”擴展建立一個新的分支，在將當前開發好新功能或者修復bug的分支與當前從主干拉的新分支進行一個代碼合并，并在代碼合并時或之后要排除合并的沖突問題，并在進行一次測驗，測驗無誤后用戶發布上線，上線后在將變更的內容同步合并到正在作業的其他分支，如開發分支、功能分支，
各個分支的作業流程圖：
注：以上圓形代表每個分支
5.3.Git分支管理操作
5.3.1.創建分支
創建一個分支就是將某個目標分支做為一個原型將其復制成為一個新的專案工程(分支)，
創建：git <分支名稱>
查看：git branch -v
操作參考圖：
在實際的專案中創建分支一般使用：git checkout -b <分支名稱>，這邊表示創建分支并定位到分支
操作參考圖：
5.3.2.切換分支
操作命令：git checkout <分支名稱>
操作參考圖：
5.3.3.合并分支
第一步，切換到主干：git checkout master
第二步，合并：git merge 分支名
操作參考圖：
5.3.4.洗掉分支
1.切換到主干：git checkout master
2.洗掉：git branch -D 分支名
操作參考圖：
6.沖突
6.1.沖突的出現場景
6.1.1.代碼上傳
當多名的開發人員都對同一份代碼檔案的同一塊區域進行了編輯，那么當非首位提交人員在進行commit后再在對GitHub進行Push時就會產生沖突：
操作場景參考圖：
6.1.2.版本合并時
從主干創建了一個分支并在分支中對某個代碼的函式進行了編輯，另外同時主干也對同份代碼的函式進行了編輯，主干對編輯的內容先進行了commit，那么當分支在對編輯內容進行commit時就會產生沖突，
沖突參考圖：
6.2.解決沖突
下面以上述的第二種情況來介紹如何解決沖突：
- 通過命令：”git diff”，找到發生沖突的檔案及沖突的內容區域，如圖：
2.對沖突檔案中的沖突內容進行編輯(手工解決沖突內容)，在實際的作業中這塊往往需要找到和你同時操作同塊內容的同事進行協商，看如何對內容進行編輯取舍，
3.對沖突的內容確定好修改后，需要對沖突檔案進行add后再commit
操作參考圖：
注：當Merging標識消失就表示沖突已經解決，
4.如果是代碼上傳是產生的沖突，那么在commit之后還需要進行一次push操作，
后續詳見第二節.....
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/1002.html
標籤：其他