汗顏，之前的大項目團隊合作都是用svn，之后在搞休閑游戲的時候雖然也用到了git，但都是單兵項目組，所以就非常矬的把git當svn用了。。。。。。
現(xiàn)在鑒于項目原因，不能再這么稀里糊涂下去了，git要認認真真的用起來，從gitflow走起。

先回憶一下集中式工作流

這里就不再贅述svn和git的對比評測了，如果git不完勝svn的話，我就不寫這篇文章了，你說呢。

下面請出今天的主角Gitflow

不如我們把她旋轉一下

這樣是不是更好理解了？

• 相對使用僅有的一個master分支，Gitflow工作流使用2個分支來記錄項目的歷史。master分支存儲了正式發(fā)布的歷史，而develop分支作為功能的集成分支。
  這樣也方便master分支上的所有提交分配一個版本號。
• 每個新功能位于一個自己的分支，這樣可以push到中央倉庫以備份和協(xié)作。
  但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。當新功能完成時，合并回develop分支。
  新功能提交應該從不直接與master分支交互。
• 一旦develop分支上有了做一次發(fā)布（或者說快到了既定的發(fā)布日）的足夠功能，就從develop分支上fork一個發(fā)布分支。
  新建的分支用于開始發(fā)布循環(huán)，所以從這個時間點開始之后新的功能不能再加到這個分支上——
  這個分支只應該做Bug修復、文檔生成和其它面向發(fā)布任務。
  一旦對外發(fā)布的工作都完成了，發(fā)布分支合并到master分支并分配一個版本號打好Tag。
  另外，這些從新建發(fā)布分支以來的做的修改要合并回develop分支。
  使用一個用于發(fā)布準備的專門分支，使得一個團隊可以在完善當前的發(fā)布版本的同時，另一個團隊可以繼續(xù)開發(fā)下個版本的功能。 這也打造定義良好的開發(fā)階段（比如，可以很輕松地說，『這周我們要做準備發(fā)布版本4.0』，并且在倉庫的目錄結構中可以實際看到）。
• 維護分支或說是熱修復（hotfix）分支用于生成快速給產(chǎn)品發(fā)布版本（production releases）打補丁，這是唯一可以直接從master分支fork出來的分支。
  修復完成，修改應該馬上合并回master分支和develop分支（當前的發(fā)布分支），master分支應該用新的版本號打好Tag。
  為Bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個發(fā)布循環(huán)。
  你可以把維護分支想成是一個直接在master分支上處理的臨時發(fā)布。

估計現(xiàn)在大家已經(jīng)大概明白了Gitflow的方法，那么下面給大家再看一張圖，猜猜這是什么工作流？

？？？？？？？？？？？？？？？？？？？？？

上圖叫Forking工作流

在github上貢獻過代碼的同學肯定都會知道。
Forking工作流的一個主要優(yōu)勢是，貢獻的代碼可以被集成，而不需要所有人都能push代碼到僅有的中央倉庫中。
開發(fā)者push到自己的服務端倉庫，而只有項目維護者才能push到正式倉庫。
這樣項目維護者可以接受任何開發(fā)者的提交，但無需給他正式代碼庫的寫權限。

效果就是一個分布式的工作流，能為大型、自發(fā)性的團隊（包括了不受信的第三方）提供靈活的方式來安全的協(xié)作。 也讓這個工作流成為開源項目的理想工作流。

提個問題

我們都知道svn里的add命令，那git為何每次commit之前都需要add一次，這背后究竟做了哪些處理？
|
|
|
|
|
|
|
好了，看圖說話，add背后的秘密竟然是這個。。。

光是暫存區(qū)這個概念就可以甩svn十幾條街了，暫存區(qū)帶來的好處大家在日后使用中慢慢感受吧。

推薦閱讀：
Git教程-廖雪峰
深入理解學習Git工作流（git-workflow-tutorial）