從不用版本管理到使用 Git
分支管理的故事，也就是從這個時候開始的。。。
某公司只有一個程序員，一開始並沒有版本管理的概念。項目開發只有一個人在參與，所以也沒用版本管理工具。
后來，老板又招了兩個程序員，老板說：“研發管理要規范！”，經過一番調研，選用了 Git，三個人開始使用 Git 進行開發上的協作。
一開始，三個人都是通過一個倉庫，在 master 分支上進行協作。每天上班第一件事就是先把最新的代碼從服務器上拉到本地的 master 分支，下班前再把代碼給推到服務器上的 master 分支，項目就這樣展開了協作。
3人通過本地倉庫 master 分支向遠程倉庫 master 分支提交代碼
解決頻繁的代碼提交沖突
協作了幾天，團隊發現提交代碼 master 時候，經常產生代碼沖突，要么張三和李四的代碼沖突，要么李四跟趙六的代碼沖突。這時總要有人把代碼拉下來解決沖突。才能保證后續開發工作順利進行。同時，由於缺少代碼審查。部分質量較差的代碼和無關內容也時不時被提交上去。
團隊在解決沖突和代碼重構的問題上花費了不少精力。。。
為了解決單一分支頻繁更新容易發生沖突的問題，三人開始研究使用分支的方式進行協作。通過在本地 master 檢出新分支，修改后將新分支推送到遠程倉庫，再通過 拉取合並請求（Pull Request）在遠程倉庫上合並分支到 master 分支。最后再把代碼從遠程 master 拉取到本地 master 進行更新。在這個基礎上，團隊也開始展開相互的 代碼審查（Code Review）工作。
本地 master 分支檢出新分支開發推送到遠端倉庫后，通過 Pull Request 合並到 master，然后拉回本地 master。
初步解決代碼迭代版本問題
經過一番折騰，幾個人的協作總算能比較穩定地進行。在后續數周內，團隊開發工作順利展開，項目也得以落地，進入快速迭代階段。為了解決迭代的版本問題，團隊使用分支對每次版本發布檢出一個分支進行保留。
通過遠程倉庫 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：https://nvie.com/posts/a-successful-git-branching-model/ 。通過安裝后，開發成員可以在本地通過對項目的各類功能分支進行定義。
Git-flow 通過交互方式定義各類功能分支
通過一系列命令簡化各種分支模型的管理操作，小范圍功能可以通過本地合並到本地分支，或直接推送到遠程再通過 Pull Request 合並操作。
經過一番調研和討論，三人最終決定了團隊在代碼協作上使用 單倉庫多分支 的方式，采用 分支模型 進行管理。
接下來的問題就比較簡單了，在碼雲 gitee.com 上新建倉庫，選擇相應的分支模型即可。Git 的分支相比 SVN 來說是非常輕量級的，善用分支有利於更清晰的進行開發過程的管理。