封面
作為一名85后的技術男，一轉眼10年過去了（一不小心暴露了年齡，雖然我叫18歲fantasy），親手寫代碼已經是5年前了，目前主要負責公司的軟體產品的規劃和設計（所以最近寫的東西也主要與設計和產品分析有關）并帶著研發團隊進行產品落地，偶爾手癢癢寫點代碼或者和團隊討論一下架構設計啥的，畢竟以前是那么的熱愛！
這篇文章主要想寫寫我所在團隊git的使用歷程，有些算是回憶吧，~老司機共勉啊~
SVN時代
在剛進公司的時候，那會大家都還在使用svn，代碼，原型設計和程序檔案都在svn上，大概過了一年，整合svn大小40個G（大概兩個千萬級專案的代碼和檔案），每次更新要人命，也給實施團隊和方案團隊帶來了很多困惑，后來就直接把研發從svn上分出來了，但還是svn管理，svn只用來做內部檔案管理，
那個時候主要面對專案開發，團隊也比較集中，都在北京，專案的特征就是一次性交付，后面有部分變更開發和bug修改，所以從分支上來說基本上就是這樣的，
單專案svn
大家都在主分支上開發，然后定時提交，到了上線節點QA把代碼checkout下來開始測驗，測驗完后把bug清單發給研發，研發一頓改，之后提交，QA再回歸測驗，基本上沒問題然后就上線了，
暴露問題：
隨著時間的發展，大家有不少時間花在解決沖突上，因為其他人提交了有bug的代碼（團隊有要求必須自測后提交但，但是自測能力參差不齊），有時候量大了能折騰一上午，基本上最后提交之前都得先本地備份一下，生怕應為沖突而代碼丟失了，
引入GIT
隨著業務的擴展和團隊的發展，北京，武漢，長春都有了研發基地，這種扯皮的事情更多了，并且由于網路的不穩定，很多時候代碼提交都出現了問題，通過內部溝通研究，決定將代碼管理從svn遷移到公網碼云（gitee）上，當時也研究了github之類的，最好考慮還是用了國內的，畢竟還有社區啥的，平時吐個槽看個科技前言新聞也方便，
上了git之后，一開始也只解決了地域問題，大家可以在各自的城市暢通無阻的提交代碼了，同時團隊也加強了代碼審核和自測培訓，但是基本上沒有分支的概念，那個時候，GIT的使用是這樣的，
gitc之初
此階段解決的問題：
分布式團隊，分布式提交，
產生的問題：由于團隊要求每天代碼必須提交到遠程，但是自測結果任然具有不確定，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去應付新的定制需求，整個開發流程變成下面的情況：
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分支
有些地方會和網上的會有差別，比如我們是在最后才引入dev分支的，
總結
1、針對專案和產品我們采用了兩套策略，專案用release策略，產品用tag策略，
2、另外如果是集中式開發的小團隊小專案，只基于mater開發也不是不可，也挺靈活，加上嚴格的代碼審核和自檢培訓就行了，
3、這里面基本也用到GIT的三種作業流的思想（Git Flow，GitHub Flow，GitLab Flow），加入了自己的一些實踐和定制，
關于pull request
對于git中的pull request協作機制，實際應用中也基本沒用上，感覺比較適合外包或者開源協作專案（多個不太熟悉的小團隊合作開發一個專案），如果是內部團隊，畢竟這種協同機制內部定死也沒必要線上處理了，
我們的代碼審核時間有時候不在上線前，基本上會周五或者周一由專人進行（一方面審核代碼及完善審核規則，一方面培訓新人），而并不是提交一個模塊就讓人審核，這樣如果功能點太多，審核人的時間就很零碎，但是上線的功能肯定是審核過了的，而且會有嚴格的代碼測驗，
零零碎碎也了很多，歡迎大家一起討論吧，有問題也歡迎留言提出，
總之，適合自己團隊和公司的就是最好的，用發展的眼光看待技術，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/212710.html
標籤：其他