Gitflow工做流程

在工做場合實施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 git push -u origin develop

develop分支將包含項目的全部歷史，而master會是一個縮減版本。如今，其餘開發者應該克隆（clone）中央倉庫，而且爲develop建立一個追蹤分支。

git clone ssh://user@host/path/to/repo.git git checkout -b develop origin/develop

到如今，全部人都把包含有完整歷史的分支（develop）在本地配置好了。

2. 小馬和小明開始開發新功能

img

咱們的故事從小馬和小明要分別開發新功能開始。他們倆各自創建了本身的分支。注意，他們在建立分支時，父分支不能選擇master，而要選擇develop。

git checkout -b some-feature develop

他們倆都在本身的功能開發分支上開展工做。一般就是這種Git三部曲：edit，stage，commit：

git status git add <some-file> git commit

3. 小馬把她的功能開發好了

img

在提交過幾回代碼以後，小馬以爲她的功能作完了。若是她所在的團隊使用「拉拽請求」，此刻即是一個合適的時機——她能夠提出一個將她所完成的功能合併入develop分支的請求。要否則，她能夠自行將她的代碼合併入本地的develop分支，而後再推送到中央倉庫，像這樣：

git pull origin develop git checkout develop git merge some-feature git push git branch -d some-feature

第一條命令確保了本地的develop分支擁有最新的代碼——這一步必須在將功能代碼合併以前作！注意，新開發的功能代碼永遠不能直接合併入master。必要時，還須要解決在代碼合併過程當中的衝突。

4. 小馬開始準備一次發佈

img

儘管小明還在忙着開發他的功能，小馬卻能夠開始準備這個項目的第一次正式發佈了。相似於功能開發，她使用了一個新的分支來作產品發佈的準備工做。在這一步，發佈的版本號也最初肯定下來。

git checkout -b release-0.1 develop

這個分支專門用於發佈前的準備，包括一些清理工做、全面的測試、文檔的更新以及任何其餘的準備工做。它與用於功能開發的分支類似，不一樣之處在於它是專爲產品發佈服務的。

一旦小馬建立了這個分支並把它推向中央倉庫，此次產品發佈包含的功能也就固定下來了。任何還處於開發狀態的功能只能等待下一個發佈週期。

5. 小馬完成了發佈

img

一切準備就緒以後，小馬就要把發佈分支合併入master和develop分支，而後再將發佈分支刪除。注意，往develop分支的合併是很重要的，由於開發人員可能在發佈分支上修復了一些關鍵的問題，而這些修復對於正在開發中的新功能是有益的。再次提醒一下，若是小馬所在的團隊強調代碼評審（Code Review），此時很是適合提出這樣的請求。

git checkout master git merge release-0.1 git push git checkout develop git merge release-0.1 git push git branch -d release-0.1

發佈分支扮演的角色是功能開發（develop）與官方發佈（master）之間的一個緩衝。不管何時你把一些東西合併入master，你都應該隨即打上合適的標籤。

git tag -a 0.1 -m"Initial public release" master git push --tags

Git支持鉤子（hook）的功能，也就是說，在代碼倉庫裏某些特定的事件發生的時候，能夠執行一些預約義的腳本。所以，一種可行的作法是：在服務器端配置一個鉤子，當你把master推送到中央倉庫或者推送標籤時，Git服務器能爲產品發佈進行一次自動的構建。

6. 用戶發現了一個bug

img

當一次發佈完成以後，小馬便回去與小明一塊兒開發其餘功能了。忽然，某個用戶提出抱怨說當前發佈的產品裏有一個bug。爲了解決這個問題，小馬（或者小明）基於master建立了一個用於維護的分支。她在這個分支上修復了那個bug，而後把改動的代碼直接合併入master。

git checkout -b issue-#001 master \# Fix the bug git checkout master git merge issue-#001 git push

跟用於發佈的分支同樣，在維護分支上的改動也須要合併入develop分支，這一點是很重要的！所以，小馬務必不能忘了這一步。隨後，她就能夠將維護分支刪除。

git checkout develop git merge issue-#001 git push git branch -d issue-#001

原文連接：https://www.atlassian.com/git/workflows#!workflow-gitflow

 

本文做者：happydeer
原文連接：http://blog.csdn.net/happydeer/article/details/17618935
版權歸做者全部，轉載請註明出處