作為一名85後的技術男，一轉眼10年過去了（一不小心暴露了年齡，雖然我叫18歲fantasy），親手寫程式碼已經是5年前了，目前主要負責公司的軟體產品的規劃和設計（所以最近寫的東西也主要與設計和產品分析有關）並帶著研發團隊進行產品落地。偶爾手癢癢寫點程式碼或者和團隊討論一下架構設計啥的，畢竟以前是那麼的熱愛！
這篇文章主要想寫寫我所在團隊git的使用歷程，有些算是回憶吧。~老司機共勉啊~
SVN時代
在剛進公司的時候，那會大家都還在使用svn。程式碼，原型設計和過程文件都在svn上。大概過了一年，整合svn大小40個G（大概兩個千萬級專案的程式碼和文件），每次更新要人命，也給實施團隊和方案團隊帶來了很多困惑，後來就直接把研發從svn上分出來了，但還是svn管理，svn只用來做內部文件管理。
那個時候主要面對專案開發，團隊也比較集中，都在北京，專案的特徵就是一次性交付，後面有部分變更開發和bug修改。所以從分支上來說基本上就是這樣的。
大家都在主分支上開發，然後定時提交，到了上線節點QA把程式碼checkout下來開始測試。測試完後把bug清單發給研發，研發一頓改，之後提交，QA再回歸測試，基本上沒問題然後就上線了。
暴露問題：
隨著時間的發展，大家有不少時間花在解決衝突上，因為其他人提交了有bug的程式碼（團隊有要求必須自測後提交但，但是自測能力參差不齊），有時候量大了能折騰一上午，基本上最後提交之前都得先本地備份一下，生怕應為衝突而程式碼丟失了。
引入GIT
隨著業務的擴充套件和團隊的發展，北京，武漢，長春都有了研發基地，這種扯皮的事情更多了，並且由於網路的不穩定，很多時候程式碼提交都出現了問題，通過內部溝通研究，決定將程式碼管理從svn遷移到公網碼雲（gitee）上，當時也研究了github之類的。最好考慮還是用了國內的，畢竟還有社群啥的，平時吐個槽看個科技前言新聞也方便。
上了git之後，一開始也只解決了地域問題，大家可以在各自的城市暢通無阻的提交程式碼了，同時團隊也加強了程式碼稽核和自測培訓。但是基本上沒有分支的概念，那個時候，GIT的使用是這樣的。
此階段解決的問題：
分散式團隊，分散式提交。
產生的問題：由於團隊要求每天程式碼必須提交到遠端。但是自測結果任然具有不確定，bug還是滿天飛，每天一來還是要處理衝突。
引入分支
通過團隊討論，程式碼每天下班遠端提交是必須的，為了防止影響別人，就引入個人分支（團隊任務基本上按人按模組分工，前後端不分離），於是就給了每個人或者開發同一個模組的幾個人建一個分支（如果同一個分支幾個人之間有小矛盾內部自己解決吧），那個時候起名一般按照“專案名_模組名”起名，比如：dxplat_logmgr（下文暫時用git的專用名稱feature代替）。每天寫完程式碼，如果還沒完成就先提交，然後確定測試完之後再合併到主分支。
解決的問題：
可按地域分散式提交。
可遠端提交到自己的分支，不影響主分支。
產生的問題：
專案上線後，一個專案實施（簡稱A）完之後，另外一個相同業務的專案（B）也中標了，但是需求還不盡相同。並且A專案在質保期，還得修修改改，添添補補。怎麼能同時滿足這兩個專案併發升級上線呢。如果按照以前的方法，就是管你A和B，我就是一個工程，然後最後都是打一個包給你（說到這很多人應該有同感），同時包含A+B。實施人員你去部署吧，上線配置小心點改，A專案改A的引數，B專案改B的引數。
隨著時間的推移，同業務域定製的專案越來越多，這樣下去不是辦法，由於上線時間不一致，主分支都不敢隨便提交了，QA正在測試A專案的時候B專案也催的著急，也得提交程式碼讓另外一個AQ測試啊。而且程式碼也慢慢失控了，改起來別提多費勁了，各種依賴包整的專案臃腫的不行不行的了。
引入release分支
團隊討論之後，決定引入release分支，一個專案上線後，通過master建立release分支用來支撐不同需求的專案，定時選擇性的將不同專案裡面的模組合併到master，開發人員都基於release做開發，並且這個release會一直保留，因為使用者永遠都有小心思。同時新的專案來了之後都從mater再建立release去應付新的定製需求。整個開發流程變成下面的情況：
至此這個策略用了至少2年，一直堅持在用。並且對待專案型的開發總體感覺用著還行，網上有人說少了dev分支，團隊內部討論整體感覺對專案型沒必要再搞個dev分支，因為專案基本上是瀑布式開發直到上線，中間迭代上先次數基本很少，要上線也是所有需求滿足直接上先。但是最後還是用上了。
接著往下發展~
終於公司部分業務產品化了，也面向公眾和企業使用者了。需求也多了，面對競爭對手也必須快準狠的面對市場了。
總結產品和專案不同的特徵如下：
1、專案具有固定週期，專案結項完畢，開發工作也基本結束了，後期修修補補。產品當然也有周期，但是不是客戶定的週期，而是企業戰略和市場決定。
2、專案基本瀑布式開發，而產品如果競爭激烈，那就必須敏捷迭代，對需求池進行排序，快速跟進。
3、產品和專案都具有可複製特性。但是專案的複製由於客戶需求的不同，需求範圍有很大的不同，也就是所說的定製化程度高，基本上是方案和設計思想的複製，其他都是大量定製開發。而產品一旦確定使用者群和需求痛點這些大方向，基本上是一個線性開發的過程。不斷開發迎合市場和企業戰略的新需求，廢棄沒必要和過時的老需求。
雲端產品和終端產品的區別：
如果雲端產品，那個所有使用者都會感知一個版本。而如果是終端產品的話，不同的終端使用者群會有不同的產品版本，根據公司策略和客戶要求去升級。
那麼對於產品化的分支策略，開發需不停的在完成需求池中需求的開發。市場則需根據市場策略上線不同的版本，比如有的功能是技術公關，作為公司與競爭對手的pk點，就不能過於超前上線，以便被抄襲。有的是使用者最關心就必須在競爭對手之前上線。
這個時候以前的分支策略問題就來了。必須有一個分支是時刻能上線的程式碼，而且能記錄不同的版本（有的版本上線後有bug，需要修改，但是使用者也不需要新功能）。
引入TAG
通過在mater上記錄tag來記錄每次上市的產品版本，如果這個版本有bug，但是使用者當前不需要新的需求，就直接在這個tag上建立臨時的分支給使用者改bug，改完之後程式碼將程式碼合併到master。這個時候我們一般不刪除這個臨時分支，因為鬼知道後面還有啥bug呢，有點類似於release分支，但是和release不同的是，這個只用來改bug，新的功能開發都必須在mater上。開發流程就變成了這樣：
這裡面的問題就是QA測試的時候master不能合併新的程式碼只能改bug。一旦合併新的功能，上線範圍就變了，就得重新測試。必須測試完打上tag之後才行。但是有時候公司內部須對全功能進行內部演示和訪談調研，就必須有一個全版本的分鐘，而mater作為釋出版本，又能隨便合併。怎麼辦呢，就是引入dev分支。
引入DEV分支
具體做法就是建立dev分支，版本上線是，合併到mater，QA從mater上pull程式碼做測試用於測試上線，有bug建分支改，改完bug，master和dev上都合併。但是這個時候dev上開發的新模組不合併到mater，大家提交還是往dev上提交，內部演示都從dev打包做演示。下次上線依然是提交到mater讓QA測試（這一塊和網上很多人說的不一樣，大家都是從dev上做測試，然後沒問題合併到mater）。這樣下來分支就變成這樣：
有些地方會和網上的會有差別，比如我們是在最後才引入dev分支的。
總結
1、針對專案和產品我們採用了兩套策略，專案用release策略，產品用tag策略。
2、另外如果是集中式開發的小團隊小專案，只基於mater開發也不是不可，也挺靈活，加上嚴格的程式碼稽核和自檢培訓就行了。
3、這裡面基本也用到GIT的三種工作流的思想（Git Flow，GitHub Flow，GitLab Flow），加入了自己的一些實踐和定製。
關於pull request
對於git中的pull request協作機制，實際應用中也基本沒用上，感覺比較適合外包或者開源協作專案（多個不太熟悉的小團隊合作開發一個專案）。如果是內部團隊，畢竟這種協同機制內部定死也沒必要線上處理了。
我們的程式碼稽核時間有時候不在上線前，基本上會週五或者週一由專人進行（一方面稽核程式碼及完善稽核規則，一方面培訓新人），而並不是提交一個模組就讓人稽核，這樣如果功能點太多，稽核人的時間就很零碎。但是上線的功能肯定是稽核過了的，而且會有嚴格的程式碼測試。
零零碎碎也了很多，歡迎大家一起討論吧，有問題也歡迎留言提出。
總之，適合自己團隊和公司的就是最好的，用發展的眼光看待技術。
