Git Flow, Why & How

若是你是個在廠裏搞開發的，而且曾有過以下的遭遇：
(1) 你被要求立刻發佈版本，現實倒是當前開發的某功能作了一半，如今作不完也斃不乾淨；
(2) 你開發的下一個版本的功能已經作完了，但大家車間的兩個工友在作當前版本發佈，因而你老無法提交代碼，最後憋到內傷；
(3) 車間里正happy地開發新版本，忽然廠裏來了指示，要求在已發佈版本基礎上作一個小改動。
     結果大家痛苦地切分支改代碼測試發版本，結果指示是執行了，這個改動卻忘了合併到主線上。
(4) 各類其餘……

那麼，建議你試下Git Flow；固然，若是大家車間用的是SVN啥啥的，先看看Git吧。

如下介紹的是通過我「微創新」以後的Git Flow版本，修改了原版的一些BUG，某些細節上也有些差別。我作的改動具體能夠看我前面的幾篇博客。
http://www.jiangyouxin.net/2013/02/12/git_flow_1.html
http://www.jiangyouxin.net/2013/02/13/git_flow_2.html
http://www.jiangyouxin.net/2013/02/14/git_flow_3.html

獲取代碼：

  git clone https://github.com/JiangYouxin/gitflow.git

  cd gitflow
  git checkout t/squash

安裝方法：
  (linux or cygwin) 直接: make install。
  (msysgit) 建議改用cygwin……

簡單使用說明:

  首先你要用git作版本控制（好像是廢話）。
  去項目目錄裏執行 git flow init 可初始化git flow。這件事情你和你的每個工友都要作。
  剩下的事情見分割線下面的說明吧。

=======

1. 開發新功能

(1) 準備開發

   首先要爲新開發的feature取一個名字<name>，使用命令：  

     git flow feature start <name>

   此時本地會基於develop分支（develop分支能夠認爲是開發主幹，下面會簡稱主幹），建立並切換到一個新的分支feature/<name>。
  
(2) 本地開發和提交

   專心研發指定的功能，不要作其它事情，包括（非該feature引入的）bug fix。
   有點像使用SVN時「將代碼Hold在本地不提交」的狀態。
   但git有本地代碼庫，能夠作提交、回退，甚至再開分支。
   
   經常使用git命令：

     git add <file>：添加新文件（或老文件的修改）到暫存區
     git add -u：添加全部老文件的修改到暫存區
     git commit：將暫存區內容作本地提交
     git status：查看狀態

   能夠本地編版本，單獨提測feature。
   固然，非該feature引入的BUG，要推遲到release分支打出來以後再修改。
  
(3) 多人協做

   同一個feature的開發須要多人協做時，首先把分支推到服務器上：

     git push origin feature/<name>

   其餘人從服務器上把分支取下來：

     git fetch
     git checkout feature/<name>

   獲取最新更新（相似SVN Update）：

     git pull origin feature/<name> --rebase
     （若是出現衝突，須要手工解決並提交）
 
   將本地已提交的修改推送到服務器（相似SVN Commit）：
    
     git push origin feature/<name>

(4) 完成開發

   先確認feature分支上全部修改都已經本地提交過了。
   若是有多人協做，還要確認你們都已經推到服務器，而且已經從獲取了服務器的最新更新。
   若是feature單獨提測，要等到基本無BUG後再作此操做。
 
   執行命令：

     git flow feature finish <name>

   這條命令會將feature分支上全部修改合併成一個，提交到主幹。
   若是沒有產生衝突，則會要求填寫提交日誌，這個日誌會在主幹上永久保存，要認真寫。
   若是產生衝突，本地解決並提交後，從新執行上面的finish命令。
   成功後，feature分支會被刪除，本地位於主幹。

   以後更新並推送主幹（即develop分支）：

     git pull origin develop --rebase
     git push origin develop

2. 發佈主幹版本

(1) 準備發佈

   先把準備發佈的feature都finish掉，保證本地主幹是最新的。
   而後肯定發佈版本號<version>，它會做爲版本發佈時的TAG名稱。執行命令：

     git flow release start <version>

   此時本地會基於主幹，建立並切換到一個新的分支release/<version>。

   多人協做方式詳見上面的 1 (3)，只是 feature/<name> 換成 release/<version>。

   release分支上主要是bug fix，小的需求變動等，不要作大feature。
   另外release分支上的每個提交，往後都會在主幹上永久保留，因此日誌必定要認真寫。
  
(2) 完成發佈

   當release分支測試完成後，就能夠發佈版本了。
   確認release分支上全部修改都已經本地提交過了。
   且你們都已經推到服務器，而且已經從獲取了服務器的最新更新。

   使用命令：

     git flow release finish <version>

   這條命令會在release分支當前位置打TAG，並把release分支合併到主幹。
   若是產生衝突，本地解決並提交後，從新執行上面的finish命令。
   成功後，feature分支會被刪除，本地位於主幹。

   以後更新並推送主幹（即develop分支），詳見 1（4）。

   另外完成發佈還會把本地master分支更新到指向最新版本，也要推送到服務器：
 
     git push origin master

3. 發佈緊急修復版本

   與發佈主幹版本相似，參見上面的2。兩點不一樣：
  
(1) 開始發佈時要指定基準版本號。基於<base>作緊急修復的命令以下：
  
     git flow release start <version> <base>

(2) 若是<base>不是最新發布版（即與master不重合），結束髮布時不會更新master。