# git-flow 的工作流程 當在團隊開發中使用版本控制系統時，商定一個統一的工作流程是至關重要的。Git 的確可以在各個方面做很多事情，然而，如果在你的團隊中還沒有能形成一個特定有效的工作流程，那么混亂就將是不可避免的。 基本上你可以定義一個完全適合你自己項目的工作流程，或者使用一個別人定義好的。 在這章節中我們將一起學習一個當前非常流行的工作流程 git-flow。 ## 什么是 git-flow？ 一旦安裝安裝 git-flow，你將會擁有一些擴展命令。這些命令會在一個預定義的順序下自動執行多個操作。是的，這就是我們的工作流程！ git-flow 并不是要替代 Git，它僅僅是非常聰明有效地把標準的 Git 命令用腳本組合了起來。 嚴格來講，你并不需要安裝什么特別的東西就可以使用 git-flow 工作流程。你只需要了解，哪些工作流程是由哪些單獨的任務所組成的，并且附帶上正確的參數，以及在一個正確的順序下簡單執行那些對應的 Git 命令就可以了。當然，如果你使用 git-flow 腳本就會更加方便了，你就不需要把這些命令和順序都記在腦子里。 ## 安裝 git-flow 近些年來出現了很多不同的安裝方法。在本章節中我們會使用當前最流行的一種： [AVH Edition](https://github.com/petervanderdoes/gitflow/)。 要了解安裝 git-flow 細節，請閱讀下面這個文檔 [official documentation](https://github.com/petervanderdoes/gitflow/wiki#installing-git-flow)。 ## 在項目中設置 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_ 分支中。  這兩個分支被稱作為 [長期分支](https://www.git-tower.com/learn/git/ebook/cn/command-line/branching-merging/branching-workflows)。它們會存活在項目的整個生命周期中。而其他的分支，例如針對功能的分支，針對發行的分支，僅僅只是臨時存在的。它們是根據需要來創建的，當它們完成了自己的任務之后就會被刪除掉。  讓我們開始探索一些在現實應用中可能遇到的案例吧！ ## 功能開發 對于一個開發人員來說，最平常的工作可能就是功能的開發。這就是為什么 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 并不是必須的。當積攢了一定的使用經驗后，很多團隊會不再需要它了。當你能正確地理解工作流程的基本組成部分和目標的之后，你完全可以定義一個屬于你自己的工作流程。