前言: 關於git的使用, 之前就已經寫過一篇博客了: http://www.cnblogs.com/0zcl/p/6874588.html. 看完這篇博客, 你就基本可以使用git了. 這種使用, 僅限了一兩人的開發. 如果團隊有多人, 而且位置較分散. 那這開發就更需要規范了. 因此, 這篇博客來說一下GIT工作流.
本來以為我用git命令行可以解決GIT工作流上的問題，但其實只用命令行還是蠻困難的。下面先看看GIT的規范, 這部分比較無聊, 下面會圖文並茂的, 好吧. 如果你瞄了一眼, 覺得這SB博客, 寫得太low了, 然后就關掉這篇博客, 我感覺還是錯過一些東東.
一、提交規則
[feature] 新增功能、更新的提交，例如“[feature] add a new data layer for reading jpeg images”
[bugfix] bug修正的提交，有bugid的補充bugid，例如“[bugfix] now data layer reads single-channel images correctly”
[optimize] 優化的提交：性能等方面，feature分之下的單次優化要指明，優化分支下的用[feature]即可
[refactor] 代碼等重構的提交，feature分之下的單次重構要指明，重構分支下的用[feature]即可
- 每次提交應該只能有一個修改，不能將多個邏輯修改放在一個提交中;不可將一個邏輯修改分成多個提交
- 例如: 同時修復一個bug，同時做了重構或優化，就要把提交分成兩個(bugfix、refactor/optimize)。
- 每次merged到develop分支的代碼必須為可運行的，並且保證多平台可用
- 多人協作過程中如果在開發同一個feature，不可以在同一個feature分支進行開發，需要各自拉出新feature分支獨立開發，完成后merge到共同的feature分支
- 每日至少一次Git提交，防止代碼丟失
- feature分支在完成后合並到develop
二、版本號的定義
A.B.C。例如1.1.0。按照功能來定：
- 如果是大的版本更新，則A+1，並且B和C都設置為0；
- 如果是小的版本更新，則B+1，並且A不變，C設置為0；
- 如果是修復bug的版本更新，則C+1，並且A和B都不變。
三、Git工作流
添加一個工程文件以后，點擊：（倉庫）——（git flow）——（初始化倉庫）
- 這個的目的是為了方便git各種分支的自動生成，同時也是為了后續工作流的方便使用。
develop
當前版本最新開發進展，未測試或者測試中，對於單人開發小模塊可以直接提交，多人協作及大模塊必須通過合並具體功能子分支，接受來自feature，release，hotfix的合並。
- 創建分支必須通過（git flow）——（建立新的功能）從develop來進行
feature分支
這個分支主要是為了各種研發方案執行使用。（必須推送遠端，完成feature后合並到develop，以及測試下是否可以執行）
- 分支命名以版本號+開發者+模塊的形式來，例如：feature/1.0.0_aidy_newfeature。
- 當分支特性開發完成后合並到develop，主要是通過（git flow）——（完成功能）來進行合並，或者手動合並。
- 當出現合並沖突時，記得與沖突者當面一起溝通與合並，並確認效果ok。
release分支
這個分支主要是給研發方案差不多確定時使用，主要是為了fixbug等。（完成feature后，必須推送遠端，以及測試下是否可以執行）
- 這個分支只來自develop，當研發差不多了以后，就開始做release分支。
- 命名為版本號，例如1.0.0。主要是通過（git flow）——（建立新的發布版本）來進行。
- 當realease分支差不多了，就通過（git flow）——（完成發布版本）來進行。並會打一個版本號的標簽。
- 完成后並入develop和master。
hotfix分支
主要用於最新發布版本的bug修復。
當前版本
- 就通過（git flow）——（建立新的修復補丁）來進行。
- 當完成以后，通過（git flow）——（完成新的修復補丁）來進行合並。
- 當出現合並沖突時，記得與沖突的修改者當面一起溝通與合並，並確認效果ok。
以上來自GIT規范，然而看完GIT規范感覺還是沒有頓悟的感覺。so，必須得會使用smartgit呀。
四、使用SmartGit
看完GIT規范，你已經知道，feature分支是平時開發功能用的，完成feature分支開發后，合並到develop分支，合並成功后，刪除該feature分支。這用smartgit可以輕松實現，用命令行的話是比較麻煩，但也可以實現呀。現在的問題是，用smartgit如何輕松實現創建feature分支，刪除feature分支？
點擊Git-Flow，再點擊configure，可出現如下圖：如果你找不到下圖這個界面，那必然是你操作的姿勢有問題。
看到沒有，神奇呀，在上圖中，你只需點擊OK，GIT就會自動幫你創建feature, release, hot-fix, develop分支。這超牛逼的。這步操作很重要。完成這步操作后，會出現develop分支，此時需要把develop分支推到遠程。
正常情況下，你遠程倉庫應該有兩個分支了，分別是master和develop分支。如果沒有，把它們推到遠程。
啥，不知道怎么push？有兩種方式，在上圖的左下角的Branches窗口下，你可以點擊master分支，然后鼠標右擊，再點擊push to ；也可以在左下角的Branches窗口下，雙擊要push的分支A，此時分切換到A分支，然后再點擊上圖左上方的Push推到遠程。
五、feature分支的使用
OK，此時遠程倉庫應該有兩個分支master/develop，然而這還遠遠不夠呀，你看到同事的項目有一個feature分支。so，你肯定也是需要feature分支的。
點擊Git-Flow，會出現下圖。如果沒出現Start Feature; Start Release這些，必然是你最開始的configure有問題。
點擊Start Feature來創建一個feature分支，分支命令要參考命名規范。
現在你已經有一個feature分支了。在該分支提交些東西，commit后，提交到遠程。你會驚喜的發現遠程的倉庫出現feature分支。
現在你可以不斷地開發，提交代碼到feature分支上，但feature分支只負責一個功能的開發而已，當這個功能開發完成后，必然需要把該feature分支刪除。
簡單粗暴地說，就是當feature/0.0.2_zzy_example分支負責的功能開發完畢時，需要把feature分支合並到develop分支，合並完成后，feature分支刪除，此時遠程倉庫就看不到feature/0.0.2_zzy_example分支。
其實smartgit已經幫我們簡化了工作。牛逼呀。
當你創建feature分支時，會自動切換到feature分支。完成功能開發后，想把feature分支合並到develop分支，如何做呢？
只需點擊Git-Flow，就會出現下圖。注意，此時你應該是處於feature分支的：
看到上圖的Delete feature branch沒，當你合並完成后，就會把feature分支刪除。
接下來你需要把develop分支推到遠程。你會發現遠程的feature分支不見了。
以上，是feature分支開發的流程。
六、發布版本
今天，團長想考下git方面的操作。給我一個需求：
先來看看GIT規范對於release分支是如何介紹的:
release分支
這個分支主要是給研發方案差不多確定時使用，主要是為了fixbug等。（完成feature后，必須推送遠端，以及測試下是否可以執行）
- 這個分支只來自develop，當研發差不多了以后，就開始做release分支。
- 命名為版本號，例如1.0.0。主要是通過（git flow）——（建立新的發布版本）來進行。
- 當realease分支差不多了，就通過（git flow）——（完成發布版本）來進行。並會打一個版本號的標簽。
- 完成后並入develop和master。
第一步：
先創建一個release分支：點擊Git-Flow，再點擊start release:
輸入release分支名，分支名參考GIT規范。
第二步：可以在release分支commit, push到遠程。此時你的遠程除master, develop外，應該得有一個release分支
第三步：發布版本
點擊finish，就會發布版本啦，這里需要給版本打一個tag，tag默認會自動顯示為你的版本號。同時會把release合並到master與develop分支。再同時發布之后，會刪除該release分支。
此時遠程如下顯示：沒有release分支。多了一個Tags版本：
至此，團長交待的任務完成！
七、附本人測試用了GIT分支圖：
八、總結：
- 由於最開始就沒用好smartgit，比如下面這張圖的操作。之前就沒用到，導致后面的操作不順。
- 不要用命令行，不要用命令行，不要用命令行。命令行操作add, commit, push還可以，但對於分支操作，版本發布，用smartgit,用smartgit,用smartgit。
- 我想git這塊我頓悟了。佛系佛系，喝懷奶荼冷靜一下。
