前言

記得剛工作的時候根本不知道什麼是版本管理工具，有一次和別人聊天，人家問你們公司程式碼用什麼版本管理工具？我說啥是版本管理工具，我們一般用U盤拷貝，然後人家就顧左右而言他了。後來我知道了有個東西叫SVN,後來又知道了還有個東西叫Git。所以說剛畢業的同學一定要優先進入專業的大公司，就像年輕時候應該去大城市闖兩年一樣，眼界以及你遇到的牛人會大大加快你以後成功的程序。

概述

本文主要是介紹一種在具體實踐中使用Git來管理專案開發的一種成功的方式，其實主要思想來源於這篇文章 A successful Git branching model，網上大部分教程都是致敬這篇文章。

Git的基本使用方法

關於git的基本教程，強烈建議閱讀廖雪峰老師的Git教程，對初學者非常友好。

使用Git管理專案的方式

在實際開發中如何使用Git沒有一個標準答案，使用方式也是各式各樣，很多基本上都是把Git當SVN來用。下面介紹的是一種經過實踐的執行比較良好的管理方式。

主分支

實際開發中，一個倉庫（通常只放一個專案）主要存在兩條主分支：master與develop分支。這個兩個分支的生命週期是整個專案週期。就是說，自創建出來就不會刪除，會隨著專案的不斷開發不斷的往裡面新增程式碼。master分支是建立git倉庫時自動生成的，隨即我們就會從master分支建立develop分支，如下圖所示。

• master：這個分支最為穩定，這個分支代表專案處於可釋出的狀態。

  例如王二狗向master分支合併了程式碼，那就意味著王二狗完成了此專案的一個待發布的版本，專案經理可以認為，此專案已經準備好釋出新版本了。所以master分支不是隨隨便便就可以簽入程式碼的地方，只有計劃釋出的版本功能在develop分支上全部完成，而且測試沒有問題了才會合併到master上。

• develop：作為開發的分支，平行於master分支。

  例如王二狗要開發一個註冊功能，那麼他就會從develop分支上建立一個feature分支 fb-register（後面講），在fb-register分支上將註冊功能完成後，將程式碼合併到develop

  分支上。這個fb-register就完成了它的使命，可以刪除了。專案經理看王二狗效率很高啊，於是：“二狗你順帶把登入功能也做了吧”。二狗心中暗暗罵道：日了個狗的，但是任務還的正常做，二狗就會重複上面的步驟：從develop分支上新建立一個名為fb-login的分支，喝杯咖啡繼續開發，1個小時後登入功能寫好了，二狗又會將這個分支的程式碼合併回develop分支後將其刪除。

通過以上分析可以發現，我們可以使用Git hook 指令碼自動釋出釋出新的版本，具體就是每當有程式碼從develop分支合併到master分支的時候，指令碼就會自動觸發，編譯釋出新的版本。

支援分支

這些分支都是為了程式設計師協同開發，以及應對專案的各種需求而存在的。這些分支都是為了解決某一個具體的問題而設立，當這個問題解決後，程式碼會合並回主分支develop或者master後刪除，一般我們會人為分出三種分支。

• Feature branches：這種分支和我們程式設計師日常開發最為密切，稱作功能分支。

  必須從develop分支建立，完成後合併回develop分支

  如下圖所示。
  
  具體事例可以參考上面王二狗完成登入註冊功能時的做法。

• Release branches：這個分支用來分佈新版本。

  從develop分支建立，完成後合併回develop與master分支。

  這個分支上可以做一些非常小的bug修復，當然，你也可以禁止在這個分支做任何bug的修復工作，而只做版本釋出的相關操作，例如設定版本號等操作，那樣的話那些發現的小bug就必須放到下一個版本修復了。如果在這個分支上發現了大bug，那麼也絕對不能在這個分支上改，需要Featrue分支上改，走正常的流程。

  例項：王二狗開發完了登入註冊功能後決定發一個版本V0.1，那麼他先從develop分支上建立一個Release 分支release-v0.1，然後二狗在這個分支上把版本號等做了修改。正準備編譯釋出了，專案經理說：“二狗啊，你那個登入框好像向右偏移量1個畫素，你可以調一下嗎？”二狗心中有暗暗罵道：日了個狗，但是。。。你們懂得，功能還的正常改。不過二狗發現這個bug特別小，對專案其他部分不造成不可預知的問題，所以直接在release分支上改了，然後愉快的釋出了版本1.0.版本上線後，二狗將這個分支分別合併回了develop與master分支，然後刪除了這個分支。

• Hotfix branches：這個分支主要為修復線上特別緊急的bug準備的。

  必須從master分支建立，完成後合併回develop與master分支。

  如下圖所示：
  
  這個分支主要是解決線上版本的緊急bug修復的，例如突然版本V0.1上有一個致命bug，必須修復。那麼我們就可以從master 分支上釋出這個版本那個時間點 例如 tag v0.1（一般程式碼釋出後會及時在master上打tag），來建立一個 hotfix-v0.1.1的分支，然後在這個分支上改bug，然後釋出新的版本。最後將程式碼合併回develop與master分支。

  例項：某天夜裡二狗正在和女朋友嘿咻呢，突然專案經理打來電話：“二狗啊，線上出了個大問題，大量使用者無法登入，客服電話已經被打爆了，你緊急處理一下”。二狗心中默默罵道：日了個狗，然後就爬起來去改程式碼了。二狗先找到master分支上tag v0.1 的地方，然後新建了hotfix-v0.1.1 分支，默默的修bug去了。經過一個多小時的奮戰，終於修復了，然後二狗改了版本號，釋出了新版本。二狗將這個分支分別合併回了develop與master分支後刪除了這個分支。終於搞定了，回頭看看床上的女票已經進入了夢鄉，二狗賊心不死，上前挑逗，此刻女票將滿腹怨氣集於一點，使出凌空一腳將其登於床下，隨後甩一枕於二狗，二狗會意，趨客廳，抱枕臥於沙發。。。

總結圖

上面的講解最後匯成一張圖

總結

希望廣大程式設計師不要有王二狗的遭遇，最後希望廣大“王二狗媳婦”可以理解廣大“”王二狗”的苦衷。