1、 應(yīng)用系統(tǒng)雙模研發(fā)的GIT分支模型介紹目 錄 TOC o 1-3 h z u HYPERLINK l _Toc526844362 0.背景 PAGEREF _Toc526844362 h 3 HYPERLINK l _Toc526844363 1.常見的Git分支模型介紹 PAGEREF _Toc526844363 h 3 HYPERLINK l _Toc526844364 2.傳統(tǒng)企業(yè)雙模研發(fā)的趨勢 PAGEREF _Toc526844364 h 7 HYPERLINK l _Toc526844365 3.適用于傳統(tǒng)企業(yè)雙模研發(fā)的全場景分支模型 PAGEREF _Toc526844365 h

2、 8 HYPERLINK l _Toc526844366 4.通過分支規(guī)范化命名降低代碼管理的成本 PAGEREF _Toc526844366 h 19 HYPERLINK l _Toc526844367 5.統(tǒng)一的分支粒度原則提升功能分支規(guī)劃的準(zhǔn)確性 PAGEREF _Toc526844367 h 19 HYPERLINK l _Toc526844368 6.通過代碼挑煉實(shí)現(xiàn)大團(tuán)隊(duì)協(xié)作開發(fā)重點(diǎn)版本快捷傳遞 PAGEREF _Toc526844368 h 20 HYPERLINK l _Toc526844369 7.分支按需創(chuàng)建解決特殊場景中的代碼管理與測試混亂難題 PAGEREF _Toc5

3、26844369 h 22 HYPERLINK l _Toc526844370 8.通過淺克隆解決歷史記錄數(shù)量龐大問題 PAGEREF _Toc526844370 h 23 HYPERLINK l _Toc526844371 9.通過稀疏檢出解決開發(fā)人員本地代碼工程巨大的問題 PAGEREF _Toc526844371 h 24背景近年來，傳統(tǒng)企業(yè)IT研發(fā)面臨的“雙模研發(fā)”場景越來越多，在完成瀑布式研發(fā)任務(wù)的基礎(chǔ)上還要承載新市場形勢下的快速迭代的研發(fā)需求，由于傳統(tǒng)企業(yè)IT研發(fā)的歷史原因與系統(tǒng)應(yīng)用場景的特殊性，無法直接采用現(xiàn)有成熟的Git代碼分支模型進(jìn)行代碼管理，如何在這種復(fù)雜協(xié)作型項(xiàng)目中進(jìn)行代

4、碼分支管理是項(xiàng)目管理和開發(fā)人員亟待解決的問題。本文分析了傳統(tǒng)企業(yè)軟件研發(fā)的特點(diǎn)，提出了一種適用于復(fù)雜協(xié)作型項(xiàng)目、兼容“瀑布+敏捷”雙模研發(fā)的Git代碼分支管理模型，并根據(jù)傳統(tǒng)企業(yè)IT研發(fā)特點(diǎn)制定了相應(yīng)的分支管理與操作規(guī)范，解決了大團(tuán)隊(duì)協(xié)作研發(fā)中的諸多代碼管理難題，并在農(nóng)業(yè)銀行信貸管理系統(tǒng)群（C3）中進(jìn)行了應(yīng)用實(shí)踐。常見的Git分支模型介紹Git是目前世界上最先進(jìn)的分布式版本控制系統(tǒng)，可以有效、高速的處理從小到非常大的項(xiàng)目版本管理。Git基于分支進(jìn)行代碼開發(fā)，分支模型是開發(fā)團(tuán)隊(duì)為了更有效的對(duì)代碼進(jìn)行管理而提出的分支管理方式。為了使Git能夠適合企業(yè)復(fù)雜的開發(fā)場景、更好的與持續(xù)集成、持續(xù)交付流水線

5、進(jìn)行集成，不同的研發(fā)團(tuán)隊(duì)根據(jù)自己的系統(tǒng)架構(gòu)、項(xiàng)目特點(diǎn)與產(chǎn)品的交付方式設(shè)計(jì)了不同的分支模型。隨著敏捷研發(fā)等新的研發(fā)模式逐漸被軟件研發(fā)行業(yè)認(rèn)可，分支管理模型作為代碼管理中的重要組成部分成為大家越來越關(guān)注的話題。由于歷史原因和系統(tǒng)應(yīng)用場景的特殊性，很多項(xiàng)目在開發(fā)過程中經(jīng)常存在瀑布與敏捷兩種模式并存的情形，如何在這種復(fù)雜協(xié)作型項(xiàng)目中進(jìn)行代碼分支管理是項(xiàng)目管理和開發(fā)人員亟待解決的問題。業(yè)內(nèi)都在探索適合自己系統(tǒng)與團(tuán)隊(duì)特色的分支模型，流行的分支模型有Git flow模型、Github flow模型、主線開發(fā)模型等。（1）Git flow：如圖1所示，Git flow是基于Git的強(qiáng)大分支能力所構(gòu)建的一套軟件

6、開發(fā)工作流，將軟件生命周期中的各類活動(dòng)歸并到不同的分支上，實(shí)現(xiàn)了軟件開發(fā)過程不同操作的相互隔離。Git flow包含Master、Develop兩個(gè)永久存在的長期分支和Feature、Release、Hotfix等短期輔助性分支，Develop分支用于代碼開發(fā)，Master分支用于版本發(fā)布，完成代碼開發(fā)并準(zhǔn)備發(fā)布時(shí)所有的代碼變更都合并到Master分支；輔助性分支為短期分支，用于完成功能開發(fā)與特性跟蹤、產(chǎn)品的發(fā)布準(zhǔn)備以及快速修復(fù)線上問題。Git flow的優(yōu)點(diǎn)是分支清晰可控，缺點(diǎn)是相對(duì)復(fù)雜，需要同時(shí)維護(hù)兩個(gè)長期分支，同時(shí)Feature分支長期存在時(shí)容易產(chǎn)生代碼不一致問題。圖1 Git flow

7、（2）Github flow：Github flow是Git flow的簡化版，它是G使用的工作流程。它只有一個(gè)長期分支Master，從Master拉出新分支進(jìn)行代碼開發(fā)，新分支開發(fā)完成后向Master發(fā)起一個(gè)pull request（簡稱PR），請(qǐng)求進(jìn)行代碼評(píng)審與分支合并。Github flow的最大優(yōu)點(diǎn)就是簡單，適于“持續(xù)發(fā)布”的產(chǎn)品，缺點(diǎn)是不適用于產(chǎn)品上線時(shí)間不確定等復(fù)雜的開發(fā)場景。（3）主線開發(fā)模型:如圖2所示，主線開發(fā)模型是同一個(gè)產(chǎn)品的所有的開發(fā)人員共享一個(gè)trunk，開發(fā)人員可以有自己的私有分支，但所有修改最后都會(huì)回到主干，只有在Release時(shí)才會(huì)創(chuàng)建Release Branch

8、，由Release Engineer進(jìn)行維護(hù)，發(fā)布分支是主干某個(gè)時(shí)點(diǎn)的快照，必要時(shí)通過cherry-pick從主干挑揀代碼到發(fā)布分支?；谥鞲傻拈_發(fā)的優(yōu)點(diǎn)是保證了所有用戶看到的都是同一份代碼的最新版本，避免了合并分支時(shí)的麻煩，缺點(diǎn)是不適于瀑布開發(fā)模型，同時(shí)對(duì)開發(fā)人員和發(fā)布分支的維護(hù)人員的技術(shù)要求比較高。圖2 主線開發(fā)模型傳統(tǒng)企業(yè)雙模研發(fā)的趨勢縱觀大型企業(yè)面臨的市場環(huán)境，產(chǎn)品快速迭代的壓力撲面而來，誰先推出符合市場需求的產(chǎn)品誰就占領(lǐng)了先機(jī)，對(duì)企業(yè)IT研發(fā)的快速交付能力提出了新的要求和挑戰(zhàn)，各大型企業(yè)IT研發(fā)領(lǐng)域都提出了敏捷研發(fā)的要求，同時(shí)對(duì)研發(fā)中的代碼管理方式提出了新的要求。但由于傳統(tǒng)企業(yè)本身業(yè)

9、務(wù)的特殊性，軟件研發(fā)存在很多特殊研發(fā)場景：產(chǎn)品線龐雜，開發(fā)架構(gòu)、運(yùn)行架構(gòu)各異，且存在大量遺留系統(tǒng)；很多IT產(chǎn)品研發(fā)往往有著明確的需求和明確的研發(fā)時(shí)間期望，并不完全符合經(jīng)典的敏捷場景；研發(fā)團(tuán)隊(duì)規(guī)模較大，IT管理文化有別于互聯(lián)網(wǎng)企業(yè)等；傳統(tǒng)IT研發(fā)交付測試的產(chǎn)品不一定能夠及時(shí)投產(chǎn)，存在長期處于測試并迭代優(yōu)化的狀態(tài)，同時(shí)由于業(yè)務(wù)的復(fù)雜性、多變性及涉及部門的多樣性，需求變更、延期多，導(dǎo)致產(chǎn)品交付日期不可控，存在長期未上線的功能，并且功能之間存在較強(qiáng)的代碼依賴性等問題?，F(xiàn)有的分支模型各有千秋，都有最佳的應(yīng)用場景，但由于傳統(tǒng)企業(yè)IT研發(fā)團(tuán)隊(duì)與系統(tǒng)的特殊性，不能直接照搬某一種分支模型。為了兼容“瀑布+敏捷”

10、的雙模研發(fā)，對(duì)代碼分支管理提出了更高的要求，如何探索與實(shí)踐高效、易用的分支模型越來越受到傳統(tǒng)企業(yè)研發(fā)領(lǐng)域的關(guān)注。適用于傳統(tǒng)企業(yè)雙模研發(fā)的全場景分支模型基于傳統(tǒng)企業(yè)IT雙模研發(fā)場景的特點(diǎn)，我們?cè)诔浞盅芯繕I(yè)內(nèi)典型分支模型的基礎(chǔ)上提出了一種適用于復(fù)雜協(xié)作型項(xiàng)目、兼容“瀑布+敏捷”雙模研發(fā)的全場景代碼分支管理模型。3.1 全場景分支模型的組成如圖3所示，我們提出的全場景分支模型包含Master分支、Dev分支、Test分支3個(gè)長期分支和功能分支、投產(chǎn)分支、其他測試分支3類短期分支。圖3 全場景分支模型Master分支是主分支，始終保持最新的投產(chǎn)在運(yùn)行代碼，通過標(biāo)記區(qū)分不同的投產(chǎn)窗口（投產(chǎn)窗口是系統(tǒng)的上

11、線時(shí)點(diǎn),對(duì)應(yīng)一個(gè)唯一的正式代碼版本，如圖中“窗口1”、“窗口2”、“窗口3”所示），所有其他分支都從Master分支創(chuàng)建，普通開發(fā)人員不能直接在Master分支進(jìn)行代碼推送，必須通過拉取請(qǐng)求的方式進(jìn)行代碼更新；Dev分支用于代碼的存儲(chǔ)、共享及協(xié)作開發(fā)，不合并回Master分支，根據(jù)具體研發(fā)情況對(duì)Dev分支進(jìn)行定期清理；Test分支用于發(fā)布功能測試，保持功能測試的最新代碼，根據(jù)運(yùn)行情況從Master分支進(jìn)行階段性更新，普通開發(fā)人員不能直接在Test分支進(jìn)行代碼推送，只能通過拉取請(qǐng)求的方式進(jìn)行代碼合并，根據(jù)具體研發(fā)情況對(duì)Test分支進(jìn)行定期清理；功能分支（即特性分支）從Master分支創(chuàng)建，用于管

12、理某個(gè)功能的代碼，用于發(fā)布功能測試與投產(chǎn)，開發(fā)人員一般不直接在功能分支進(jìn)行代碼提交，而是通過將 Dev 分支已經(jīng)開發(fā)完成的代碼通過工具整理到功能分支；投產(chǎn)分支包含Rel分支和Hotfix分支，用于投產(chǎn)準(zhǔn)備及投產(chǎn)發(fā)布，從Master分支創(chuàng)建，投產(chǎn)完成后將其合并到主分支并刪除，其中Hotfix分支用于緊急缺陷修復(fù)；其他測試分支是臨時(shí)測試分支，如正式上線前的區(qū)域性測試等，可以直接從Test分支新建分支，也可以從Master分支拉取分支后再合并待測試內(nèi)容。在開發(fā)任務(wù)分解完成后，開發(fā)人員基于Dev分支進(jìn)行協(xié)作開發(fā)，開發(fā)完成后需要進(jìn)行功能測試時(shí)，基于最新的Master分支新建功能分支，開發(fā)人員將待測試內(nèi)容

13、通過cherry-pick的方式從Dev分支整理到功能分支，并通過在線pull request的方式發(fā)布到Test分支進(jìn)行測試，測試完成后同樣通過pull request的方式發(fā)布到投產(chǎn)分支進(jìn)行投產(chǎn)，投產(chǎn)完成后對(duì)所有的短期過時(shí)分支進(jìn)行清理。3.2 通過共享開發(fā)分支實(shí)現(xiàn)瀑布型場景的即時(shí)研發(fā)在雙模研發(fā)項(xiàng)目中的瀑布型開發(fā)場景是需要進(jìn)行長期開發(fā)的項(xiàng)目，瀑布型開發(fā)中往往涉及到跨職能組或部門的大團(tuán)隊(duì)協(xié)作，經(jīng)常存在一個(gè)或多個(gè)大型系統(tǒng)的協(xié)同研發(fā)，由于項(xiàng)目的特殊性經(jīng)常面臨項(xiàng)目周期不可控、開發(fā)階段需求尚未完全明確、在項(xiàng)目最終投產(chǎn)前存在大量需求變更、延期等常見問題。在此開發(fā)場景中，開發(fā)人員可以在需求粒度、投產(chǎn)日期不

14、完全明確的情況下直接基于Dev分支進(jìn)行代碼修改提交，待到開發(fā)功能基本確定、測試點(diǎn)基本明確的情況下，申請(qǐng)功能分支，將Dev分支已經(jīng)完成開發(fā)的功能代碼挑揀 (通過 Git 的 cherry pick 命令實(shí)現(xiàn))到功能分支，將功能分支合并到Test分支進(jìn)行功能測試，在投產(chǎn)時(shí)將功能分支合并到Rel分支進(jìn)行投產(chǎn)驗(yàn)證及投產(chǎn)包構(gòu)建，此流程能夠很好兼顧瀑布型研發(fā)開發(fā)周期長的特點(diǎn)，方便了研發(fā)功能的整體規(guī)劃與投產(chǎn)。3.3 通過短平快的分支實(shí)現(xiàn)迭代型場景的研發(fā)在雙模研發(fā)項(xiàng)目中的迭代開發(fā)場景包括臨時(shí)項(xiàng)目、緊急變更或缺陷修復(fù)等，在此類開發(fā)場景中，開發(fā)人員直接申請(qǐng)新的功能分支，基于最新的投產(chǎn)代碼進(jìn)行開發(fā)，開發(fā)完成后將功能

15、分支合并到Test分支進(jìn)行功能測試，完成功能測試后合并到Rel分支進(jìn)行投產(chǎn)驗(yàn)證與投產(chǎn)打包，此流程簡單清晰，便于功能的快速測試與投產(chǎn)。3.4 通過分支對(duì)齊避免未測試代碼帶入生產(chǎn)環(huán)境分支對(duì)齊指的是多個(gè)分支之間的前后順序，即若源分支有新增的commit id，在該分支合并到目標(biāo)分支之前，源分支是先于目標(biāo)分支的，分支完成合并后則源分支與目標(biāo)分支是對(duì)齊的。如下圖所示，基于分支對(duì)齊，可以確定要發(fā)布投產(chǎn)的功能分支是否已經(jīng)發(fā)布功能測試以及在功能測試發(fā)布后是否有新的代碼修改，并通過分支評(píng)審的方式拒絕未完成測試的分支合并到投產(chǎn)分支，避免了傳統(tǒng)配置管理中的人工代碼整理導(dǎo)致的未測試的代碼誤發(fā)布到投產(chǎn)的問題。圖4 TF

16、S中的分支對(duì)齊3.5 通過分支的權(quán)限控制與多級(jí)評(píng)審機(jī)制確保版本安全在全場景分支模型中，對(duì)分支添加了強(qiáng)制權(quán)限控制，開發(fā)人員擁有Dev分支與功能分支的代碼提交、推送權(quán)限，但對(duì)于Test分支、Rel分支、Master分支只能通過拉取請(qǐng)求進(jìn)行合并，避免了代碼的誤修改。同時(shí)對(duì)于所有分支，開發(fā)人員只能增量修改、不能存量刪除，保證了整個(gè)代碼庫的安全性與可追溯性。在基于Git進(jìn)行代碼開發(fā)時(shí)，由于分支包含的是全量的系統(tǒng)代碼，為了保證分支中修改代碼的安全性，我們引入了可視化的多級(jí)分支評(píng)審機(jī)制，功能分支到Test分支，功能分支到Rel分支，Rel分支到Master分支的拉取請(qǐng)求都設(shè)置了代碼評(píng)審機(jī)制，針對(duì)研發(fā)模塊進(jìn)行

17、了分支策略設(shè)置（如圖5所示），保證關(guān)鍵核心文件要經(jīng)過系統(tǒng)控制人員審核、跨模塊文件修改要經(jīng)過對(duì)方的負(fù)責(zé)人審批，確保代碼不會(huì)被誤修改、誤合并，并通過可視化的方法提高了協(xié)同研發(fā)與問題解決的效率。圖5 TFS中的Git分支策略設(shè)置3.6 通過代碼分庫實(shí)現(xiàn)關(guān)鍵配置文件的扎口式管理在雙模研發(fā)項(xiàng)目中，尤其是跨團(tuán)隊(duì)協(xié)同的大項(xiàng)目，部署環(huán)境依賴性文件、生產(chǎn)環(huán)境安全配置文件等核心文件需要進(jìn)行特殊的處理，為此我們?cè)诜种碛腥看a的基礎(chǔ)上設(shè)計(jì)了關(guān)鍵代碼分庫存儲(chǔ)的方式，即將特殊文件從主流分支中剝離，在另一個(gè)庫中由專人負(fù)責(zé)配置管理，開發(fā)人員所見的分支擁有全量的開發(fā)環(huán)境的代碼，在持續(xù)集成與版本發(fā)布的過程中，我們?cè)O(shè)計(jì)了文件自

18、動(dòng)替換的方式（如圖6所示），使整個(gè)過程對(duì)于開發(fā)人員來說是透明的，在保證了特殊文件便于開發(fā)人員操作的基礎(chǔ)上保證了文件的安全性，確保測試文件不會(huì)誤帶入生成環(huán)境，同時(shí)通過自動(dòng)替換的方式實(shí)現(xiàn)了代碼的一次編譯多環(huán)境發(fā)布。圖6 在TFS的生成定義中配置自動(dòng)化腳本3.7 全場景分支模型在雙模研發(fā)中的應(yīng)用優(yōu)勢與常見分支模型相比，全場景分支模型下具有以下優(yōu)點(diǎn)：（1）支持雙模研發(fā)模式：支持瀑布、敏捷兩種研發(fā)模式，有效應(yīng)對(duì)復(fù)雜多變需求的并行開發(fā)、多時(shí)點(diǎn)上線；（2）支持大團(tuán)隊(duì)協(xié)同開發(fā)：團(tuán)隊(duì)開發(fā)分支與功能特性分支相結(jié)合，適合跨職能組的大團(tuán)隊(duì)并行協(xié)同開發(fā)，在開發(fā)階段所有開發(fā)人員的代碼修改都會(huì)及時(shí)推送到Dev分支，團(tuán)隊(duì)人員

19、可以及時(shí)看到其他成員的代碼更新，方便代碼的實(shí)時(shí)共享和復(fù)用。（3）有效避免了功能分支的長期存在引發(fā)的文件沖突問題：在全場景分支模型中，功能分支是“事后整理”，即功能開發(fā)完成并明確了測試與投產(chǎn)時(shí)間后再進(jìn)行功能分支的申請(qǐng)與代碼整理，避免了Git flow模型中先新建分支再開發(fā)導(dǎo)致的分支長期存在引發(fā)的大量文件沖突問題。（4）簡化代碼依賴管理：由于最新的開發(fā)代碼都可以在Dev分支獲取，保證了所有代碼依賴的都是最新版本,各開發(fā)模塊和開發(fā)人員可以很好的解決代碼依賴問題。每當(dāng)代碼變動(dòng)，會(huì)及時(shí)反饋到代碼依賴方，能夠提前發(fā)現(xiàn)協(xié)作開發(fā)中出現(xiàn)的問題。（5）有效應(yīng)對(duì)復(fù)雜多變的需求和開發(fā)場景：在該分支模型中，開發(fā)人員先基

20、于Dev分支進(jìn)行開發(fā)基于功能分支進(jìn)行代碼整理，能夠有效應(yīng)對(duì)需求邊界不清晰、需求細(xì)節(jié)不明確、需求上線時(shí)間待確定等不確定的需求和代碼拆分、合并、延期等特殊開發(fā)場景。（6）分支代碼的自主與持續(xù)發(fā)布：在該分支模型中，開發(fā)人員在完成功能開發(fā)后可以及時(shí)的進(jìn)行版本的的自主發(fā)布，減少了人工操作，實(shí)現(xiàn)了版本的快速交付。（7）代碼強(qiáng)制評(píng)審：在該分支模型中，我們基于pull request實(shí)現(xiàn)了可視化的分支代碼的多級(jí)強(qiáng)制評(píng)審，功能分支必須按序合并到測試分支、窗口分支和主分支，有效應(yīng)對(duì)了代碼合并過程中的誤修改問題，提升了代碼開發(fā)的質(zhì)量。（8）便捷的代碼對(duì)比與分析：基于Dev分支的線性代碼開發(fā)與Master分支的投產(chǎn)節(jié)

21、點(diǎn)標(biāo)記方便了開發(fā)人員進(jìn)行代碼的查找、歷史代碼的版本對(duì)比與分析。同時(shí)，在實(shí)踐中我們基于Git的開源特性定制了便于分支管理、持續(xù)集成、自動(dòng)化測試的工具，將分支與功能工作項(xiàng)及投產(chǎn)窗口進(jìn)行關(guān)聯(lián)，實(shí)現(xiàn)了基于需求與功能的分支代碼管理，并基于TFS的可視化、流程化的方式（如下圖所示）實(shí)現(xiàn)投產(chǎn)任務(wù)的統(tǒng)一管理與集中發(fā)布，完成了代碼分支與研發(fā)工作的一體化管理。圖7 分支發(fā)布與產(chǎn)品部署通過分支規(guī)范化命名降低代碼管理的成本Git分支在提供極大的靈活性的同時(shí)，難免會(huì)存在分支管理混亂的問題，尤其是在大團(tuán)隊(duì)協(xié)作中，不規(guī)范的分支命名容易導(dǎo)致分支的查找與切換困難，甚至?xí)?dǎo)致代碼誤提到其他分支?；诖耍覀兘Y(jié)合該系統(tǒng)研發(fā)特點(diǎn)提出

22、了適合跨團(tuán)隊(duì)協(xié)作的功能分支命名規(guī)范。功能分支命名構(gòu)成如下：“GIT庫名稱/研發(fā)團(tuán)隊(duì)簡稱_變更來源及編號(hào)_功能簡稱及工作項(xiàng)編號(hào)_擬投產(chǎn)時(shí)間”。以下為分支名稱示例：“CMS_F/fd_xm2018189_mcl192659_20180809”的含義是前臺(tái)的分支，歸屬于fd團(tuán)隊(duì)，項(xiàng)目編號(hào)為2018189，對(duì)應(yīng)的研發(fā)功能為“mcl”，對(duì)應(yīng)的功能編號(hào)為192659，投產(chǎn)日期為2018年8月9日。統(tǒng)一的分支粒度原則提升功能分支規(guī)劃的準(zhǔn)確性在該系統(tǒng)中進(jìn)行團(tuán)隊(duì)協(xié)作開發(fā)的過程中，由于瀑布型研發(fā)與迭代型研發(fā)并存，并且涉及到跨團(tuán)隊(duì)、跨項(xiàng)目的協(xié)作，在多場景并存的情況下，分支規(guī)劃的粒度是一個(gè)要重點(diǎn)考慮與設(shè)計(jì)的關(guān)鍵點(diǎn)。為

23、此我們?cè)谠撓到y(tǒng)全場景分支模型中制定了“以同時(shí)投產(chǎn)的最小獨(dú)立功能點(diǎn)為分支規(guī)劃的基本粒度”的分支粒度規(guī)劃原則，同時(shí)投產(chǎn)是指能夠在很大概率上確定開發(fā)的功能點(diǎn)能夠在同一窗口投產(chǎn)，最小是指只要分支間沒有依賴關(guān)系就可以拆分出一個(gè)單獨(dú)的功能分支進(jìn)行維護(hù)，獨(dú)立是指單個(gè)分支能夠正常的完成功能的開發(fā)、聯(lián)調(diào)、測試，并且具備獨(dú)立投產(chǎn)的能力。在此基本原則下規(guī)劃的分支可以保證功能分支的最小變動(dòng)性。通過代碼挑煉實(shí)現(xiàn)大團(tuán)隊(duì)協(xié)作開發(fā)重點(diǎn)版本快捷傳遞在該系統(tǒng)中進(jìn)行團(tuán)隊(duì)協(xié)作開發(fā)的過程中，代碼開發(fā)過程首先要經(jīng)過Dev分支的共享開發(fā)，申請(qǐng)功能分支后將Dev分支的開發(fā)內(nèi)容挑揀到功能分支，同時(shí)開發(fā)人員在代碼管理過程中經(jīng)常會(huì)用到歷史版本的選

24、取、為其他人員傳遞代碼文件等操作。針對(duì)分支間經(jīng)常存在代碼依賴關(guān)系，我們提供了“整體摘取、局部挑選”（如下圖所示）的方式來實(shí)現(xiàn)代碼的快捷傳遞，整體摘取用于保證開發(fā)功能的完整性，即將分支A上的一個(gè)提交作為一個(gè)整體傳遞到分支B中，“局部摘取”用于特殊文件特殊版本的處理，即滿足特殊的開發(fā)要求，所有的操作通過界面一鍵式完成，無需開發(fā)人員通過線下手工傳遞代碼，提高了版本共享的效率與準(zhǔn)確性。圖1 通過TortoiseGit實(shí)現(xiàn)了commit級(jí)與文件級(jí)代碼的挑揀分支按需創(chuàng)建解決特殊場景中的代碼管理與測試混亂難題在該系統(tǒng)雙模研發(fā)場景中，瀑布型研發(fā)與迭代型研發(fā)經(jīng)常并行，投產(chǎn)日期經(jīng)常交替，投產(chǎn)功能點(diǎn)存在臨時(shí)延期、拆

25、分、合并等特殊場景，同時(shí)對(duì)于特定功能的特定階段，經(jīng)常需要經(jīng)過多個(gè)專有的測試環(huán)境進(jìn)行測試，在傳統(tǒng)的代碼管理方式中缺乏有效的代碼管理方式導(dǎo)致代碼管理混亂、代碼一致性差，尤其是在多個(gè)測試環(huán)境長時(shí)間并行的情況下各個(gè)環(huán)境的代碼差異巨大，“所測非所投”現(xiàn)象普遍存在，影響功能測試、其他臨時(shí)測試的順利開展，同時(shí)代碼拆分、合并、撤銷等操作工作量大、易發(fā)生錯(cuò)誤。針對(duì)雙模研發(fā)場景中特殊難題，我們通過對(duì)長期分支、短期分支進(jìn)行統(tǒng)一規(guī)劃，制定分支合并過程中的單向傳遞規(guī)則，對(duì)投產(chǎn)分支實(shí)行窗口化管理，對(duì)測試分支實(shí)行定向拉取管理等一系列措施實(shí)現(xiàn)了分支的按需創(chuàng)建、按需合并與定期銷毀，并通過規(guī)范的標(biāo)簽管理、注釋管理實(shí)現(xiàn)了代碼版本的清晰分類、定向追溯。功能分支的按需合并，增加了功能測試、投產(chǎn)發(fā)布的靈活性，提高了版本制作的效率，同時(shí)保證了不同測試環(huán)境版本的強(qiáng)一致性。通過淺克隆解決歷史記錄數(shù)量龐大問題在該系統(tǒng)的協(xié)作研發(fā)過程中，隨著研發(fā)時(shí)間的推進(jìn)，本地會(huì)積累大量的代碼歷史記錄，為了提升開發(fā)人員的代碼對(duì)比及摘取效率，同時(shí)節(jié)約磁盤空間，我們提供了代碼淺克隆的機(jī)制，具體操作參見圖2所示Git命令。圖2 代碼淺克隆操作通過實(shí)踐對(duì)比發(fā)現(xiàn)，開發(fā)人員本地的代碼歷史數(shù)據(jù)量減少極為明顯，減少了本地?zé)o效分支與標(biāo)簽的克隆，簡化了本地工作區(qū)的管理。通過稀疏檢出解決開發(fā)人員本地代碼工程巨大的問題整個(gè)系統(tǒng)中存在數(shù)十個(gè)大的研發(fā)模塊，眾多模塊的代碼增加