在工作場合實施Git的時候，有很多種工作流程可供選擇，此時反而會讓你手足無措。本文羅列了企業團隊最常用的一些git工作流程，包括Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow。願以此文拋磚引玉。
在你開始閱讀之前，請記住：這些流程應被視作為指導方針，而非“鐵律”。我們只是想告訴你可能的做法。因此，如果有必要的話，你可以組合使用不同的流程。
（本文主要介紹Gitflow Workflow……）
img
Vincent Driessen曾經寫過一篇博文，題為“A successful Git branching model”（一個成功的Git分支模型）。Gitflow工作流程就是從這篇文章里來的。
Gitflow工作流程圍繞項目發布定義了嚴格的分支模型。盡管它比Feature Branch Workflow更復雜一些，但它也為管理更大規模的項目提供了堅實的框架。
與Feature Branch Workflow比起來，Gitflow流程並沒有增加任何新的概念或命令。其特色在於，它為不同的分支分配了非常明確的角色，並且定義了使用場景和用法。除了用於功能開發的分支，它還使用獨立的分支進行發布前的准備、記錄以及后期維護。當然，你還是能充分利用Feature Branch Workflow的好處：拉拽請求（Pull Request）、隔離的試驗以及更高效率的合作。
它是怎么工作的？
Gitflow流程仍然使用一個中央代碼倉庫，它是所有開發者的信息交流中心。跟其他的工作流程一樣，開發者在本地完成開發，然后再將分支代碼推送到中央倉庫。唯一不同的是項目中分支的結構。
用於記錄歷史的分支
Gitflow使用兩個分支來記錄項目開發的歷史，而不是使用單一的master分支。在Gitflow流程中，master只是用於保存官方的發布歷史，而develop分支才是用於集成各種功能開發的分支。使用版本號為master上的所有提交打標簽（tag）也很方便。
img
事實上，Gitflow流程就是圍繞這兩個特點鮮明的分支展開的。
用於功能開發的分支
每一個新功能的開發都應該各自使用獨立的分支。為了備份或便於團隊之間的合作，這種分支也可以被推送到中央倉庫。但是，在創建新的功能開發分支時，父分支應該選擇develop（而不是master）。當功能開發完成時，改動的代碼應該被合並（merge）到develop分支。功能開發永遠不應該直接牽扯到master。
img
注意：組合使用功能開發分支和develop分支的這種設計，其實完全就是Feature Branch Workflow的理念。然而，Gitflow流程並不止於此。且看下文分解。
用於發布的分支
img
一旦develop分支積聚了足夠多的新功能（或者預定的發布日期臨近了），你可以基於develop分支建立一個用於產品發布的分支。這個分支的創建意味着一個發布周期的開始，也意味着本次發布不會再增加新的功能——在這個分支上只能修復bug，做一些文檔工作或者跟發布相關的任務。在一切准備就緒的時候，這個分支會被合並入master，並且用版本號打上標簽。另外，發布分支上的改動還應該合並入develop分支——在發布周期內，develop分支仍然在被使用（一些開發者會把其他功能集成到develop分支）。
使用專門的一個分支來為發布做准備的好處是，在一個團隊忙於當前的發布的同時，另一個團隊可以繼續為接下來的一次發布開發新功能。這也有助於清晰表明開發的狀態，比如說，團隊在匯報狀態時可以輕松使用這樣的措辭，“這星期我們要為發布4.0版本做准備。”從代碼倉庫的結構上也能直接反映出來。常用的一些措辭還有：基於develop新建分支，合並入master；命名規則為：release-或release/
用於維護的分支
img
發布后的維護工作或者緊急問題的快速修復也需要使用一個獨立的分支。這是唯一一種可以直接基於master創建的分支。一旦問題被修復了，所做的改動應該被合並入master和develop分支（或者用於當前發布的分支）。在這之后，master上還要使用更新的版本號打好標簽。
這種為解決緊急問題專設的綠色通道，讓團隊不必打亂當前的工作流程，也不必等待下一次的產品發布周期。你可以把用於維護的分支看成是依附於master的一種特別的發布分支。
舉例說明 \
下面的例子將演示Gitflow流程如何被用來管理一次產品發布。假設你已經創建好了一個中央倉庫。
1. 創建develop分支
img
第一步是給默認的master配備一個develop分支。一種簡單的做法是：讓一個開發者在本地建立一個空的develop分支，然后把它推送到服務器。
git branch develop |
develop分支將包含項目的所有歷史，而master會是一個縮減版本。現在，其他開發者應該克隆（clone）中央倉庫，並且為develop創建一個追蹤分支。
git clone ssh://user@host/path/to/repo.git |
到現在，所有人都把包含有完整歷史的分支（develop）在本地配置好了。
2. 小馬和小明開始開發新功能
img
我們的故事從小馬和小明要分別開發新功能開始。他們倆各自建立了自己的分支。注意，他們在創建分支時，父分支不能選擇master，而要選擇develop。
git checkout -b some-feature develop |
他們倆都在自己的功能開發分支上開展工作。通常就是這種Git三部曲：edit，stage，commit：
git status |
3. 小馬把她的功能開發好了
img
在提交過幾次代碼之后，小馬覺得她的功能做完了。如果她所在的團隊使用“拉拽請求”，此刻便是一個合適的時機——她可以提出一個將她所完成的功能合並入develop分支的請求。要不然，她可以自行將她的代碼合並入本地的develop分支，然后再推送到中央倉庫，像這樣：
git pull origin develop |
第一條命令確保了本地的develop分支擁有最新的代碼——這一步必須在將功能代碼合並之前做！注意，新開發的功能代碼永遠不能直接合並入master。必要時，還需要解決在代碼合並過程中的沖突。
4. 小馬開始准備一次發布
img
盡管小明還在忙着開發他的功能，小馬卻可以開始准備這個項目的第一次正式發布了。類似於功能開發，她使用了一個新的分支來做產品發布的准備工作。在這一步，發布的版本號也最初確定下來。
git checkout -b release-0.1 develop |
這個分支專門用於發布前的准備，包括一些清理工作、全面的測試、文檔的更新以及任何其他的准備工作。它與用於功能開發的分支相似，不同之處在於它是專為產品發布服務的。
一旦小馬創建了這個分支並把它推向中央倉庫，這次產品發布包含的功能也就固定下來了。任何還處於開發狀態的功能只能等待下一個發布周期。
5. 小馬完成了發布
img
一切准備就緒之后，小馬就要把發布分支合並入master和develop分支，然后再將發布分支刪除。注意，往develop分支的合並是很重要的，因為開發人員可能在發布分支上修復了一些關鍵的問題，而這些修復對於正在開發中的新功能是有益的。再次提醒一下，如果小馬所在的團隊強調代碼評審（Code Review），此時非常適合提出這樣的請求。
git checkout master |
發布分支扮演的角色是功能開發（develop）與官方發布（master）之間的一個緩沖。無論什么時候你把一些東西合並入master，你都應該隨即打上合適的標簽。
git tag -a 0.1 -m"Initial public release" master |
Git支持鈎子（hook）的功能，也就是說，在代碼倉庫里某些特定的事件發生的時候，可以執行一些預定義的腳本。因此，一種可行的做法是：在服務器端配置一個鈎子，當你把master推送到中央倉庫或者推送標簽時，Git服務器能為產品發布進行一次自動的構建。
6. 用戶發現了一個bug
img
當一次發布完成之后，小馬便回去與小明一起開發其他功能了。突然，某個用戶提出抱怨說當前發布的產品里有一個bug。為了解決這個問題，小馬（或者小明）基於master創建了一個用於維護的分支。她在這個分支上修復了那個bug，然后把改動的代碼直接合並入master。
git checkout -b issue-#001 master |
跟用於發布的分支一樣，在維護分支上的改動也需要合並入develop分支，這一點是很重要的！因此，小馬務必不能忘了這一步。隨后，她就可以將維護分支刪除。
git checkout develop |
原文鏈接：https://www.atlassian.com/git/workflows#!workflow-gitflow
原文鏈接：http://blog.csdn.net/happydeer/article/details/17618935
版權歸作者所有，轉載請注明出處