Git 作為一個源碼管理系統，不可避免涉及到多人協作。
協作必須有一個規範的工作流程，讓大家有效地合作，使得項目井井有條地發展下去。"工作流程"在英語裡，叫做"workflow"或者"flow"，原意是水流，比喻項目像水流那樣，順暢、自然地向前流動，不會發生沖擊、對撞、甚至漩渦。
本文介紹三種廣泛使用的工作流程：
Git flow Github flow Gitlab flow
如果你對Git還不是很熟悉，可以先閱讀下面的文章。
<a href="http://www.ruanyifeng.com/blog/2015/08/git-use-process.html" target="_blank">《Git 使用規範流程》</a> <a href="http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html" target="_blank">《常用 Git 指令清單》</a> <a href="http://www.ruanyifeng.com/blog/2014/06/git_remote.html" target="_blank">《Git 遠端操作詳解》</a>
它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者更新檔分支（hotfix branch）。完成開發後，該分支就合并到主分支，然後被删除。
它最主要的特點有兩個。
首先，項目存在兩個長期分支。
主分支<code>master</code> 開發分支<code>develop</code>
前者用于存放對外釋出的版本，任何時候在這個分支拿到的，都是穩定的分布版；後者用于日常開發，存放最新的開發版。
其次，項目存在三種短期分支。
功能分支（feature branch） 更新檔分支（hotfix branch） 預發分支（release branch）
一旦完成開發，它們就會被合并進<code>develop</code>或<code>master</code>，然後被删除。
Git flow的優點是清晰可控，缺點是相對複雜，需要同時維護兩個長期分支。大多數工具都将<code>master</code>當作預設分支，可是開發是在<code>develop</code>分支進行的，這導緻經常要切換分支，非常煩人。
更大問題在于，這個模式是基于"版本釋出"的，目标是一段時間以後産出一個新版本。但是，很多網站項目是"持續釋出"，代碼一有變動，就部署一次。這時，<code>master</code>分支和<code>develop</code>分支的差别不大，沒必要維護兩個長期分支。
它隻有一個長期分支，就是<code>master</code>，是以用起來非常簡單。
第一步：根據需求，從<code>master</code>拉出新分支，不區分功能分支或更新檔分支。 第三步：Pull Request既是一個通知，讓别人注意到你的請求，又是一種對話機制，大家一起評審和讨論你的代碼。對話過程中，你還可以不斷送出代碼。 第四步：你的Pull Request被接受，合并進<code>master</code>，重新部署後，原來你拉出來的那個分支就被删除。（先部署再合并也可。）
Github flow 的最大優點就是簡單，對于"持續釋出"的産品，可以說是最合适的流程。
問題在于它的假設：<code>master</code>分支的更新與産品的釋出是一緻的。也就是說，<code>master</code>分支的最新代碼，預設就是目前的線上代碼。
可是，有些時候并非如此，代碼合并進入<code>master</code>分支，并不代表它就能立刻釋出。比如，蘋果商店的APP送出稽核以後，等一段時間才能上架。這時，如果還有新的代碼送出，<code>master</code>分支就會與剛釋出的版本不一緻。另一個例子是，有些公司有釋出視窗，隻有指定時間才能釋出，這也會導緻線上版本落後于<code>master</code>分支。
上面這種情況，隻有<code>master</code>一個主分支就不夠用了。通常，你不得不在<code>master</code>分支以外，另外建立一個<code>production</code>分支跟蹤線上版本。
Gitlab flow 的最大原則叫做"上遊優先"（upsteam first），即隻存在一個主分支<code>master</code>，它是所有其他分支的"上遊"。隻有上遊分支采納的代碼變化，才能應用到其他分支。
Linus Torvalds的分支 子系統（比如netdev）的分支 裝置廠商（比如三星）的分支
Gitlab flow 分成兩種情況，适應不同的開發流程。
對于"持續釋出"的項目，它建議在<code>master</code>分支以外，再建立不同的環境分支。比如，"開發環境"的分支是<code>master</code>，"預發環境"的分支是<code>pre-production</code>，"生産環境"的分支是<code>production</code>。
開發分支是預發分支的"上遊"，預發分支又是生産分支的"上遊"。代碼的變化，必須由"上遊"向"下遊"發展。比如，生産環境出現了bug，這時就要建立一個功能分支，先把它合并到<code>master</code>，确認沒有問題，再<code>cherry-pick</code>到<code>pre-production</code>，這一步也沒有問題，才進入<code>production</code>。
隻有緊急情況，才允許跳過上遊，直接合并到下遊分支。
對于"版本釋出"的項目，建議的做法是每一個穩定版本，都要從<code>master</code>分支拉出一個分支，比如<code>2-3-stable</code>、<code>2-4-stable</code>等等。
以後，隻有修補bug，才允許将代碼合并到這些分支，并且此時要更新小版本号。
功能分支合并進<code>master</code>分支，必須通過Pull Request（Gitlab裡面叫做 Merge Request）。
<code>master</code>分支應該受到保護，不是每個人都可以修改這個分支，以及擁有審批 Pull Request 的權力。
Issue 用于 Bug追蹤和需求管理。建議先建立 Issue，再建立對應的功能分支。功能分支總是為了解決一個或多個 Issue。
功能分支的名稱，可以與issue的名字保持一緻，并且以issue的編号起首，比如"15-require-a-password-to-change-it"。
close closes closed fix fixes fixed resolve resolves resolved
這種方式還可以一次關閉多個issue，或者關閉其他代碼庫的issue，格式是<code>username/repository#issue_number</code>。
Pull Request被接受以後，issue關閉，原始分支就應該删除。如果以後該issue重新打開，新分支可以複用原來的名字。
Git有兩種合并：一種是"直進式合并"（fast forward），不生成單獨的合并節點；另一種是"非直進式合并"（none fast-forword），會生成單獨節點。
前者不利于保持commit資訊的清晰，也不利于以後的復原，建議總是采用後者（即使用<code>--no-ff</code>參數）。隻要發生合并，就要有一個單獨的合并節點。
為了便于他人閱讀你的送出，也便于<code>cherry-pick</code>或撤銷代碼變化，在發起Pull Request之前，應該把多個commit合并成一個。（前提是，該分支隻有你一個人開發，且沒有跟<code>master</code>合并過。）
本文轉自demoblog部落格園部落格，原文連結http://www.cnblogs.com/0616--ataozhijia/p/8034486.html如需轉載請自行聯系原作者
demoblog