一般在項目上線後,咱們常常會同時面臨生產環境出現Bug和新需求正在開發的情形,如何將這些情形同時處理而又互不影響呢?這個時候就須要使用到版本控制系統的分支管理。git
分支管理參考圖:函數
上圖針對不一樣時期的工做場景創建了不一樣的項目分支,分別處理不一樣場景下產生的問題,經過創建分支能夠將工做同時分配給多我的員進行開展,工做人員各自處理不一樣場景的任務,而且各自之間沒有衝突,這不只在效率和穩定方面都有很好的做用。測試
在實際的工做中通常中大型規格的軟件項目都會有一套分組管理機制,爲項目不一樣的場景、不一樣的階段造成獨立的項目工程,促使讓項目的迭代根據流暢、生產環境運行更加穩定。嚴格的、清晰的實施分組管理機制是管理好項目必不可缺的一項工做。編碼
如下根據我的的經驗,將分支劃分爲以下的種類:spa
主幹分支master設計
生產環境的源代碼,代碼功能的運行要和正在運行的生產環境徹底一致。開發人員一般是無權限進行編輯操做的。版本控制
開發分支 developblog
至關於主幹分支的副本。「開發分支 develop」並非在該分支上進行開發的,基於「開發分支」(最新的代碼)並根據新需求,一般將該分支做爲母體進行擴展創建一個新的分支「功能分支」。例如,接到某個新的需求要開發一個在線聊天功能,此時開發人員就須要在該分支(開發分支 develop)上拉一個新的分支用於開發在線聊天功能。開發
功能分支 feature原型
通常對於週期較短的功能,咱們能夠斟酌下直接在「開發分支 develop」上進行完成。可是對於衝長期的開發功能模塊,一般設計、編碼、測試會花上大量的時間,一般會在「開發分支 develop」上擴展出一個新的分支專門用於某個功能的開發,該分支就稱爲「功能分支 feature」。
Bug分支 hotfix
主要用於解決生產環境下出現系統問題(Bug),該分支一般是從「主幹分支master」上擴展創建新的分支。該分支須要注意的一項是,在修復完畢並測試上線後,最好將變動的內容同步合併到正在工做的其餘分支,如開發分支、功能分支,以避免形成其餘分支上線覆蓋掉了修復的內容。
合併預發佈分支 MergeRelease
該分支的運用場景是,當咱們開發好新功能或者修復好一個bug時,咱們會用「主幹 master」擴展創建一個新的分支,在將當前開發好新功能或者修復bug的分支與當前從主幹拉的新分支進行一個代碼合併,並在代碼合併時或以後要排除合併的衝突問題,並在進行一次測試,測試無誤後用戶發佈上線,上線後在將變動的內容同步合併到正在工做的其餘分支,如開發分支、功能分支。
各個分支的工做流程圖:
注:以上圓形表明每一個分支
建立一個分支就是將某個目標分支作爲一個原型將其複製成爲一個新的項目工程(分支)。
建立:git <分支名稱>
查看:git branch -v
操做參考圖:
在實際的項目中建立分支通常使用:git checkout -b <分支名稱>,這邊表示建立分支並定位到分支
操做參考圖:
操做命令:git checkout <分支名稱>
操做參考圖:
第一步,切換到主幹:git checkout master
第二步,合併:git merge 分支名
操做參考圖:
1.切換到主幹:git checkout master
2.刪除:git branch -D 分支名
操做參考圖:
6.1.1.代碼上傳
當多名的開發人員都對同一份代碼文件的同一塊區域進行了編輯,那麼當非首位提交人員在進行commit後再在對GitHub進行Push時就會產生衝突:
操做場景參考圖:
6.1.2.版本合併時
從主幹建立了一個分支並在分支中對某個代碼的函數進行了編輯,另外同時主幹也對同份代碼的函數進行了編輯。主幹對編輯的內容先進行了commit,那麼當分支在對編輯內容進行commit時就會產生衝突。
衝突參考圖:
下面以上述的第二種狀況來介紹如何解決衝突:
2.對衝突文件中的衝突內容進行編輯(手工解決衝突內容),在實際的工做中這塊每每須要找到和你同時操做同塊內容的同事進行協商,看如何對內容進行編輯取捨。
3.對衝突的內容肯定好修改後,須要對衝突文件進行add後再commit
操做參考圖:
注:當Merging標識消失就表示衝突已經解決。
4.若是是代碼上傳是產生的衝突,那麼在commit以後還須要進行一次push操做。
後續詳見第二節.....