應用系統(tǒng)雙模研發(fā)的GIT分支模型介紹

1、 應用系統(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ī)劃的準確性 PAGEREF _Toc526844367 h 19 HYPERLINK l _Toc526844368 6.通過代碼挑煉實現(xiàn)大團隊協(xié)作開發(fā)重點版本快捷傳遞 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ā)任務的基礎上還要承載新市場形勢下的快速迭代的研發(fā)需求，由于傳統(tǒng)企業(yè)IT研發(fā)的歷史原因與系統(tǒng)應用場景的特殊性，無法直接采用現(xiàn)有成熟的Git代碼分支模型進行代碼管理，如何在這種復雜協(xié)作型項目中進行代

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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