一個 Git 分支協做模式的進化故事

時間 2019-11-06

標籤一個 git 分支模式進化故事欄目 Git 简体版

原文原文鏈接

本文囊括2076字git

Git 做爲一個強大的分佈式版本控制系統，對比 SVN、CVS 等版本控制系統，其架構和設計在研發管理和協做上有着極大的優點。在我的開發的代碼管理和團隊協做過程當中，合理使用分支能在極大程度上提高管理效率。這篇文章根據張3、李4、趙六開發成長曆程改編，解讀了在企業開發過程當中進行協做開發的分支模型。程序員

從不用版本管理到使用 Git 分支管理的故事，也就是從這個時候開始的。。。服務器

某公司只有一個程序員，一開始並無版本管理的概念。項目開發只有一我的在參與，因此也沒用版本管理工具。

後來，老闆又招了兩個程序員，老闆說： 「研發管理要規範！」，通過一番調研，選用了 Git，三我的開始使用 Git 進行開發上的協做。

一開始，三我的都是經過一個倉庫，在 master 分支上進行協做。天天上班第一件事就是先把最新的代碼從服務器上拉到本地的 master 分支，下班前再把代碼給推到服務器上的 master 分支，項目就這樣展開了協做。

3人經過本地倉庫 master 分支向遠程倉庫 master 分支提交代碼網絡

解決頻繁的代碼提交衝突 架構

協做了幾天，團隊發現提交代碼 master 時候，常常產生代碼衝突，要麼張三和李四的代碼衝突，要麼李四跟趙六的代碼衝突。這時總要有人把代碼拉下來解決衝突。才能保證後續開發工做順利進行。同時，因爲缺乏代碼審查。部分質量較差的代碼和無關內容也時不時被提交上去。分佈式

團隊在解決衝突和代碼重構的問題上花費了很多精力。。。工具

爲了解決單一分支頻繁更新容易發生衝突的問題，三人開始研究使用分支的方式進行協做。經過在本地 master 檢出新分支，修改後將新分支推送到遠程倉庫，再經過 拉取合併請求（Pull Request）在遠程倉庫上合併分支到 master 分支。最後再把代碼從遠程 master 拉取到本地 master 進行更新。在這個基礎上，團隊也開始展開相互的 代碼審查（Code Review）工做。

本地 master 分支檢出新分支開發推送到遠端倉庫後，經過 Pull Request 合併到 master，而後拉回本地 master。post

初步解決代碼迭代版本問題spa

通過一番折騰，幾我的的協做總算能比較穩定地進行。在後續數週內，團隊開發工做順利展開，項目也得以落地，進入快速迭代階段。爲了解決迭代的版本問題，團隊使用分支對每次版本發佈檢出一個分支進行保留。

經過遠程倉庫 master 分支在版本發佈時，檢出一個以版本號命名的分支，做爲特定版本管理。設計

團隊增加帶來的困擾

兩個月後，公司迎來了業務的快速增加。技術團隊從原來三我的快速增加到十來我的。原來的成員開始帶着新人作業務，隨着團隊的增加，原有的協做方式再次遇到各類各樣的問題。通過短短一週的磨合，三人無比疲憊地坐到一塊兒，對過去一週遇到的問題進行了覆盤：

隨着協做人數增多，遠程倉庫分支數量快速增加，查找起來很麻煩，常常出現分支重名問題。
分支命名混亂，提交新功能的分支和修復Bug的分支常常混淆在一塊。
版本迭代的速度太快，產生了一大堆的 Realease 分支，又帶來了一堆的管理問題。
還沒來得及合併或獨立維護的分支，時間久了容易出現管理遺漏和維護混亂。
雖然有 Code Review，但程序的 Bug 數和 Crash 頻率明顯隨團隊規模而增加，生產事故發生率和回滾率提升。
還有人把手頭未完成開發的分支扔到遠程倉庫進行託管。

通過討論三我的都意識到了問題所在，但無奈三人對於多人協做開發經驗很少，討論無果後，決定各自調研，再對比討論。兩天後，三我的帶着方案展開了探討。

✗ℨ

單個倉庫仍是多個倉庫？

在倉庫管理的方案上，張三主張使用單倉庫多分支的方式進行管理，李四則主張使用 多倉庫多分支 的方式進行管理。

通過討論，爲了下降反覆增長加倉庫協做者名單的協做成本，三人統一意見繼續保留使用 單倉庫多分支 的方式。

用「分支模型」規範分支管理

在分支策略上，張三提出了使用分支模式做爲分支管理規範化的解決方案，從 分支類型、用途 等角度規範開發的協做方式。

通過一番討論，三人達成了一致的意見，並針對上面的 分支模型 提出了些許細節的調整。

靈活使用 Git tag 和發行版管理功能

針對單個倉庫協做可能存在分支數量增加的問題，張三提出經過 Git tag 來取代 release/* 版本分支的做用。

在 git 中，標籤（tag）是特定提交（commit) 的一個指針，也就是每一個 tag 對應一個特定的 commit。 release/* 系列分支在實質上就是合併到 Product (master) 分支上成爲一個特殊提交，因此 tag 的存在使得沒有必要保留 release/* 分支。
另外，通常形如[碼雲]這樣的 git 代碼託管平臺，自己自帶「發行版（Release）」功能。
經過 git 自己只能記錄項目的修改，而版本發佈帶來的項目構建物（特別是二進制文件）自己在某種意義上就不適合經過 git 進行存儲。
經過「發行版（Release）」功能，能夠將對應版本的源代碼和生成的項目構建物（好比exe/dmg）保存下來，還支持編寫對應的 Changelog，便於查找下載。

使用 Git-flow 腳本規範本地分支和開發

除了在遠程倉庫上的管理方案，張三還建議提倡團隊成員經過 [git-flow] 一系列的腳本擴展，規範本地的分支管理和開發流程。現網絡上最流行的 git-flow 方案應該是 AVH 版 git-flow： nvie.com/posts/a-suc… 。經過安裝後，開發成員能夠在本地經過對項目的各種功能分支進行定義。