【轉】git-flow 的工做流程

git-flow 的工做流程

當在團隊開發中使用版本控制系統時，商定一個統一的工做流程是相當重要的。Git 的確能夠在各個方面作不少事情，然而，若是在你的團隊中尚未能造成一個特定有效的工做流程，那麼混亂就將是不可避免的。

基本上你能夠定義一個徹底適合你本身項目的工做流程，或者使用一個別人定義好的。

在這章節中咱們將一塊兒學習一個當前很是流行的工做流程 git-flow。

什麼是 git-flow？

一旦安裝安裝 git-flow，你將會擁有一些擴展命令。這些命令會在一個預約義的順序下自動執行多個操做。是的，這就是咱們的工做流程！

git-flow 並非要替代 Git，它僅僅是很是聰明有效地把標準的 Git 命令用腳本組合了起來。

嚴格來說，你並不須要安裝什麼特別的東西就可使用 git-flow 工做流程。你只須要了解，哪些工做流程是由哪些單獨的任務所組成的，而且附帶上正確的參數，以及在一個正確的順序下簡單執行那些對應的 Git 命令就能夠了。固然，若是你使用 git-flow 腳本就會更加方便了，你就不須要把這些命令和順序都記在腦子裏。

安裝 git-flow

近些年來出現了不少不一樣的安裝方法。在本章節中咱們會使用當前最流行的一種： AVH Edition。

要了解安裝 git-flow 細節，請閱讀下面這個文檔 official documentation。

在項目中設置 git-flow

當你想把你的項目 「切換」 到 git-flow 上後，Git 仍是能夠像往常同樣工做的。這徹底是取決於你在倉庫上使用特殊的 git-flow 命令或是普通的 Git 命令。換句話說，git-flow 它不會以任何一種戲劇性的方式來改變你的倉庫。

話雖如此，git-flow 卻存在一些限制。讓咱們開始在一個新的項目上初始化它吧，以後咱們就會有所發現：

$ git flow init
Initialized empty Git repository in /Users/tobi/acme-website/.git/
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]

當在項目的根目錄執行 「git flow init」 命令時（它是否已經包括了一個 Git 倉庫並不重要），一個交互式安裝助手將引導您完成這個初始化操做。聽起來是否是有點炫，但實際上它只是在你的分支上配置了一些命名規則。
儘管如此，這個安裝助手仍是容許你使用本身喜歡的名字。我強烈建議你使用默認的命名機制，而且一步一步地肯定下去。

分支的模式

git-flow 模式會預設兩個主分支在倉庫中：

• master 只能用來包括產品代碼。你不能直接工做在這個 master 分支上，而是在其餘指定的，獨立的特性分支中（這方面咱們會立刻談到）。不直接提交改動到 master 分支上也是不少工做流程的一個共同的規則。
• develop 是你進行任何新的開發的基礎分支。當你開始一個新的功能分支時，它將是_開發_的基礎。另外，該分支也聚集全部已經完成的功能，並等待被整合到 master 分支中。

這兩個分支被稱做爲 長期分支。它們會存活在項目的整個生命週期中。而其餘的分支，例如針對功能的分支，針對發行的分支，僅僅只是臨時存在的。它們是根據須要來建立的，當它們完成了本身的任務以後就會被刪除掉。

讓咱們開始探索一些在現實應用中可能遇到的案例吧！

功能開發

對於一個開發人員來講，最日常的工做可能就是功能的開發。這就是爲何 git-flow 定義了不少對於功能開發的工做流程，從而來幫助你有組織地完成它。

開始新功能

讓咱們開始開發一個新功能 「rss-feed」：

$ git flow feature start rss-feed
Switched to a new branch 'feature/rss-feed'

Summary of actions:
- A new branch 'feature/rss-feed' was created, based on 'develop'
- You are now on branch 'feature/rss-feed'

概念

在這些命令的輸出文本中，git-flow 會對剛剛完成的操做打印出一個頗有幫助的概述

當你須要幫助的時候，你能夠隨時請求幫助。例如：

$ git flow feature help

正如上面這個新功能同樣，git-flow 會建立一個名爲 「feature/rss-feed」 的分支（這個 「feature/」 前綴 是一個可配置的選項設置）。你已經知道了，在你作新功能開發時使用一個獨立的分支是版本控制中最重要的規則之一。
git-flow 也會直接簽出這個新的分支，這樣你就能夠直接進行工做了。

完成一個功能

通過一段時間艱苦地工做和一系列的聰明提交，咱們的新功能終於完成了：

$ git flow feature finish rss-feed
Switched to branch 'develop'
Updating 6bcf266..41748ad
Fast-forward
    feed.xml | 0
    1 file changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 feed.xml
Deleted branch feature/rss-feed (was 41748ad).

最重要的是，這個 「feature finish」 命令會把咱們的工做整合到主 「develop」 分支中去。在這裏它須要等待：

1. 一個在更普遍的 「開發」 背景下的全面測試。
2. 稍後和全部積攢在 「develop」 分支中的其它功能一塊兒進行發佈。

以後，git-flow 也會進行清理操做。它會刪除這個當下已經完成的功能分支，而且換到 「develop」 分支。

管理 releases

Release 管理是版本控制處理中的另一個很是重要的話題。讓咱們來看看如何利用 git-flow 建立和發佈 release。

建立 release

當你認爲如今在 「develop」 分支的代碼已是一個成熟的 release 版本時，這意味着：第一，它包括全部新的功能和必要的修復；第二，它已經被完全的測試過了。若是上述兩點都知足，那就是時候開始生成一個新的 release 了：

$ git flow release start 1.1.5
Switched to a new branch 'release/1.1.5'

請注意，release 分支是使用版本號命名的。這是一個明智的選擇，這個命名方案還有一個很好的附帶功能，那就是當咱們完成了release 後，git-flow 會適當地_自動_去標記那些 release 提交。

有了一個 release 分支，再完成針對 release 版本號的最後準備工做（若是項目裏的某些文件須要記錄版本號），而且進行最後的編輯。

完成 release

如今是時候按下那個危險的紅色按鈕來完成咱們的release了：

git flow release finish 1.1.5

這個命令會完成以下一系列的操做：

1. 首先，git-flow 會拉取遠程倉庫，以確保目前是最新的版本。
2. 而後，release 的內容會被合併到 「master」 和 「develop」 兩個分支中去，這樣不只產品代碼爲最新的版本，並且新的功能分支也將基於最新代碼。
3. 爲便於識別和作歷史參考，release 提交會被標記上這個 release 的名字（在咱們的例子裏是 「1.1.5」）。
4. 清理操做，版本分支會被刪除，而且回到 「develop」。

從 Git 的角度來看，release 版本如今已經完成。依據你的設置，對 「master」 的提交可能已經觸發了你所定義的部署流程，或者你能夠經過手動部署，來讓你的軟件產品進入你的用戶手中。

hotfix

不少時候，僅僅在幾個小時或幾天以後，當對 release 版本做作全面測試時，可能就會發現一些小錯誤。
在這種狀況下，git-flow 提供一個特定的 「hotfix」 工做流程（由於在這裏無論使用 「功能」 分支流程，仍是 「release」 分支流程都是不恰當的）。

建立 Hotfixes

$ git flow hotfix start missing-link

這個命令會建立一個名爲 「hotfix/missing-link」 的分支。由於這是對產品代碼進行修復，因此這個 hotfix 分支是基於 「master」 分支。
這也是和 release 分支最明顯的區別，release 分支都是基於 「develop」 分支的。由於你不該該在一個還不徹底穩定的開發分支上對產品代碼進行地修復。

就像 release 同樣，修復這個錯誤固然也會直接影響到項目的版本號！

完成 Hotfixes

在把咱們的修復提交到 hotfix 分支以後，就該去完成它了：

$ git flow hotfix finish missing-link

這個過程很是相似於發佈一個 release 版本：

• 完成的改動會被合併到 「master」 中，一樣也會合併到 「develop」 分支中，這樣就能夠確保這個錯誤不會再次出如今下一個 release 中。
• 這個 hotfix 程序將被標記起來以便於參考。
• 這個 hotfix 分支將被刪除，而後切換到 「develop」 分支上去。

仍是和產生 release 的流程同樣，如今須要編譯和部署你的產品（若是這些操做不是自動被觸發的話）。

回顧一下

最後，在結束這個章節以前，我要再次強調幾個重點。
首先，git-flow 並不會爲 Git 擴展任何新的功能，它僅僅使用了腳原本捆綁了一系列 Git 命令來完成一些特定的工做流程。
其次，定義一個固定的工做流程會使得團隊協做更加簡單容易。不管是一個 「版本控制的新手」 仍是 「Git 專家」，每個人都知道如何來正確地完成某個任務。

記住，使用 git-flow 並非必須的。當積攢了必定的使用經驗後，不少團隊會再也不須要它了。當你能正確地理解工做流程的基本組成部分和目標的以後，你徹底能夠定義一個屬於你本身的工做流程。