參考文檔：
https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md#%E4%B8%80%E8%AF%91%E5%BA%8F
最近公司代碼從svn 遷移到gitlab；雖然成功搭建了gitlab 服務，但是成功的應用到開發上還是出現了很多問題，找了幾篇git 文章，優化提出了新的工作流方式，特此筆記，下文中大部分文字與圖片摘自上文鏈接
我們現在用的git 工作流方案
1、一個主分支master，一個測試分支release，修復bug ，是線上的bug ，就拉取個熱修復分支（線上的版本一般都是在master），release 上的分支就基於release拉取個bug 分支（git checkout -b bug_123 release）,修復好了，pull request 到要修復的分支；
2、新功能開發，一般是基於release ,拉取新的分支 （git checkout -b task_123 relaese）,開發好了在合併到release ，即使跨版本發佈也是沒有問題，只要一個新功能一個分支，可以做到快速迭代，大功能可以跨幾個版本上線
3、發佈新版本之後在master 上打一個tag 標記，用做版本區分（個人覺得用處不大，可能是公司太小~）
正常情況下我覺得一個新功能基於一個開發分支develop ,測試的測試分支在develop 上拉取一個release 測試，我覺得這纔是比較正確的，我這個是基於公司司情才做出的改變，本質上我還是覺得測試還是從develop 拉取最好；
14、常用工作流
- 迭代需求會、衝刺會後確定本次迭代的目標後，將迭代內容視爲一個項目，在 Gitlab 上創建一個 Repository，初始化工程代碼結構，根據上線日期，比如20150730上線，開出分支 release20150730、dev20150730 兩個分支，dev 分支作爲日常開發主幹分支，release 分支作爲提測打包、Code Review 的分支。
- 迭代開始，日常開發進行中，開發人員在 dev 分支上進行 Commit、Push 代碼，並且解決掉日常協同開發中的衝突等問題，等到達到提測條件的時候，提測者，首先 Merge Master 分支上的最新代碼 git merge --no-ff origin/master ，使得 Master 分支上的變更更新到迭代開發分支dev上面，之後，在 Gitlab 上面發起 pull request 請求，並指定 Code Review 人，請求的分支選擇本次上線的 release 分支，即 release20150730。
- 被指定 Code Review 的人，對發起者的代碼 Review 後，決定是否可以提交測試，若有問題，評論註釋代碼後，提交者對代碼進行進行修改，重複步驟2，直到代碼 Review 者認爲 Ok。之後便可以藉助自己公司的打包部署，對這些代碼發佈到測試環境驗證。
- 步驟2-3重複多次後，就會達到一個穩定可發佈的版本，即上線版本，上線後，將 release 版本上面最後的提交（圖中0.2.4上線對應處）合併到 Master 分支上面，並打 Tag0.3。至此，一次完整的迭代開發完成。
- 若此次上線後，不久發現生產環境有 Bug 需要修復，則從 Tag 處新開分支 release_bugfix_20150731、dev_bugfix_20150731 ，開發人員從 dev_bugfix_20150731分支上進行開發，提測code review在 release_bugfix_20150731 分支上，具體步驟參考2-3，測試環境驗證通過後，發佈到線上，驗證OK，合併到 Master 分支，並打 Tag0.2.3，此次 Bug 修復完畢，專爲解 Bug 而生的這兩個分支可以退伍了，刪除release_bugfix_20150731、dev_bugfix_20150731兩分支即可。（所有的歷史 Commit 信息均已經提交到了 Master 分支上，不用擔心丟失）
Git 的一些使用原則（供參考）
- master：master永遠是線上代碼，最穩定的分支，存放的是隨時可供在生產環境中部署的代碼，當開發活動告一段落，產生了一份新的可供部署的代碼時，發佈成功之後，代碼纔會由 aone2 提交到 master，master 分支上的代碼會被更新。應用上 aone2 後禁掉所有人的 master的寫權限
- develop：保存當前最新開發成果的分支。通常這個分支上的代碼也是可進行每日夜間發佈的代碼，只對開發負責人開放develop權限。
- feature: 功能特性分支，每個功能特性一個 feature/ 分支，開發完成自測通過後合併入 develop 分支。可以從 master 或者develop 中拉出來。
- hotfix: 緊急bug分支修復分支。修復上線後，可以直接合併入master。
Git-Develop 分支模式是基於 Git 代碼庫設計的一種需要嚴格控制發佈質量和發佈節奏的開發模式。develop 作爲固定的持續集成和發佈分支，並且分支上的代碼必須經過 CodeReview 後纔可以提交到 Develop 分支。它的基本流程如下：
- 每一個需求/變更都單獨從Master上創建一條Branch分支；
- 用戶在這個Branch分支上進行Codeing活動；
- 代碼達到發佈准入條件後aone上提交Codereview，Codereview通過後代碼自動合併到Develop分支；
- 待所有計劃發佈的變更分支代碼都合併到Develop後，系統再 rebase master 代碼到Develop 分支，然後自行構建，打包，部署等動作。
- 應用發佈成功後Aone會基於Develop分支的發佈版本打一個“當前線上版本Tag”基線；
- 應用發佈成功後Aone會自動把Develop分支的發佈版本合併回master；
15、git主流工作流--Forking工作流
這個是github 上常見的功能forcking ，我個人覺得這個更加適用於開源的項目，或者大型互聯網公司開發使用；
簡單說就是複製一個到自己的託管工具上（github或者gitlab），然後開發新功能，或者是修改了bug,搞定之後（pull request 或者merge request 到主幹上（master））；由管理者去Code Review合併
Forking工作流是分佈式工作流，充分利用了Git在分支和克隆上的優勢。可以安全可靠地管理大團隊的開發者（developer），並能接受不信任貢獻者（contributor）的提交。
Forking工作流和前面討論的幾種工作流有根本的不同，這種工作流不是使用單個服務端倉庫作爲『中央』代碼基線，而讓各個開發者都有一個服務端倉庫。這意味着各個代碼貢獻者有2個Git倉庫而不是1個：一個本地私有的，另一個服務端公開的。
Forking工作流的一個主要優勢是，貢獻的代碼可以被集成，而不需要所有人都能push代碼到僅有的中央倉庫中。 開發者push到自己的服務端倉庫，而只有項目維護者才能push到正式倉庫。 這樣項目維護者可以接受任何開發者的提交，但無需給他正式代碼庫的寫權限。
效果就是一個分佈式的工作流，能爲大型、自發性的團隊（包括了不受信的第三方）提供靈活的方式來安全的協作。 也讓這個工作流成爲開源項目的理想工作流。
15.1工作方式
和其它的Git工作流一樣，Forking工作流要先有一個公開的正式倉庫存儲在服務器上。 但一個新的開發者想要在項目上工作時，不是直接從正式倉庫克隆，而是fork正式項目在服務器上創建一個拷貝。
這個倉庫拷貝作爲他個人公開倉庫 —— 其它開發者不允許push到這個倉庫，但可以pull到修改（後面我們很快就會看這點很重要）。 在創建了自己服務端拷貝之後，和之前的工作流一樣，開發者執行git clone命令克隆倉庫到本地機器上，作爲私有的開發環境。
要提交本地修改時，push提交到自己公開倉庫中 —— 而不是正式倉庫中。 然後，給正式倉庫發起一個pull request，讓項目維護者知道有更新已經準備好可以集成了。 對於貢獻的代碼，pull request也可以很方便地作爲一個討論的地方。
爲了集成功能到正式代碼庫，維護者pull貢獻者的變更到自己的本地倉庫中，檢查變更以確保不會讓項目出錯， 合併變更到自己本地的master分支， 然後pushmaster分支到服務器的正式倉庫中。 到此，貢獻的提交成爲了項目的一部分，其它的開發者應該執行pull操作與正式倉庫同步自己本地倉庫。
我的理解是
這就就像在github 上fork 一個到本地開發，然後改完提交到自己的gitHub,你將你覺得好的修改pull request 到代碼擁有者那，人家看完你的代碼覺得好，就合併到自己的倉庫中
這個是基於倉庫的開發工作流，適用於大的開源項目
16、git主流工作流--Gitflow工作流
這個我個人覺得更加的適合大多數企業開發
相對於使用僅有的一個master分支，Gitflow工作流使用兩個分支來記錄項目的歷史。master分支存儲了正式發佈的歷史，而develop分支作爲功能的集成分支。 這樣也方便master分支上的所有提交分配一個版本號。
每個新功能位於一個自己的分支，這樣可以push到中央倉庫以備份和協作。 但功能分支不是從master分支上拉出新分支，而是使用develop分支作爲父分支。當新功能完成時，合併回develop分支。 新功能提交應該從不直接與master分支交互。
注意，從各種含義和目的上來看，功能分支加上develop分支就是功能分支工作流的用法。但Gitflow工作流沒有在這裏止步。
一旦develop分支上有了做一次發佈（或者說快到了既定的發佈日）的足夠功能，就從develop分支上checkout一個發佈分支。 新建的分支用於開始發佈循環，所以從這個時間點開始之後新的功能不能再加到這個分支上—— 這個分支只應該做Bug修復、文檔生成和其它面向發佈任務。 一旦對外發布的工作都完成了，發佈分支合併到master分支並分配一個版本號打好Tag。 另外，這些從新建發佈分支以來的做的修改要合併回develop分支。
使用一個用於發佈準備的專門分支，使得一個團隊可以在完善當前的發佈版本的同時，另一個團隊可以繼續開發下個版本的功能。 這也打造定義良好的開發階段（比如，可以很輕鬆地說，『這周我們要做準備發佈版本4.0』，並且在倉庫的目錄結構中可以實際看到）。
維護分支或說是熱修復（hotfix）分支用於給產品發佈版本（production releases）快速生成補丁，這是唯一可以直接從master分支fork出來的分支。 修復完成，修改應該馬上合併回master分支和develop分支（當前的發佈分支），master分支應該用新的版本號打好Tag。
爲Bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個發佈循環。 你可以把維護分支想成是一個直接在master分支上處理的臨時發佈。
17、git主流工作流—集中式工作流（同svn）
像Subversion一樣，集中式工作流以中央倉庫作爲項目所有修改的單點實體。相比SVN缺省的開發分支trunk，Git叫做master，所有修改提交到這個分支上。本工作流只用到master這一個分支。
首先，開發者克隆中央倉庫。在自己的項目拷貝中，像SVN一樣的編輯文件和提交修改；但修改是存在本地的，和中央倉庫是完全隔離的。開發者可以把和上游的同步延後到一個方便時間點。
然後，開發者發佈修改到正式項目中，開發者要把本地master分支的修改『推』到中央倉庫中。這相當於svn commit操作，但push操作會把所有還不在中央倉庫的本地提交都推上去。
18、git主流工作流—功能分支工作流
功能分支工作流仍然用中央倉庫，並且master分支還是代表了正式項目的歷史。 但不是直接提交本地歷史到各自的本地master分支，開發者每次在開始新功能前先創建一個新分支。 功能分支應該有個有描述性的名字，比如animated-menu-items或issue-#1061，這樣可以讓分支有個清楚且高聚焦的用途。
對於master分支和功能分支，Git是沒有技術上的區別，所以開發者可以用和集中式工作流中完全一樣的方式編輯、暫存和提交修改到功能分支上。
另外，功能分支也可以（且應該）push到中央倉庫中。這樣不修改正式代碼就可以和其它開發者分享提交的功能。 由於master是僅有的一個『特殊』分支，在中央倉庫上存多個功能分支不會有任何問題。當然，這樣做也可以很方便地備份各自的本地提交。
功能分支除了可以隔離功能的開發，也使得通過Pull Requests討論變更成爲可能。 一旦某個開發者完成一個功能，不是立即合併到master，而是push到中央倉庫的功能分支上併發起一個Pull Request請求，將修改合併到master。 在修改成爲主幹代碼前，這讓其它的開發者有機會先去Review變更。
Code Review是Pull Requests的一個重要的收益，而Pull Requests則是討論代碼的一個通用方式。 你可以把Pull Requests作爲專門給某個分支的討論。這意味着可以在更早的開發過程中就可以進行Code Review。 比如，一個開發者開發功能需要幫助時，要做的就是發起一個Pull Request，相關的人就會自動收到通知，在相關的提交旁邊能看到需要幫助解決的問題。
一旦Pull Request被接受了，發佈功能要做的就和集中式工作流就很像了。 首先，確定本地的master分支和上游的master分支是同步的。然後合併功能分支到本地master分支並push已經更新的本地master分支到中央倉庫。
倉庫管理的產品解決方案像Bitbucket或Stash，可以良好地支持Pull Requests。可以看看Stash的Pull Requests文檔。
功能分支我的理解就是一個功能一個分支，開發好了提交到gitlab ，然後發起請求合併