本文主要説明已經掌握或者想要掌握Git的開發者， 如何更好的應用Git， 以及更好的將Git與DevCloud結合應用。
2概述2.1版本控制系統介紹
從狹義上來說， 版本控制系統是軟體專案開發過程中管理代碼所有修訂版本的軟體， 能夠存儲、追蹤檔的修改歷史， 記錄多個版本的開發和維護， 事實上我們可以將任何對專案有幫助的文檔交付版本控制系統進行管理。 版本控制系統（Version Control Systems）主要分為兩類， 集中式和分散式。
2.1.1集中式版本控制系統
集中式版本控制系統的特點是只有一台中央伺服器， 存放著所有研發資料,而其它用戶端機器上保存的是中央伺服器最新版本的檔快照，
集中式版本控制系統的優點：
1.操作簡單， 使用沒有難度， 可輕鬆上手。
2.資料夾級許可權控制， 許可權控制細微性小。
3.對用戶端配置要求不高， 無需存儲全套代碼。
集中式版本控制系統的缺點：
1.網路環境要求高， 相關人員必須聯網才能工作。
2.中央伺服器的單點故障影響全域， 如果伺服器宕機， 所有人都無法工作。
3.中央伺服器在沒有備份的情況下， 磁片一旦被損壞， 將丟失所有資料。
2.1.2分散式版本控制系統
分散式版本控制系統的特點是每個用戶端都是代碼倉庫的完整鏡像， 包括專案檔案的變更歷史。 所有資料分佈的存儲在每個用戶端， 不存在中央伺服器。 可能有人會問， 我們公司使用Git分散式存儲工具， 也有“中央伺服器”啊？其實,這個所謂的“中央伺服器”僅僅是用來方便管理多人協作， 任何一台用戶端都可以勝任它的工作， 它和所有用戶端沒有本質區別。
分散式版本控制系統的優點：
1.版本庫當地語系化， 版本庫的完整克隆， 包括標籤、分支、版本記錄等。
2.支援離線提交， 適合跨地域協同開發。
3.分支切換快速高效， 創建和銷毀分支廉價。
分散式版本控制系統的缺點：
1.學習成本高， 不容易上手。
2.只能針對整個倉庫創建分支， 無法根據目錄建立層次性的分支。
3.1華為雲帳號
使用華為軟體發展服務， 首先需要註冊一個華為雲帳號。
3.2Git用戶端
Git是一款開源的分散式版本控制系統(Distributed Version Control System) ， 誕生於2002年， 由Linux之父Linus Torvalds帶領Linux開源社區開發完成， 初衷是用其管理Linux內核的龐大的開原始程式碼。 在當今敏捷開發成為主流,研發週期短， 跨地域協同開發多的大形勢下， 選擇Git版本管理工具是大勢所趨。 國內外有很多基於Git的雲端代碼託管服務， 華為軟體發展服務（Devcloud）配置管理服務就是其中之一。
代碼託管（CodeHub）是面向軟體發展者提供的基於Git的線上代碼託管服務，包括代碼克隆/下載/提交/推送/比較/合併/分支等。代碼一鍵下載到本地，基於本地IDE開發，開發完畢一鍵推送雲端，實現線上線下協同開發
3.2.1Git Bash 下載安裝
GitBash用戶端軟體是本地PC使用git必須安裝的軟體，如果本地沒有安裝，請到https://git-scm.com/downloads下載。
安裝成功以後，在開始功能表中會增加Git Bash選項。
3.2.2配置個人資訊
安裝完成，運行Git Bash，在彈出終端頁面按照下面操作進行個人配置。
3.2.3生成金鑰
運行Git Bash, 生成一對SSH金鑰，在彈出的終端中輸入下面命令，回車後會提示您輸入一個密碼，建議不輸入，一路回車即可。
此時，會在~/.ssh資料夾下生成了一對金鑰，公開金鑰id_rsa.pub和私密金鑰id_rsa，私密金鑰無需處理，保存在本機就可以了，公開金鑰的內容需要拷貝到軟體發展服務中。
3.3已經創建好的專案
創建專案
在華為雲官網首頁 產品軟體發展服務，進入華為軟體發展服務首頁。
點擊右上角“新建”按鈕新建專案
輸入專案名稱，選擇開發流程，輸入專案描述，點擊“新建”按鈕即完成了一個專案的創建。
4Devcloud場景應用4.1CodeHub操作
4.1.1新建空倉庫
在開發雲代碼服務中，點擊上方“新建倉庫”按鈕
新倉庫的詳細配置如下:
新建成功
4.1.2粘貼ssh公開金鑰
第一步：運行GitBash，在終端執行如下命令，會將.ssh資料夾下的id_rsa.pub公開金鑰內容（灰色背景的字串）列印到終端，拷貝這些字串，注意不要有多餘的空格。
第二步：在開發雲代碼服務中，點擊右上角的“設置SSH金鑰”
第三步：繼續點擊右上角的“添加SSH金鑰”
第四步：粘貼拷貝的公開金鑰字串，添加“標題”，點擊“新建”就可以了。
4.2雲端倉庫功能一覽
功能
描述
新建倉庫
用戶可以在專案中創建一個或多個代碼倉庫。
倉庫克隆
用戶可以使用克隆功能將代碼下載到本地進行開發。
分支管理
使用者開發過程中可以使用拉取分支功能進行不同特性和補丁的開發。
標籤管理
產品開發或反覆運算過程可以使用標籤記錄版本反覆運算。
分支合併
在特性或補丁開發完成後可以使用分支合併功能將特性或補丁合入主幹分支。
分支保護
倉庫管理員可以使用分支保護功能控制分支的刪除和代碼提交。
提交代碼
開發過程中通過提交方式將代碼提交到倉庫中。
拉取代碼
通過拉取代碼可以獲取遠端倉庫的的最新代碼。
推送代碼
通過推送代碼功能將本地庫代碼上傳到遠端倉庫。
代碼閱讀
可以通過Web線上方式閱讀代碼。
線上修改
可以通過Web線上方式修改。
活動記錄
倉庫代碼提交、成員變更等資訊都可以通過活動記錄查看，方便管理者審核或追溯代碼。
倉庫範本
提供有代表性的倉庫範本，使用者可以根據倉庫範本創建代碼倉庫。
倉庫成員管理
倉庫管理員可以設置用戶是否可以訪問倉庫並設置存取權限。
倉庫關注
用戶可以關注經常使用的倉庫，倉庫關注後會默認排在前面方面查看。
金鑰管理
用戶默認不感知，在創建代碼檢查任務或編譯構建任務時會自動添加部署金鑰，在代碼檢查或編譯構建下載代碼時根據部署金鑰下載，部署金鑰只能用於下載代碼不能上傳代碼，保證安全性。
5Git本地研發場景5.1克隆代碼
在本地準備克隆代碼的目的檔案夾，右鍵打開git bash終端
執行如下命令：
5.2代碼提交
一次修改被成功提交到遠端倉庫會歷經四個階段，1本地工作區->2緩存區->3版本庫->4遠端版本庫，通過執行相應的Git命令，檔在這四個區域跳轉，並呈現不同的狀態，主要涉及三步操作：
#git add/rm filename //將新增、修改或者刪除的檔增加到暫存區
#git commit –m “commit message” //將已暫存的檔提交到本地倉庫
#git push//將本地代碼倉庫修改推送到遠端倉庫
5.3分支操作
5.3.1新建分支
Git新建分支的本質就是創建一個指向最後一次提交的可變指標，所以，Git分支的創建不是複製版本庫的內容，僅僅是新建了一個指標，它以40個字元長度SHA-1字串形式保存在檔中。
#git branchbranchNamecommitID
基於commitID即某一個全球版本號拉出新分支，如果沒有commitID則基於當前分支的HEAD拉出新分支。
如下圖新建feature分支執行的命令為git branch feature
5.3.2切換分支
#git checkoutbranchName
如下圖切換到feature分支執行的命令為git checkoutfeature
5.3.3分支合併
無論哪種工作流都會涉及到分支合併（把一個分支中的修改整合到當前分支），主要有兩種方法：三方合併（merge）和衍合（rebase）。我們通過對同一種場景進行不同操作體會兩種合併方法的區別。
場景：master分支新增了C4節點， hotfix分支新增了C3節點，現將hotfix分支合併到master分支：
1.三方包括hotfix新增節點C3，master新增節點C4，以及兩者的共同祖先節點C2。這種合併操作簡單，但新增合併節點C5，形成了環形，版本記錄可讀性差。
#git checkout master
#git merge hotfix
2.衍合先將master分支新增節點C4以補丁形式保存在.git/rebase目錄中，然後同步hotfix分支最新代碼，再應用補丁C4’。
#git checkout master
#git rebase hotfix
5.3.4衝突解決
類型一：兩個合併分支修改了同一行代碼
解決方法：
1.分析哪種修改方法正確，手動合併；
2.提交修改。
類型二：檔被重命名為不同的名字
解決方法：
1.確認哪個名字是正確的，刪除錯誤的；
2.提交修改。
6Git工作流什麼是Git工作流？你可以理解為代碼管理的分支策略，它不僅僅是版本管理範疇，更服務於專案流程管理和團隊協同開發。所以，我們有必要制定適合自己研發場景的工作流。
下面介紹四種工作流的工作方式、優缺點，以及使用中的一些注意事項。
1.集中式工作流
2.功能分支工作流
3.gitflow工作流（Devcloud推薦）
4.forking工作流
6.1集中式工作流
集中式工作流適合5人左右小開發團隊，或是剛從SVN工具轉型為Git的團隊，它只有一個預設的maste分支（相當於svn的trunk主分支），所有人的修改都是在master分支上進行的。但是，這種工作流無法充分發揮git優勢和多人協同，不推薦使用。
工作方式：
開發人員將master分支從中央倉庫克隆到本地，修改完成後再推送回中央倉庫master分支。
優點：
不涉及分支交交互操作
缺點：
1.不適合人員較多的團隊，當人員10+時，解決開發人員之間的代碼衝突會耗費很多時間；
2.master分支提交頻繁；
3.master分支不穩定，不利於集成測試。
Tips：如何儘量避免產生衝突和不合理的提交歷史？
開發人員在開發一個新功能之前，一定要在本地同步中央倉庫最新代碼，使自己的工作基於最新的代碼之上；開發完成後，在提交新功能到中央倉庫前，需要先fetch中央庫的新增提交，並rebase自己的提交。這樣做的目的是，把自己的修改加到中央倉別人已經提交的修改之上，使最終的提交記錄是一個完美的線性歷史，而不是環形。
舉例：
1.開發人員A和開發人員B同時在某個時間拉取了中央倉庫的代碼
2.開發人員A先完成了自己的工作，並提交到中央倉庫
3.開發人員B需要在本地執行git pull –rebase中央倉庫的新提交，這時開發人員B的本地倉庫就包含了開發人員A修改的內容，並在A的基礎上增加了自己的修改
4.開發人員B將代碼推送到中央倉庫
6.2功能分支工作流
通過新建幾個功能分支，增加開發者的交流和協作，它的理念是所有的功能開發都應該在master分支外的一個獨立分支進行，這種方式隔離了開發者的工作空間不被互相干擾，保證了master分支的穩定性。
工作方式：
開發人員每次在開始新功能開發前，需要在master分支上拉取一個新分支，並起個有描述性的名字，比如video-output或issue-#1061，這樣可以讓分支用途明確。功能分支不但存在開發人員本地倉庫，也應該推送到中央倉庫，這樣就可以在代碼不合入master分支的情況下與其他開發人員分享代碼。
優點：
分支合併前可以使用pull request進行code review；
降低了master分支的提交頻率
缺點：
只有一個master分支作為集成，仍然不是很穩定，不適合大型開發
6.3Gitflow工作流
Gitflow一般用於管理大型專案，它為不同的分支分配一個很明確的工作角色，並定義分支之間什麼時候進行交互。
工作方式：
master分支：生產分支，最穩定的版本，一直是ready to deploy狀態。不接受開發人員直接commit，只接受從其他分支merge操作。在很多企業中，這個分支被預設開啟分支保護，只有維護者可以操作。
hotfix分支：從master分支拉取的臨時修復分支，用於解決一線緊急bug。bug解決後需要合入master分支並打上新的版本號，這個修改也需要同時合入develop分支。
develop分支：從master分支拉取的開發分支，用於功能集成。包含所有要發佈到下一個Release的代碼用於開發集成、系統測試。
release分支：臨近既定的發佈日，就從develop分支上拉取一個release分支，任何不在當前分支中的新功能都推到下個發佈中。release分支用於發佈，所以從當前時間點之後新的功能不能再加到這個分支上，這個分支只做Bug修復、文檔生成和其它面向發佈的任務。當對外發佈的工作都完成了，release分支合併到master分支並分配一個版本號打好Tag；另外，這些從release分支新做的修改要反向合併回develop分支。
feature分支：開發者使用的特性分支，父分支是develop分支，當新功能完成時，合入develop分支。新功能提交從不直接與master分支交互。
###############################################################################
開發人員提交新功能的兩種途徑：
1.團隊有專人review審核新功能
a)開發人員將feature分支推送到華為軟體發展雲代碼託管平臺（中央倉庫）
b)發起一個從feature分支合併到develop分支的pull request請求，並指給review專員
c)review專員審核。如果通過，將feature分支的新功能合併到develop分支，並刪除feature分支；如果未通過，拒絕該請求並注明拒絕原因。
2.開發人員自審核新功能
a)開發人員在本地倉庫將feature分支合併到develop分支，並刪除feature分支
b)將本地develop分支的修改推送到華為軟體發展雲代碼託管平臺（中央倉庫）
###############################################################################
優點：
1.使用一個用於發佈準備的專門分支（release分支），使得一個團隊可以在完善當前的發佈版本的同時，可以在develop分支並行繼續開發下個版本的功能。這也打造了視覺化的發佈階段，團隊成員都可以在倉庫網狀結構中可以看到發佈狀態；
2.使用緊急修復分支（hotfix分支）讓團隊可以處理緊急問題的同時而不打斷其它工作或是等待下一個發佈再合入hotfix修改。我們可以把hotfix分支想成是一個直接在master分支上處理的臨時發佈；
3.大型專案人員協作頻繁，流程較多，合理的多角色分支幫助研發有條不紊進行；
4.更符合devops理念。
缺點：
1.學習成本較高；
2.如果團隊不遵守使用約定，帶來的影響更大。
6.4forking工作流
Forking工作流區別於前三種工作流的最大特點是每個開發人員都有一個從公共倉庫fork出來的屬於自己的公共倉。Forking工作流適合外包、眾包以及眾創和開源場景。接包方的開發人員從專案公共倉fork自己的公共倉庫進行操作，並不需要被專案公共倉直接授權。
工作方式：
將“項目公共倉”fork出一個“個人公共倉”
將“個人公共倉”clone到“本地倉庫”
操作“本地倉庫”，修改完成後提交到“個人公共倉”
為“個人公共倉”提交一個pull request給項目維護者，申請代碼合入“專案公共倉”
< p="">專案維護者在本地review、驗證本地提交，審核通過後push進入“專案公共倉”Tip：如果開發人員A的代碼未被審核通過合入“公共倉庫”，而此代碼對開發人員B有借鑒作用，開發人員B可以直接從開發人員A的“個人公共倉”拉取代碼。
優點：
1.開發人員之間若需要代碼協作，可以直接從其他人的“個人公共倉”拉取，無需等到代碼提交到項目公共倉；
2.“項目公共倉”無需為每個代碼貢獻者授權；
3.項目維護者通過審核pull request成為代碼安全的重要防線；
4.倉庫分支的選擇可以根據專案實際情況綜合使用前三種工作流。
缺點：
1.提交步驟繁瑣，開發人員代碼到最終版本庫的週期較長。
研發團隊可以根據實際研發場景制定合理的工作流，能有效提高專案管理水準和團隊協同開發能力，並通過華為軟體發展雲CodeHub平臺，高效、安全的管理代碼資產，將更多的精力集中在業務開發上，實現持續集成、持續交付和快速反覆運算的目標。
代碼託管（CodeHub）是面向軟體發展者提供的基於Git的線上代碼託管服務，包括代碼克隆/下載/提交/推送/比較/合併/分支等。代碼一鍵下載到本地，基於本地IDE開發，開發完畢一鍵推送雲端，實現線上線下協同開發
3.2.1Git Bash 下載安裝
GitBash用戶端軟體是本地PC使用git必須安裝的軟體，如果本地沒有安裝，請到https://git-scm.com/downloads下載。
安裝成功以後，在開始功能表中會增加Git Bash選項。
3.2.2配置個人資訊
安裝完成，運行Git Bash，在彈出終端頁面按照下面操作進行個人配置。
3.2.3生成金鑰
運行Git Bash, 生成一對SSH金鑰，在彈出的終端中輸入下面命令，回車後會提示您輸入一個密碼，建議不輸入，一路回車即可。
此時，會在~/.ssh資料夾下生成了一對金鑰，公開金鑰id_rsa.pub和私密金鑰id_rsa，私密金鑰無需處理，保存在本機就可以了，公開金鑰的內容需要拷貝到軟體發展服務中。
3.3已經創建好的專案
創建專案
在華為雲官網首頁 產品軟體發展服務，進入華為軟體發展服務首頁。
點擊右上角“新建”按鈕新建專案
輸入專案名稱，選擇開發流程，輸入專案描述，點擊“新建”按鈕即完成了一個專案的創建。
4Devcloud場景應用4.1CodeHub操作
4.1.1新建空倉庫
在開發雲代碼服務中，點擊上方“新建倉庫”按鈕
新倉庫的詳細配置如下:
新建成功
4.1.2粘貼ssh公開金鑰
第一步：運行GitBash，在終端執行如下命令，會將.ssh資料夾下的id_rsa.pub公開金鑰內容（灰色背景的字串）列印到終端，拷貝這些字串，注意不要有多餘的空格。
第二步：在開發雲代碼服務中，點擊右上角的“設置SSH金鑰”
第三步：繼續點擊右上角的“添加SSH金鑰”
第四步：粘貼拷貝的公開金鑰字串，添加“標題”，點擊“新建”就可以了。
4.2雲端倉庫功能一覽
功能
描述
新建倉庫
用戶可以在專案中創建一個或多個代碼倉庫。
倉庫克隆
用戶可以使用克隆功能將代碼下載到本地進行開發。
分支管理
使用者開發過程中可以使用拉取分支功能進行不同特性和補丁的開發。
標籤管理
產品開發或反覆運算過程可以使用標籤記錄版本反覆運算。
分支合併
在特性或補丁開發完成後可以使用分支合併功能將特性或補丁合入主幹分支。
分支保護
倉庫管理員可以使用分支保護功能控制分支的刪除和代碼提交。
提交代碼
開發過程中通過提交方式將代碼提交到倉庫中。
拉取代碼
通過拉取代碼可以獲取遠端倉庫的的最新代碼。
推送代碼
通過推送代碼功能將本地庫代碼上傳到遠端倉庫。
代碼閱讀
可以通過Web線上方式閱讀代碼。
線上修改
可以通過Web線上方式修改。
活動記錄
倉庫代碼提交、成員變更等資訊都可以通過活動記錄查看，方便管理者審核或追溯代碼。
倉庫範本
提供有代表性的倉庫範本，使用者可以根據倉庫範本創建代碼倉庫。
倉庫成員管理
倉庫管理員可以設置用戶是否可以訪問倉庫並設置存取權限。
倉庫關注
用戶可以關注經常使用的倉庫，倉庫關注後會默認排在前面方面查看。
金鑰管理
用戶默認不感知，在創建代碼檢查任務或編譯構建任務時會自動添加部署金鑰，在代碼檢查或編譯構建下載代碼時根據部署金鑰下載，部署金鑰只能用於下載代碼不能上傳代碼，保證安全性。
5Git本地研發場景5.1克隆代碼
在本地準備克隆代碼的目的檔案夾，右鍵打開git bash終端
執行如下命令：
5.2代碼提交
一次修改被成功提交到遠端倉庫會歷經四個階段，1本地工作區->2緩存區->3版本庫->4遠端版本庫，通過執行相應的Git命令，檔在這四個區域跳轉，並呈現不同的狀態，主要涉及三步操作：
#git add/rm filename //將新增、修改或者刪除的檔增加到暫存區
#git commit –m “commit message” //將已暫存的檔提交到本地倉庫
#git push//將本地代碼倉庫修改推送到遠端倉庫
5.3分支操作
5.3.1新建分支
Git新建分支的本質就是創建一個指向最後一次提交的可變指標，所以，Git分支的創建不是複製版本庫的內容，僅僅是新建了一個指標，它以40個字元長度SHA-1字串形式保存在檔中。
#git branchbranchNamecommitID
基於commitID即某一個全球版本號拉出新分支，如果沒有commitID則基於當前分支的HEAD拉出新分支。
如下圖新建feature分支執行的命令為git branch feature
5.3.2切換分支
#git checkoutbranchName
如下圖切換到feature分支執行的命令為git checkoutfeature
5.3.3分支合併
無論哪種工作流都會涉及到分支合併（把一個分支中的修改整合到當前分支），主要有兩種方法：三方合併（merge）和衍合（rebase）。我們通過對同一種場景進行不同操作體會兩種合併方法的區別。
場景：master分支新增了C4節點， hotfix分支新增了C3節點，現將hotfix分支合併到master分支：
1.三方包括hotfix新增節點C3，master新增節點C4，以及兩者的共同祖先節點C2。這種合併操作簡單，但新增合併節點C5，形成了環形，版本記錄可讀性差。
#git checkout master
#git merge hotfix
2.衍合先將master分支新增節點C4以補丁形式保存在.git/rebase目錄中，然後同步hotfix分支最新代碼，再應用補丁C4’。
#git checkout master
#git rebase hotfix
5.3.4衝突解決
類型一：兩個合併分支修改了同一行代碼
解決方法：
1.分析哪種修改方法正確，手動合併；
2.提交修改。
類型二：檔被重命名為不同的名字
解決方法：
1.確認哪個名字是正確的，刪除錯誤的；
2.提交修改。
6Git工作流什麼是Git工作流？你可以理解為代碼管理的分支策略，它不僅僅是版本管理範疇，更服務於專案流程管理和團隊協同開發。所以，我們有必要制定適合自己研發場景的工作流。
下面介紹四種工作流的工作方式、優缺點，以及使用中的一些注意事項。
1.集中式工作流
2.功能分支工作流
3.gitflow工作流（Devcloud推薦）
4.forking工作流
6.1集中式工作流
集中式工作流適合5人左右小開發團隊，或是剛從SVN工具轉型為Git的團隊，它只有一個預設的maste分支（相當於svn的trunk主分支），所有人的修改都是在master分支上進行的。但是，這種工作流無法充分發揮git優勢和多人協同，不推薦使用。
工作方式：
開發人員將master分支從中央倉庫克隆到本地，修改完成後再推送回中央倉庫master分支。
優點：
不涉及分支交交互操作
缺點：
1.不適合人員較多的團隊，當人員10+時，解決開發人員之間的代碼衝突會耗費很多時間；
2.master分支提交頻繁；
3.master分支不穩定，不利於集成測試。
Tips：如何儘量避免產生衝突和不合理的提交歷史？
開發人員在開發一個新功能之前，一定要在本地同步中央倉庫最新代碼，使自己的工作基於最新的代碼之上；開發完成後，在提交新功能到中央倉庫前，需要先fetch中央庫的新增提交，並rebase自己的提交。這樣做的目的是，把自己的修改加到中央倉別人已經提交的修改之上，使最終的提交記錄是一個完美的線性歷史，而不是環形。
舉例：
1.開發人員A和開發人員B同時在某個時間拉取了中央倉庫的代碼
2.開發人員A先完成了自己的工作，並提交到中央倉庫
3.開發人員B需要在本地執行git pull –rebase中央倉庫的新提交，這時開發人員B的本地倉庫就包含了開發人員A修改的內容，並在A的基礎上增加了自己的修改
4.開發人員B將代碼推送到中央倉庫
6.2功能分支工作流
通過新建幾個功能分支，增加開發者的交流和協作，它的理念是所有的功能開發都應該在master分支外的一個獨立分支進行，這種方式隔離了開發者的工作空間不被互相干擾，保證了master分支的穩定性。
工作方式：
開發人員每次在開始新功能開發前，需要在master分支上拉取一個新分支，並起個有描述性的名字，比如video-output或issue-#1061，這樣可以讓分支用途明確。功能分支不但存在開發人員本地倉庫，也應該推送到中央倉庫，這樣就可以在代碼不合入master分支的情況下與其他開發人員分享代碼。
優點：
分支合併前可以使用pull request進行code review；
降低了master分支的提交頻率
缺點：
只有一個master分支作為集成，仍然不是很穩定，不適合大型開發
6.3Gitflow工作流
Gitflow一般用於管理大型專案，它為不同的分支分配一個很明確的工作角色，並定義分支之間什麼時候進行交互。
工作方式：
master分支：生產分支，最穩定的版本，一直是ready to deploy狀態。不接受開發人員直接commit，只接受從其他分支merge操作。在很多企業中，這個分支被預設開啟分支保護，只有維護者可以操作。
hotfix分支：從master分支拉取的臨時修復分支，用於解決一線緊急bug。bug解決後需要合入master分支並打上新的版本號，這個修改也需要同時合入develop分支。
develop分支：從master分支拉取的開發分支，用於功能集成。包含所有要發佈到下一個Release的代碼用於開發集成、系統測試。
release分支：臨近既定的發佈日，就從develop分支上拉取一個release分支，任何不在當前分支中的新功能都推到下個發佈中。release分支用於發佈，所以從當前時間點之後新的功能不能再加到這個分支上，這個分支只做Bug修復、文檔生成和其它面向發佈的任務。當對外發佈的工作都完成了，release分支合併到master分支並分配一個版本號打好Tag；另外，這些從release分支新做的修改要反向合併回develop分支。
feature分支：開發者使用的特性分支，父分支是develop分支，當新功能完成時，合入develop分支。新功能提交從不直接與master分支交互。
###############################################################################
開發人員提交新功能的兩種途徑：
1.團隊有專人review審核新功能
a)開發人員將feature分支推送到華為軟體發展雲代碼託管平臺（中央倉庫）
b)發起一個從feature分支合併到develop分支的pull request請求，並指給review專員
c)review專員審核。如果通過，將feature分支的新功能合併到develop分支，並刪除feature分支；如果未通過，拒絕該請求並注明拒絕原因。
2.開發人員自審核新功能
a)開發人員在本地倉庫將feature分支合併到develop分支，並刪除feature分支
b)將本地develop分支的修改推送到華為軟體發展雲代碼託管平臺（中央倉庫）
###############################################################################
優點：
1.使用一個用於發佈準備的專門分支（release分支），使得一個團隊可以在完善當前的發佈版本的同時，可以在develop分支並行繼續開發下個版本的功能。這也打造了視覺化的發佈階段，團隊成員都可以在倉庫網狀結構中可以看到發佈狀態；
2.使用緊急修復分支（hotfix分支）讓團隊可以處理緊急問題的同時而不打斷其它工作或是等待下一個發佈再合入hotfix修改。我們可以把hotfix分支想成是一個直接在master分支上處理的臨時發佈；
3.大型專案人員協作頻繁，流程較多，合理的多角色分支幫助研發有條不紊進行；
4.更符合devops理念。
缺點：
1.學習成本較高；
2.如果團隊不遵守使用約定，帶來的影響更大。
6.4forking工作流
Forking工作流區別於前三種工作流的最大特點是每個開發人員都有一個從公共倉庫fork出來的屬於自己的公共倉。Forking工作流適合外包、眾包以及眾創和開源場景。接包方的開發人員從專案公共倉fork自己的公共倉庫進行操作，並不需要被專案公共倉直接授權。
工作方式：
將“項目公共倉”fork出一個“個人公共倉”
將“個人公共倉”clone到“本地倉庫”
操作“本地倉庫”，修改完成後提交到“個人公共倉”
為“個人公共倉”提交一個pull request給項目維護者，申請代碼合入“專案公共倉”
< p="">專案維護者在本地review、驗證本地提交，審核通過後push進入“專案公共倉”Tip：如果開發人員A的代碼未被審核通過合入“公共倉庫”，而此代碼對開發人員B有借鑒作用，開發人員B可以直接從開發人員A的“個人公共倉”拉取代碼。
優點：
1.開發人員之間若需要代碼協作，可以直接從其他人的“個人公共倉”拉取，無需等到代碼提交到項目公共倉；
2.“項目公共倉”無需為每個代碼貢獻者授權；
3.項目維護者通過審核pull request成為代碼安全的重要防線；
4.倉庫分支的選擇可以根據專案實際情況綜合使用前三種工作流。
缺點：
1.提交步驟繁瑣，開發人員代碼到最終版本庫的週期較長。
研發團隊可以根據實際研發場景制定合理的工作流，能有效提高專案管理水準和團隊協同開發能力，並通過華為軟體發展雲CodeHub平臺，高效、安全的管理代碼資產，將更多的精力集中在業務開發上，實現持續集成、持續交付和快速反覆運算的目標。