徐磊老師在 IDCF FDCC 認證公益訓練營中提出，需求管理、配置管理、版本管理是研發(fā)管理的三大基石。而 Git 是當前最棒的版本控制系統(tǒng)，是事實的業(yè)界標準。可見熟悉 Git 操作, 設計合適的分支策略對于研發(fā)人員非常重要。

目前，已有很多文章介紹 Git 操作，也有很多文章介紹分支策略的選擇。本文以華為云軟件開發(fā)平臺DevCloud(https://devcloud.huaweicloud.com/)為例，基于常見的研發(fā)場景，介紹分支策略和對應的操作方法，方便開發(fā)團隊設計和實施適合自己的分支策略。

其中一些示例參考徐磊老師的課程《IDCF 訓練營 - DevOps 持續(xù)交付》，徐磊老師在課程中詳細介紹了分布式配置管理系統(tǒng) Git 的特點和優(yōu)勢，以及如何為團隊設計簡單高效的配置管理策略(分支策略)，推薦大家學習。

開發(fā)庫、受控庫和產(chǎn)品庫

開發(fā)庫、受控庫和產(chǎn)品庫的提法可能來源于 CMMI V1.0 (或更早的版本)的一個配置管理系統(tǒng)的例子，然后就成了一些組織的過程資產(chǎn)，沿用至今。

• 開發(fā)庫是開發(fā)人員修改代碼的地方，開發(fā)人員可以隨意修改；
• 受控庫是測試版本代碼存放的地方，需要開發(fā)組長提交測試申請修改；
• 產(chǎn)品庫是測試通過版本存放的地方，需要測試報告來驅(qū)動修改。

Examples of configuration management systems include the following:

Dynamic (or developer's) systems contain components currently being created or revised. They are in the developer's workspace and are controlled by the developer. Configuration items in a dynamic system are under version control.

Master (or controlled) systems contain current baselines and changes to them. Configuration items in a master system are under full configuration management as described int ths process area.

Static systems contain archives of various baselines released for use. Static systems are under full configuration management as described in this process area.

使用 Git 可以建立 dev, test 和 prod 三個分支分別對應開發(fā)庫、測試庫和產(chǎn)品庫，而不需要建 3 個庫 (repo)，這樣通過簡單的合并操作就可以實現(xiàn)從開發(fā)庫到測試庫、從測試庫到開發(fā)庫的代碼復制，而且可以從合并記錄中看出 3 個分支之間的關系。當然，作為分布式配置管理系統(tǒng)，每克隆一個新庫，就相當于新建了一個或一組分支，如果建 3 個庫，可以實現(xiàn)更嚴格的權(quán)限控制。

如果通過分支進行權(quán)限控制，打開 DevCloud, 進入要管理的代碼倉庫，在分支頁簽下建好所需的分支，然后在設置頁簽的倉庫管理 ? 保護分支管理菜單下，點擊新建保護分支，按照提示進行操作，可以實現(xiàn)只允許管理員向這些分支提交/合并，也就實現(xiàn)了測試庫和產(chǎn)品庫受控。

注意：DevCloud 保護分支管理界面中的合并指的是合并請求的批準權(quán)限，與 git-merge 并不是一回事。

保護分制管理

開發(fā)庫、受控庫和產(chǎn)品庫看起來可以滿足瀑布式開發(fā)的需要，在這種場景下，開發(fā)完成再測試，測試完成再進行生產(chǎn)發(fā)布，沒有合并時的沖突。實際上，沖突會體現(xiàn)在 dev 分支上。即使是遠端的中心倉庫只有一個 dev 分支，但其實中心倉庫的 dev 分支和開發(fā)人員本地倉庫的 dev 分支并不是一回事，即使用的是同一個名字，并且有跟蹤關系。

$ git checkout devSwitched to a new branch 'dev'Branch 'dev' set up to track remote branch 'dev' from 'origin'.

所以只要有團隊中有多位開發(fā)人員，就可能出現(xiàn)合并時的沖突，也就需要開發(fā)團隊對分支策略達成共識。在開發(fā)開始前，以及向中心倉庫推送修改前，及時拉取 dev 分支的最新改動，可以有效減少合并時的沖突。

當然，減少沖突的根本還是應從管理粒度和工程解耦兩方面考慮，這是徐磊老師在《IDCF 訓練營 - DevOps 持續(xù)交付》中提出的研發(fā)效能提升的核心秘籍。

至于 test 和 prod 兩個受控分支，因為只有被授權(quán)的配置管理員才能進行提交/合并操作，不太可能出現(xiàn)沖突，反而管理相對簡單。

如果 test 和 prod 兩個受控分支不允許存在無關的提交記錄，在從 dev 或 test 分支進行合并操作時，可使用 --squash 選項，然后再進行提交操作。當然如果使用 --squash, 從分支圖譜上將看不出兩個分支之間的關系，最好使用標簽功能在這幾個分支上進行標記。而且在下一次使用這種方式進行合并時，雖然當前的 HEAD 指向的文件內(nèi)容與被合并分支的某個父節(jié)點指向的的文件內(nèi)容完全相同，但兩者卻是不同的提交，所以很可能會出現(xiàn)合并沖突，此時指定合并策略可以避免處理合并沖突的麻煩。

$ git checkout testSwitched to branch 'test'Your branch is up to date with 'origin/test'.$ git merge dev --squash --strategy-option=theirsAuto-merging README.mdAutomatic merge went well; stopped before committing as requestedSquash commit -- not updating HEAD$ git commit -m "test-v2"[test 8d9b6a4] test-v2 1 file changed, 5 insertions(+)$ git log --oneline --graph* 8d9b6a4 (HEAD -> test) test-v2* 0e9357a test-v1* d226468 init$ git push...Writing objects: 100% (3/3), 285 bytes | 285.00 KiB/s, done.Total 3 (delta 2), reused 0 (delta 0)remote:remote: To create a merge request for test, visit:remote: https://codehub.devcloud.huaweicloud.com/codehub/nnnnnn/newmerge...

如果對 git 命令行不熟悉，又沒有熟悉的客戶端工具支持較為復雜的合并選項，這些操作看起來有些復雜。所以如果不是執(zhí)著于清除一些敏感(silly)的提交記錄，使用 DevCloud 的合并請求可能更為有效。具體操作在后面的章節(jié)中會有介紹。

合并請求及評審

曾經(jīng)有位同事說他們團隊中的新人向代碼倉庫中提交的代碼太亂，問能不能從服務器中撤銷這些提交。雖然不是不可以，但撤銷總是比較麻煩。對于有新人加入團隊的情況，結(jié)對編程可能可以讓新人快速融入團隊，進行高質(zhì)量的開發(fā)和提交。

如果條件不具備，可以參考 Martin Fowler 寫的 Reviewed Commits (https://martinfowler.com/articles/branching-patterns.html#reviewed-commits)這種分支模式，團隊非核心人員提交的代碼經(jīng)過評審后，才能被合并到受控分支。

這種分支模式可與特性分支結(jié)合使用，比如開發(fā)人員小王在開始一項工作任務時，首先基于現(xiàn)有的開發(fā)分支 dev 建立一個特性分支 feature-w2, 在開發(fā)完成后，拉取 dev 的最新提交合并入 feature-w2, 解決完可能出現(xiàn)的合并沖突，將 feature-w2 推送到中心倉庫，然后發(fā)起從 feature-w2 向 dev 分支的合并請求。評審人收到合并請求后，進行代碼審查和意見反饋。在評審通過后，具有權(quán)限的人員執(zhí)行合并操作，并刪除不再使用的分支 feature-w2。DevCloud 可以對這種模式提供很好的支持。

小王在將 feature-w2 推送到中心倉庫時，會收到一個提示信息，內(nèi)含為 feature-w2 新建合并請求的 URL 鏈接，詳見上節(jié) git push 的返回信息。打開此鏈接就可以在 DevCloud 中新建合并請求。在 DevCloud 代碼倉庫的合并請求頁簽下，可以查看現(xiàn)有的合并請求，也可以從此頁面新建合并請求。

合并請求頁簽

新建合并請求

在新建合并請求的過程中, DevCloud 會檢查準入條件，比如分支之間是否有差異，是否有沖突等。

新建合并請求詳細信息

在新建合并請求頁面，點擊標題編輯框, DevCloud 會基于歷史提交信息生成一個默認的標題，修改標題(可選)，然后添加合并人和評審人(可選)后，單擊確定按鈕完成合并請求的創(chuàng)建。

評審人在合并請求頁簽下可以查看所有的合并請求，對選定的合并請求進行評論，包括其他評論信息和反饋信息、文件變更和提交記錄，從而決定關閉或拒絕合并請求。合并人單擊頁面右上角的“普通合并” 或 “刪除源分支合并” 完成合并操作。其中 “刪除源分支合并” 很好地支持了短特性分支實踐，可以避免留存過多不再使用的分支，減少混亂。

評審合并請求

Reviewed Commits 分支模式要求反饋要足夠迅速，如果反饋時間過長，小王就可能需要重新回想原先進行的工作，而且可能會因為 dev 分支上有了新的提交，出現(xiàn)合并沖突，造成不必要的浪費。

＋“CH050791”后 回“冬哥”，可入qun交流~

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結(jié)

以上是生活随笔為你收集整理的如何新建分支上传_Git分支策略及操作演示1|IDCF FDCC认证学员作品的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。