使用Git進行産品代碼管理的總結
Git近些年來非常流行，很多公司已經從SVN/CVS/TFS 這樣的管理工具切換過來，但是很多人對Git使用以及與其他版本管理工具的差別仍然有疑惑。在這裡我根據實際的産品管理經驗，總結一下Git工作流的實踐，供大家參考。
背景和要求
可能很多朋友與我們一樣，進行着産品的開發和銷售，通常這就意味着我們管理着一套産品的基準代碼，同時又需要滿足各個客戶的要求，對每個銷售的版本進行單獨的二次開發和修改，這些代碼的變更修改往往是不能合并到産品代碼的主線中的。是以需要對每個銷售的版本進行管理。
之前我們的方式比較落後，簡單的把每個項目的代碼複制出來，重建立立一個新的Repository，随着項目變多，很多修改需要在不同的Repository間複制，尤其是bug的修複，如果在主産品代碼上修複了bug沒有即時在其他項目間同步，那一定是會被忘掉的，然後團隊成員在其他項目的代碼上再改一遍，極大的浪費有沒有…
針對這些問題，我們進行了改進，這種，利用了Git的分布式開發特性，分成了産品主線開發、銷售版本的開發兩部分，當然僅僅是Git不夠的，在版本管理的實施過程中，團隊還需要達成默契：定版本、勤送出、寫說明。
GIT的典型工作流模式
Git 是分布式的工作流程，使得開發者之間的協作更加靈活多樣，根據官方的總結，主要有三種模式：集中式工作流、內建管理者工作流、司令官與副官工作流。實際使用中可以選擇其中的一種或者将幾種進行搭配使用，在這裡把官方的介紹進行整理，更加具體的您可以去參考官方文檔。
集中式工作流
這意味着如果兩個開發者從中心倉庫克隆代碼下來，同時作了一些修改，那麼隻有第一個開發者可以順利地把資料推送回共享伺服器。 第二個開發者在推送修改之前，必須先将第一個人的工作合并進來，這樣才不會覆寫第一個人的修改。 這和 Subversion （或任何 CVCS）中的概念一樣。
內建管理者工作流
Git 允許多個遠端倉庫存在，使得這樣一種工作流成為可能：每個開發者擁有自己倉庫的寫權限和其他所有人倉庫的讀權限。 這種情形下通常會有個代表`‘官方’’項目的權威的倉庫。 要為這個項目做貢獻，你需要從該項目克隆出一個自己的公開倉庫，然後将自己的修改推送上去。 接着你可以請求官方倉庫的維護者拉取更新合并到主項目。 維護者可以将你的倉庫作為遠端倉庫添加進來，在本地測試你的變更，将其合并入他們的分支并推送回官方倉庫。
司令官與副官工作流
這其實是多倉庫工作流程的變種。 一般擁有數百位協作開發者的超大型項目才會用到這樣的工作方式，例如著名的 Linux 核心項目。 被稱為副官（lieutenant）的各個內建管理者分别負責內建項目中的特定部分。 所有這些副官頭上還有一位稱為司令官（dictator）的總內建管理者負責統籌。 司令官維護的倉庫作為參考倉庫，為所有協作者提供他們需要拉取的項目代碼。 整個流程看起來是這樣的(見 司令官與副官工作流。):
- 普通開發者在自己的特性分支上工作，并根據 master 分支進行變基。 這裡是司令官的
master
- 副官将普通開發者的特性分支合并到自己的 master 分支中。
- 司令官将所有副官的 master 分支并入自己的 master 分支中。
- 司令官将內建後的 master 分支推送到參考倉庫中，以便所有其他開發者以此為基礎進行變基。
主産品線版本管理
對于産品的主線的版本管理，還是基于Git的集中式管理模式，與我們以前用的SVN差不多，在分支上做了優化，我們建立了這幾個分支：develop、bugfix、feature、prelease，加上master，一共五個。
- develop: 開發團隊日常開發測試的分支
- bugfix: bug修複分支
- feature：具體功能的開發，開發一些比較獨立複雜的功能。
- prelease：釋出前的測試，給測試團隊用的
- master：釋出的版本，每個釋出版本會打Tag，标記一下。
參考這張圖：
開發
在實際操作中，涉及到開發、測試、産品三種角色。對于開發，一開始我們是在develop分支進行的，處在混沌态，很多頁面的調用參數需要即時的協調和溝通，搭好産品的基本架構。根據産品需求，一些功能逐漸的被配置設定給一個或者幾個人進行開發，這時建立一些feature分支（feature1，feature2），開發完後merge到develop分支（當然經常因為變動一些feature直接被砍掉了，你懂的），當一個階段開發完成後，我們會将develop内部測試一遍，合并到test分支給測試團隊，然後繼續進行下一階段的開發。
測試
通常測試團隊可以在1~2個工作日給我們回報結果，我們基于test建立一些bugfix分支，由此bugfix和test進入了蜜月期，直到測試團隊通過。完成後的需要保證所有的修改都合并到了develop中。
釋出
測試完成後，由test建立分支到master，并打上tag版本号釋出出來，注意這裡的釋出還是内部釋出而不是直接釋出給客戶。
銷售版的版本管理
銷售版本面向每個客戶都是不同的，這就利用了Git的內建管理者模式，從産品主線的master中fork出來，當然fork這個功能隻有gitlab/github裡面有，實際fork是由多個git指令實作的，這裡借用這個名字。
fork出來的代碼與主産品代碼有着上下遊的關系，銷售版可以拉去最新釋出的master版本，也可以送出到主産品中，但隻能建立新的feature送出進去。
銷售版的分支就沒有那麼多了，隻有feature，bugfix，prerelease，和master。測試團隊和開發團隊一樣，這裡我們取消了develop分支，讓prerelease具備了他的功能，即日常開發基于prelease。
過程是這樣的：
首次釋出
- fork master版本的代碼到prelease分支
- 從prelease釋出到master，把master釋出給客戶
二次開發/修改
- 二次修改，建立feature/bugfix 開發完成後釋出到prelease
- prelease測試完成後合并到master，釋出給客戶。
送出到産品主線中
在産品主線中建立一個feature分支，将需要送出的feature和bugfix都送出到這個分支中。
總結
這裡分享的是我們的經驗，相信很多朋友遇到跟我們類似的情況，可能每個團隊的成員組成不一樣，具體的操作流程需要進行調整，但重要的是熟悉git的過程，建立合并分支，內建和分布式的進行代碼管理。