一、為什麼需要版本控制

1.概述

在軟體開發過程，每天都會產生新的程式碼，程式碼合併的過程中可能會出現如下問題：

• 程式碼被覆蓋或丟失
• 程式碼寫的不理想希望還原之前的版本
• 希望知道與之前版本的差別
• 是誰修改了程式碼以及為什麼修改
• 發版時希望分成不同的版本(測試版、發行版等)

因此，我們希望有一種機制，能夠幫助我們：

• 可以隨時回滾到之前的版本
• 協同開發時不會覆蓋別人的程式碼
• 留下修改記錄，以便隨時檢視
• 發版時可以方便的管理不同的版本

2.什麼是版本控制系統

一個標準的版本控制系統 Version Control System (VCS)，通常需要有以下功能：

• 能夠建立 Repository (倉庫)，用來儲存程式碼
• 協同開發時方便將程式碼分發給團隊成員
• 記錄每次修改程式碼的內容、時間、原因等資訊
• 能夠建立 Branch (分支)，可以根據不同的場景進行開發
• 能夠建立 Tag (標籤)，建立專案里程碑

3.版本控制系統的發展史

版本控制系統發展至今有幾種不同的模式：

1）Local VCS

本地使用 複製/貼上 的方式進行管理，缺點是無法協同開發

2）Centralized VCS (Lock，悲觀鎖)

中央集中式版本控制系統團隊共用倉庫，當某人需要編輯檔案時，進行鎖定，以免其他人同時編輯時造成衝突。缺點是雖然避免了衝突，但不是很方便。其他人需要排隊才能編輯檔案，如果有人編輯了很久或是忘記解鎖就會造成其他人長時間等待的情況。

3）Centralized VCS (Merge，樂觀鎖)

中央集中式版本控制系統團隊共用倉庫，不採用悲觀鎖方式來避免衝突，而是事後發現如果別人也修改相同檔案(衝突)，再進行手動修改解決。有很多 VCS 屬於這種型別，如：CVS，Subversion，Perforce 等

中央集中式版本控制系統的共同問題是，做任何操作都需要和伺服器同步，如果伺服器宕機則會造成無法繼續工作的窘迫。

4）Distributed VCS

分散式版本控制系統，本地也擁有完整的程式碼倉庫，就不會出現上述集中式管理的問題，即使沒有網路，依然可以 commit 和看 log，也無需擔心伺服器同步問題。如：Git，Mercurial，Bazaar 等就屬於分散式版本控制系統。缺點是功能比較複雜，上手需要一定的學習時間。

二、Git 工作流簡介

1.概述

工作流有各式各樣的用法，但也正因此使得在實際工作中如何上手使用增加了難度。這篇指南通過總覽公司團隊中最常用的幾種 Git 工作流讓大家可以上手使用。

在閱讀的過程中請記住，本文中的幾種工作流是作為方案指導而不是條例規定。在展示了各種工作流可能的用法後，你可以從不同的工作流中挑選或揉合出一個滿足你自己需求的工作流。

2.集中式工作流

如果你的開發團隊成員已經很熟悉 Subversion，集中式工作流讓你無需去適應一個全新流程就可以體驗 Git 帶來的收益。這個工作流也可以作為向更 Git 風格工作流遷移的友好過渡。

3.功能分支工作流

功能分支工作流以集中式工作流為基礎，不同的是為各個新功能分配一個專門的分支來開發。這樣可以在把新功能整合到正式專案前，用 Pull Requests 的方式討論變更。

4.GitFlow 工作流

GitFlow 工作流通過為功能開發、釋出準備和維護分配獨立的分支，讓釋出迭代過程更流暢。嚴格的分支模型也為大型專案提供了一些非常必要的結構。

5.Forking 工作流

Forking 工作流是分散式工作流，充分利用了 Git 在分支和克隆上的優勢。可以安全可靠地管理大團隊的開發者（developer），並能接受不信任貢獻者（contributor）的提交。

6.Pull Requests

Pull requests 讓開發者更方便地進行協作的功能，提供了友好的 Web 介面可以在提議的修改合併到正式專案之前對修改進行討論。

三、集中式工作流

1.概述

轉到分散式版本控制系統看起來像個令人生畏的任務，但不改變已用的工作流你也可以用上 Git 帶來的收益。團隊可以用和 Subversion 完全不變的方式來開發專案。

但使用 Git 加強開發的工作流，Git 比 SVN 有幾個優勢。首先，每個開發可以有屬於自己的整個工程的本地拷貝。隔離的環境讓各個開發者的工作和專案的其他部分（修改）獨立開來 —— 即自由地提交到自己的本地倉庫，先完全忽略上游的開發，直到方便的時候再把修改反饋上去。

其次，Git 提供了強壯的分支和合並模型。不像 SVN，Git 的分支設計成可以做為一種用來在倉庫之間整合程式碼和分享修改的『失敗安全』的機制。

2.工作方式

像 Subversion 一樣，集中式工作流以中央倉庫作為專案所有修改的單點實體。相比 SVN 預設的開發分支 trunk，Git 叫做 master，所有修改提交到這個分支上。該工作流只用到 master 這一個分支。

開發者開始先克隆中央倉庫。在自己的專案拷貝中，像 SVN 一樣的編輯檔案和提交修改；但修改是存在本地的，和中央倉庫是完全隔離的。開發者可以把和上游的同步延後到一個方便時間點。

要釋出修改到正式專案中，開發者要把本地 master 分支的修改『推（push）』到中央倉庫中。這相當於 svn commit 操作，但 push 操作會把所有還不在中央倉庫的本地提交都推上去。

3.解決衝突

中央倉庫代表了正式專案，所以提交歷史應該被尊重且是穩定不變的。如果開發者本地的提交歷史和中央倉庫有分歧，Git 會拒絕 push 提交否則會覆蓋已經在中央庫的正式提交。

在開發者提交自己功能修改到中央庫前，需要先 fetch 在中央庫的新增提交，rebase 自己提交到中央庫提交歷史之上。這樣做的意思是在說，『我要把自己的修改加到別人已經完成的修改上。』最終的結果是一個完美的線性歷史，就像以前的SVN 的工作流中一樣。

如果本地修改和上游提交有衝突，Git 會暫停 rebase 過程，給你手動解決衝突的機會。Git 解決合併衝突，用和生成提交一樣的 git status 和 git add 命令，很一致方便。還有一點，如果解決衝突時遇到麻煩，Git 可以很簡單中止整個 rebase 操作，重來一次（或者讓別人來幫助解決）。

4.示例

讓我們一起逐步分解來看看一個常見的小團隊如何用這個工作流來協作的。有兩個開發者小明和小紅，看他們是如何開發自己的功能並提交到中央倉庫上的。

1）有人先初始化好中央倉庫

第一步，有人在伺服器上建立好中央倉庫。如果是新專案，你可以初始化一個空倉庫；否則你要匯入已有的 Git 或 SVN 倉庫。

中央倉庫應該是個裸倉庫（bare repository），即沒有工作目錄（working directory）的倉庫。

2）所有人克隆中央倉庫

下一步，各個開發者建立整個專案的本地拷貝。通過 git clone 命令完成：

git clone https://github.com/path/to/repo.git

基於你後續會持續和克隆的倉庫做互動的假設，克隆倉庫時 Git 會自動新增遠端別名 origin 指回『父』倉庫。

3）小明開發功能

在小明的本地倉庫中，他使用標準的 Git 過程開發功能：編輯、暫存（Stage）和提交。如果你不熟悉暫存區（Staging Area），這裡說明一下：暫存區的用來準備一個提交，但可以不用把工作目錄中所有的修改內容都包含進來。這樣你可以建立一個高度聚焦的提交，儘管你本地修改很多內容。

git status # 檢視本地倉庫的修改狀態
git add # 暫存檔案
git commit # 提交檔案

請記住，因為這些命令生成的是本地提交，小明可以按自己需求反覆操作多次，而不用擔心中央倉庫上有了什麼操作。對需要多個更簡單更原子分塊的大功能，這個做法是很有用的。

4）小紅開發功能

與此同時，小紅在自己的本地倉庫中用相同的編輯、暫存和提交過程開發功能。和小明一樣，她也不關心中央倉庫有沒有新提交；當然更不關心小明在他的本地倉庫中的操作，因為所有本地倉庫都是私有的。

5）小明發布功能

一旦小明完成了他的功能開發，會發布他的本地提交到中央倉庫中，這樣其它團隊成員可以看到他的修改。他可以用下面的 git push 命令：

git push origin master

注意，origin 是在小明克隆倉庫時 Git 建立的遠端中央倉庫別名。master 引數告訴 Git 推送的分支。由於中央倉庫自從小明克隆以來還沒有被更新過，所以 push 操作不會有衝突，成功完成。

6）小紅試著釋出功能

一起來看看在小明發布修改後，小紅 push 修改會怎麼樣？她使用完全一樣的 push 命令：

git push origin master

但她的本地歷史已經和中央倉庫有分岐了，Git 拒絕操作並給出下面很長的出錯訊息：

error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

這避免了小紅覆寫正式的提交。她要先 pull 小明的更新到她的本地倉庫合併上她的本地修改後，再重試。

7）小紅在小明的提交之上 rebase

小紅用 git pull 合併上游的修改到自己的倉庫中。這條命令類似 svn update ——拉取所有上游提交命令到小紅的本地倉庫，並嘗試和她的本地修改合併：

git pull --rebase origin master

--rebase 選項告訴 Git 把小紅的提交移到同步了中央倉庫修改後的 master 分支的頂部，如下圖所示：

如果你忘加了這個選項，pull 操作仍然可以完成，但每次 pull 操作要同步中央倉庫中別人修改時，提交歷史會以一個多餘的『合併提交』結尾。對於集中式工作流，最好是使用 rebase 而不是生成一個合併提交。

8）小紅解決合併衝突

rebase 操作過程是把本地提交一次一個地遷移到更新了的中央倉庫 master 分支之上。這意味著可能要解決在遷移某個提交時出現的合併衝突，而不是解決包含了所有提交的大型合併時所出現的衝突。這樣的方式讓你儘可能保持每個提交的聚焦和專案歷史的整潔。反過來，簡化了哪裡引入 Bug 的分析，如果有必要，回滾修改也可以做到對專案影響最小。

如果小紅和小明的功能是相關的，不大可能在 rebase 過程中有衝突。如果有，Git 在合併有衝突的提交處暫停 rebase 過程，輸出下面的資訊並帶上相關的指令：

CONFLICT (content): Merge conflict in

Git 很讚的一點是，任何人可以解決他自己的衝突。在這個例子中，小紅可以簡單的執行 git status 命令來檢視哪裡有問題。衝突檔案列在 Unmerged paths（未合併路徑）一節中：

# Unmerged paths:
# (use "git reset HEAD <some-file>..." to unstage)
# (use "git add/rm <some-file>..." as appropriate to mark resolution)
#
# both modified: <some-file>

接著小紅編輯這些檔案。修改完成後，用老套路暫存這些檔案，並讓 git rebase 完成剩下的事：

git add
git rebase --continue

要做的就這些了。Git 會繼續一個一個地合併後面的提交，如其它的提交有衝突就重複這個過程。

如果你碰到了衝突，但發現搞不定，不要驚慌。只要執行下面這條命令，就可以回到你執行 git pull --rebase 命令前的樣子：

git rebase --abort

9）小紅成功釋出功能

小紅完成和中央倉庫的同步後，就能成功釋出她的修改了：

git push origin master

5.總結

如你所見，僅使用幾個 Git 命令我們就可以模擬出傳統 Subversion 開發環境。對於要從 SVN 遷移過來的團隊來說這太好了，但沒有發揮出 Git 分散式本質的優勢。

如果你的團隊適應了集中式工作流，但想要更流暢的協作效果，絕對值得探索一下功能分支工作流的收益。通過為一個功能分配一個專門的分支，能夠做到一個新增功能整合到正式專案之前對新功能進行深入討論。

四、功能分支工作流

1.概述

一旦你玩轉了集中式工作流，在開發過程中可以很簡單地加上功能分支，用來鼓勵開發者之間協作和簡化交流。

功能分支工作流背後的核心思路是所有的功能開發應該在一個專門的分支，而不是在 master 分支上。這個隔離可以方便多個開發者在各自的功能上開發而不會弄亂主幹程式碼。另外，也保證了 master 分支的程式碼一定不會是有問題的，極大有利於整合環境。

功能開發隔離也讓 pull requests 工作流成功可能，pull requests 工作流能為每個分支發起一個討論，在分支合入正式專案之前，給其它開發者有表示贊同的機會。另外，如果你在功能開發中有問題卡住了，可以開一個 pull requests 來向同學們徵求建議。這些做法的重點就是，pull requests 讓團隊成員之間互相評論工作變成非常方便！

2.工作方式

功能分支工作流仍然用中央倉庫，並且 master 分支還是代表了正式專案的歷史。但不是直接提交本地歷史到各自的本地 master 分支，開發者每次在開始新功能前先建立一個新分支。功能分支應該有個有描述性的名字，比如 animated-menu-items 或 issue-#1061，這樣可以讓分支有個清楚且高聚焦的用途。

在 master 分支和功能分支之間，Git 是沒有技術上的區別，所以開發者可以用和集中式工作流中完全一樣的方式編輯、暫存和提交修改到功能分支上。

另外，功能分支也可以（且應該）push 到中央倉庫中。這樣不修改正式程式碼就可以和其它開發者分享提交的功能。由於 master 僅有的一個『特殊』分支，在中央倉庫上存多個功能分支不會有任何問題。當然，這樣做也可以很方便地備份各自的本地提交。

3.Pull Requests

功能分支除了可以隔離功能的開發，也使得通過 Pull Requests 討論變更成為可能。一旦某個開發完成一個功能，不是立即合併到 master，而是 push 到中央倉庫的功能分支上併發起一個 Pull Request 請求去合併修改到 master。在修改成為主幹程式碼前，這讓其它的開發者有機會先去 Review 變更。

Code Review 是 Pull Requests 的一個重要的收益，但 Pull Requests 目的是討論程式碼一個通用方式。你可以把 Pull Requests 作為專門給某個分支的討論。這意味著可以在更早的開發過程中就可以進行 Code Review。比如，一個開發者開發功能需要幫助時，要做的就是發起一個 Pull Request，相關的人就會自動收到通知，在相關的提交旁邊能看到需要幫助解決的問題。

一旦 Pull Request 被接受了，釋出功能要做的就和集中式工作流就很像了。首先，確定本地的 master 分支和上游的 master 分支是同步的。然後合併功能分支到本地 master 分支並 push 已經更新的本地 master 分支到中央倉庫。

4.示例

下面的示例演示瞭如何把 Pull Requests 作為 Code Review 的方式，但注意 Pull Requests 可以用於很多其它的目的。

1）小紅開始開發一個新功能

在開始開發功能前，小紅需要一個獨立的分支。使用下面的命令新建一個分支：

git checkout -b marys-feature master

這個命令檢出一個基於 master 名為 marys-feature 的分支，Git 的 -b 選項表示如果分支還不存在則新建分支。這個新分支上，小紅按老套路編輯、暫存和提交修改，按需要提交以實現功能：

git status
git add
git commit

2）小紅要去吃個午飯

早上小紅為新功能新增一些提交。去吃午飯前，push 功能分支到中央倉庫是很好的做法，這樣可以方便地備份，如果和其它開發協作，也讓他們可以看到小紅的提交。

git push -u origin marys-feature

1

這條命令 push marys-feature 分支到中央倉庫（origin），-u 選項設定本地分支去跟蹤遠端對應的分支。設定好跟蹤的分支後，小紅就可以使用 git push 命令省去指定推送分支的引數。

3）小紅完成功能開發

小紅吃完午飯回來，完成整個功能的開發。在合併到 master 之前，她發起一個 Pull Request 讓團隊的其它人知道功能已經完成。但首先，她要確認中央倉庫中已經有她最近的提交：

git push

然後，在她的 Git GUI 客戶端中發起 Pull Request，請求合併 marys-feature 到 master，團隊成員會自動收到通知。Pull Request 很酷的是可以在相關的提交旁邊顯示評註，所以你可以很對某個變更集提問。

4）小黑收到 Pull Request

小黑收到了 Pull Request 後會檢視 marys-feature 的修改。決定在合併到正式專案前是否要做些修改，且通過 Pull Request 和小紅來回地討論。

5）小紅再做修改

要再做修改，小紅用和功能第一個迭代完全一樣的過程。編輯、暫存、提交併push更新到中央倉庫。小紅這些活動都會顯示在 Pull Request 上，小黑可以斷續做評註。

如果小黑有需要，也可以把 marys-feature 分支拉到本地，自己來修改，他加的提交也會一樣顯示在 Pull Request 上。

6）小紅髮布她的功能

一旦小黑可以的接受 Pull Request，就可以合併功能到穩定專案程式碼中（可以由小黑或是小紅來做這個操作）：

git checkout master
git pull
git pull origin marys-feature
git push

無論誰來做合併，首先要檢出 master 分支並確認是它是最新的。然後執行 git pull origin marys-feature 合併 marys-feature 分支到和已經和遠端一致的本地 master 分支。你可以使用簡單 git merge marys-feature 命令，但前面的命令可以保證總是最新的新功能分支。最後更新的 master 分支要重新 push 回到 origin。

這個過程常常會生成一個合併提交。有些開發者喜歡有合併提交，因為它像一個新功能和原來程式碼基線的連通符。但如果你偏愛線性的提交歷史，可以在執行合併時 rebase 新功能到 master 分支的頂部，這樣生成一個快進（fast-forward）的合併。

一些 GUI 客戶端可以只要點一下『接受』按鈕執行好上面的命令來自動化 Pull Request 接受過程。如果你的不能這樣，至少在功能合併到 master 分支後能自動關閉 Pull Request。

7）與此同時，小明在做和小紅一樣的事

當小紅和小黑在 marys-feature 上工作並討論她的 Pull Request 的時候，小明在自己的功能分支上做完全一樣的事。

通過隔離功能到獨立的分支上，每個人都可以自主的工作，當然必要的時候在開發者之間分享變更還是比較繁瑣的。

8）總結

到了這裡，但願你發現了功能分支可以很直接地在集中式工作流的僅有的 master 分支上完成多功能的開發。另外，功能分支還使用了 Pull Request，使得可以在你的版本控制 GUI 客戶端中討論某個提交。

功能分支工作流是開發專案異常靈活的方式。問題是，有時候太靈活了。對於大型團隊，常常需要給不同分支分配一個更具體的角色。GitFlow 工作流是管理功能開發、釋出準備和維護的常用模式。

五、GitFlow 工作流

1.概述

GitFlow 工作流定義了一個圍繞專案釋出的嚴格分支模型。雖然比功能分支工作流複雜幾分，但提供了用於一個健壯的用於管理大型專案的框架。

GitFlow 工作流沒有用超出功能分支工作流的概念和命令，而是為不同的分支分配一個很明確的角色，並定義分支之間如何和什麼時候進行互動。除了使用功能分支，在做準備、維護和記錄釋出也使用各自的分支。當然你可以用上功能分支工作流所有的好處：Pull Requests、隔離實驗性開發和更高效的協作。

2.工作方式

GitFlow 工作流仍然用中央倉庫作為所有開發者的互動中心。和其它的工作流一樣，開發者在本地工作並 push 分支到中央倉庫中。

1）歷史分支

相對使用僅有的一個 master 分支，GitFlow 工作流使用2個分支來記錄專案的歷史。master 分支儲存了正式釋出的歷史，而 develop 分支作為功能的整合分支。這樣也方便 master 分支上的所有提交分配一個版本號。

剩下要說明的問題圍繞著這2個分支的區別展開。

2）功能分支

每個新功能位於一個自己的分支，這樣可以 push 到中央倉庫以備份和協作。但功能分支不是從 master 分支上拉出新分支，而是使用 develop 分支作為父分支。當新功能完成時，合併回 develop 分支。新功能提交應該從不直接與 master 分支互動。

注意，從各種含義和目的上來看，功能分支加上 develop 分支就是功能分支工作流的用法。但 GitFlow 工作流沒有在這裡止步。

3）釋出分支

一旦 develop 分支上有了做一次釋出（或者說快到了既定的釋出日）的足夠功能，就從 develop 分支上 fork 一個釋出分支。新建的分支用於開始釋出迴圈，所以從這個時間點開始之後新的功能不能再加到這個分支上 —— 這個分支只應該做 Bug 修復、文件生成和其它面向釋出任務。一旦對外發布的工作都完成了，釋出分支合併到 master 分支並分配一個版本號打好 Tag。另外，這些從新建釋出分支以來的做的修改要合併回 develop 分支。

使用一個用於釋出準備的專門分支，使得一個團隊可以在完善當前的釋出版本的同時，另一個團隊可以繼續開發下個版本的功能。這也打造定義良好的開發階段（比如，可以很輕鬆地說，『這周我們要做準備釋出版本 4.0』，並且在倉庫的目錄結構中可以實際看到）。

常用的分支約定：

• 用於新建釋出分支的分支: develop
• 用於合併的分支: master
• 分支命名: release-* 或 release/*

4）維護分支

維護分支或說是熱修復（hotfix）分支用於生成快速給產品釋出版本（production releases）打補丁，這是唯一可以直接從 master 分支 fork 出來的分支。修復完成，修改應該馬上合併回 master 分支和 develop 分支（當前的釋出分支），master 分支應該用新的版本號打好 Tag。

為 Bug 修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個釋出迴圈。你可以把維護分支想成是一個直接在 master 分支上處理的臨時釋出。

3.示例

下面的示例演示本工作流如何用於管理單個釋出迴圈。假設你已經建立了一箇中央倉庫。

1）建立開發分支

第一步為 master 分支配套一個 develop 分支。簡單來做可以本地建立一個空的 develop 分支，push 到伺服器上：

git branch develop
git push -u origin develop

以後這個分支將會包含了專案的全部歷史，而 master 分支將只包含了部分歷史。其它開發者這時應該克隆中央倉庫，建好 develop 分支的跟蹤分支：

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

現在每個開發都有了這些歷史分支的本地拷貝。

2）小紅和小明開始開發新功能

這個示例中，小紅和小明開始各自的功能開發。他們需要為各自的功能建立相應的分支。新分支不是基於 master 分支，而是應該基於 develop 分支：

git checkout -b some-feature develop

1

他們用老套路新增提交到各自功能分支上：編輯、暫存、提交：

git status
git add
git commit

3）小紅完成功能開發

添加了提交後，小紅覺得她的功能 OK 了。如果團隊使用 Pull Requests，這時候可以發起一個用於合併到 develop 分支。否則她可以直接合併到她本地的 develop 分支後 push 到中央倉庫：

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

第一條命令在合併功能前確保 develop 分支是最新的。注意，功能決不應該直接合併到 master 分支。衝突解決方法和集中式工作流一樣。

4）小紅開始準備釋出

這個時候小明正在實現他的功能，小紅開始準備她的第一個專案正式釋出。像功能開發一樣，她用一個新的分支來做釋出準備。這一步也確定了釋出的版本號：

git checkout -b release-0.1 develop

這個分支是清理髮布、執行所有測試、更新文件和其它為下個釋出做準備操作的地方，像是一個專門用於改善釋出的功能分支。

只要小紅建立這個分支並 push 到中央倉庫，這個釋出就是功能凍結的。任何不在 develop 分支中的新功能都推到下個釋出迴圈中。

5）小紅完成釋出

一旦準備好了對外發布，小紅合併修改到 master 分支和 develop 分支上，刪除釋出分支。合併回 develop 分支很重要，因為在釋出分支中已經提交的更新需要在後面的新功能中也要是可用的。另外，如果小紅的團隊要求 Code Review，這是一個發起 Pull Request 的理想時機。

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 分支，就應該打好 Tag 以方便跟蹤。

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

Git 有提供各種勾子（hook），即倉庫有事件發生時觸發執行的指令碼。可以配置一個勾子，在你 push 中央倉庫的 master 分支時，自動構建好對外發布。

6）終端使用者發現 Bug

對外發布後，小紅回去和小明一起做下個釋出的新功能開發，直到有終端使用者開了一個 Ticket 抱怨當前版本的一個 Bug。為了處理 Bug，小紅（或小明）從 master 分支上拉出了一個維護分支，提交修改以解決問題，然後直接合並回 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

4.總結

到了這裡，但願你對集中式工作流、功能分支工作流和 GitFlow 工作流已經感覺很舒適了。你應該也牢固的掌握了本地倉庫的潛能，push/pull 模式和 Git 健壯的分支和合並模型。

記住，這裡演示的工作流只是可能用法的例子，而不是在實際工作中使用 Git 不可違逆的條例。所以不要畏懼按自己需要對工作流的用法做取捨。不變的目標就是讓 Git 為你所用。

六、Forking 工作流

Forking 工作流和前面討論的幾種工作流有根本的不同。這種工作流不是使用單個服務端倉庫作為『中央』程式碼基線，而讓各個開發者都有一個服務端倉庫。這意味著各個程式碼貢獻者有 2 個 Git 倉庫而不是 1 個：一個本地私有的，另一個服務端公開的。

Forking 工作流的一個主要優勢是，貢獻的程式碼可以被整合，而不需要所有人都能 push 程式碼到僅有的中央倉庫中。開發者 push 到自己的服務端倉庫，而只有專案維護者才能 push 到正式倉庫。這樣專案維護者可以接受任何開發者的提交，但無需給他正式程式碼庫的寫許可權。

效果就是一個分散式的工作流，能為大型、自發性的團隊（包括了不受信的第三方）提供靈活的方式來安全的協作。也讓這個工作流成為開源專案的理想工作流。

1.工作方式

和其它的 Git 工作流一樣，Forking 工作流要先有一個公開的正式倉庫儲存在伺服器上。但一個新的開發者想要在專案上工作時，不是直接從正式倉庫克隆，而是 fork 正式專案在伺服器上建立一個拷貝。

這個倉庫拷貝作為他個人公開倉庫 —— 其它開發者不允許 push 到這個倉庫，但可以 pull 到修改（後面我們很快就會看這點很重要）。在建立了自己服務端拷貝之後，和之前的工作流一樣，開發者執行 git clone 命令克隆倉庫到本地機器上，作為私有的開發環境。

要提交本地修改時，push 提交到自己公開倉庫中 —— 而不是正式倉庫中。然後，給正式倉庫發起一個 pull request，讓專案維護者知道有更新已經準備好可以集成了。對於貢獻的程式碼，pull request 也可以很方便地作為一個討論的地方。

為了整合功能到正式程式碼庫，維護者 pull 貢獻者的變更到自己的本地倉庫中，檢查變更以確保不會讓專案出錯，合併變更到自己本地的 master 分支，然後 push master 分支到伺服器的正式倉庫中。到此，貢獻的提交成為了專案的一部分，其它的開發者應該執行 pull 操作與正式倉庫同步自己本地倉庫。

1）正式倉庫

在 Forking 工作流中，『官方』倉庫的叫法只是一個約定，理解這點很重要。從技術上來看，各個開發者倉庫和正式倉庫在Git看來沒有任何區別。事實上，讓正式倉庫之所以正式的唯一原因是它是專案維護者的公開倉庫。

2）Forking 工作流的分支使用方式

所有的個人公開倉庫實際上只是為了方便和其它的開發者共享分支。各個開發者應該用分支隔離各個功能，就像在功能分支工作流和 GitFlow 工作流一樣。唯一的區別是這些分支被共享了。在 Forking 工作流中這些分支會被 pull 到另一個開發者的本地倉庫中，而在功能分支工作流和 GitFlow 工作流中是直接被 push 到正式倉庫中。

2.示例

1）專案維護者初始化正式倉庫

和任何使用 Git 專案一樣，第一步是建立在伺服器上一個正式倉庫，讓所有團隊成員都可以訪問到。通常這個倉庫也會作為專案維護者的公開倉庫。

公開倉庫應該是裸倉庫，不管是不是正式程式碼庫。所以專案維護者會執行像下面的命令來搭建正式倉庫：

ssh user@host
git init --bare /path/to/repo.git

Bitbucket 和 Stash 提供了一個方便的 GUI 客戶端以完成上面命令列做的事。這個搭建中央倉庫的過程和前面提到的工作流完全一樣。如果有現存的程式碼庫，維護者也要 push 到這個倉庫中。

2）開發者 fork 正式倉庫

其它所有的開發需要 fork 正式倉庫。可以用 git clone 命令用 SSH 協議連通到伺服器，拷貝倉庫到伺服器另一個位置 —— 是的，fork 操作基本上就只是一個服務端的克隆。Bitbucket 和 Stash 上可以點一下按鈕就讓開發者完成倉庫的 fork 操作。

這一步完成後，每個開發都在服務端有一個自己的倉庫。和正式倉庫一樣，這些倉庫應該是裸倉庫。

3）開發者克隆自己 fork 出來的倉庫

下一步，各個開發者要克隆自己的公開倉庫，用熟悉的 git clone 命令。

在這個示例中，假定用 Bitbucket 託管了倉庫。記住，如果這樣的話各個開發者需要有各自的 Bitbucket 賬號，使用下面命令克隆服務端自己的倉庫：

git clone https://[email protected]/user/repo.git

相比前面介紹的工作流只用了一個 origin 遠端別名指向中央倉庫，Forking 工作流需要 2 個遠端別名 —— 一個指向正式倉庫，另一個指向開發者自己的服務端倉庫。別名的名字可以任意命名，常見的約定是使用 origin 作為遠端克隆的倉庫的別名（這個別名會在執行 git clone 自動建立），upstream（上游）作為正式倉庫的別名。

git remote add upstream https://bitbucket.org/maintainer/repo

需要自己用上面的命令建立 upstream 別名。這樣可以簡單地保持本地倉庫和正式倉庫的同步更新。注意，如果上游倉庫需要認證（比如不是開源的），你需要提供使用者：

git remote add upstream https://[email protected]/maintainer/repo.git

這時在克隆和 pull 正式倉庫時，需要提供使用者的密碼。

4）開發者開發自己的功能

在剛克隆的本地倉庫中，開發者可以像其它工作流一樣的編輯程式碼、提交修改和新建分支：

git checkout -b some-feature
// Edit some code
git commit -a -m "Add first draft of some feature"

所有的修改都是私有的直到 push 到自己公開倉庫中。如果正式專案已經往前走了，可以用 git pull 命令獲得新的提交：

git pull upstream master

由於開發者應該都在專門的功能分支上工作，pull 操作結果會都是快進合併。

5）開發者釋出自己的功能

一旦開發者準備好了分享新功能，需要做二件事。首先，通過push他的貢獻程式碼到自己的公開倉庫中，讓其它的開發者都可以訪問到。他的 origin 遠端別名應該已經有了，所以要做的就是：

git push origin feature-branch

這裡和之前的工作流的差異是，origin 遠端別名指向開發者自己的服務端倉庫，而不是正式倉庫。

第二件事，開發者要通知專案維護者，想要合併他的新功能到正式庫中。Bitbucket 和 Stash 提供了 Pull Request 按鈕，彈出表單讓你指定哪個分支要合併到正式倉庫。一般你會想整合你的功能分支到上游遠端倉庫的 master 分支中。

6）專案維護者整合開發者的功能

當專案維護者收到 pull request，他要做的是決定是否整合它到正式程式碼庫中。有二種方式來做：

• 直接在 pull request 中檢視程式碼
• pull 程式碼到他自己的本地倉庫，再手動合併

第一種做法更簡單，維護者可以在 GUI 中檢視變更的差異，做評註和執行合併。但如果出現了合併衝突，需要第二種做法來解決。這種情況下，維護者需要從開發者的服務端倉庫中 fetch 功能分支，合併到他本地的 master 分支，解決衝突：

git fetch https://bitbucket.org/user/repo feature-branch
// 檢視變更
git checkout master
git merge FETCH_HEAD

變更整合到本地的 master 分支後，維護者要 push 變更到伺服器上的正式倉庫，這樣其它的開發者都能訪問到：

git push origin master

注意，維護者的 origin 是指向他自己公開倉庫的，即是專案的正式程式碼庫。到此，開發者的貢獻完全整合到了專案中

7）開發者和正式倉庫做同步

由於正式程式碼庫往前走了，其它的開發需要和正式倉庫做同步：

git pull upstream master

3.總結

如果你之前是使用 SVN，Forking 工作流可能看起來像是一個激進的正規化切換（paradigm shift）。但不要害怕，這個工作流實際上就是在功能分支工作流之上引入另一個抽象層。不是直接通過單箇中央倉庫來分享分支，而是把貢獻程式碼釋出到開發者自己的服務端倉庫中。

示例中解釋了，一個貢獻如何從一個開發者流到正式的 master 分支中，但同樣的方法可以把貢獻整合到任一個倉庫中。比如，如果團隊的幾個人協作實現一個功能，可以在開發之間用相同的方法分享變更，完全不涉及正式倉庫。

這使得 Forking 工作流對於鬆散組織的團隊來說是個非常強大的工具。任一開發者可以方便地和另一開發者分享變更，任何分支都能有效地合併到正式程式碼庫中。

七、Pull Requests

Pull Requests 是 Bitbucket 上方便開發者之間協作的功能。提供了一個使用者友好的 Web 介面，在整合提交的變更到正式專案前可以對變更進行討論。

開發者向團隊成員通知功能開發已經完成，Pull Requests 是最簡單的用法。開發者完成功能開發後，通過 Bitbucket 賬號發起一個 Pull Request。這樣讓涉及這個功能的所有人知道，要去做 Code Review 和合併到 master 分支。

但是，Pull Request 遠不止一個簡單的通知，而是為討論提交的功能的一個專門論壇。如果變更有任何問題，團隊成員反饋在 Pull Request 中，甚至 push 新的提交微調功能。所有的這些活動都直接跟蹤在 Pull Request 中。

相比其它的協作模型，這種分享提交的形式有助於打造一個更流暢的工作流。SVN 和 Git 都能通過一個簡單的指令碼收到通知郵件；但是，討論變更時，開發者通常只能去回覆郵件。這樣做會變得雜亂，尤其還要涉及後面的幾個提交時。Pull Requests 把所有相關功能整合到一個和 Bitbucket 倉庫介面整合的使用者友好 Web 介面中。

1.解析 Pull Request

當要發起一個 Pull Request，你所要做的就是請求（Request）另一個開發者（比如專案的維護者），來 pull 你倉庫中一個分支到他的倉庫中。這意味著你要提供 4 個資訊（源倉庫、源分支、目的倉庫、目的分支），以發起 Pull Request。

2.工作方式

Pull Request 可以和功能分支工作流、GitFlow 工作流或 Forking 工作流一起使用。但 Pull Request 要求要麼分支不同，要麼倉庫不同，所以不能用於集中式工作流。在不同的工作流中使用 Pull Request 會有一些不同，但基本的過程是這樣的：

• 開發者在本地倉庫中新建一個專門的分支開發功能。
• 開發者 push 分支修改到公開的 Bitbucket 倉庫中。
• 開發者通過 Bitbucket 發起一個 Pull Request。
• 團隊的其它成員 review code，討論並修改。
• 專案維護者合併功能到官方倉庫中並關閉 Pull Request。

1）在功能分支工作流中使用 Pull Request

功能分支工作流用一個共享的 Bitbucket 倉庫來管理協作，開發者在專門的分支上開發功能。但不是立即合併到 master 分支上，而是在合併到主程式碼庫之前開發者應該開一個 Pull Request 發起功能的討論。

功能分支工作流只有一個公開的倉庫，所以 Pull Request 的目的倉庫和源倉庫總是同一個。通常開發者會指定他的功能分支作為源分支，master 分支作為目的分支。

收到 Pull Request 後，專案維護者要決定如何做。如果功能沒問題，就簡單地合併到 master 分支，關閉 Pull Request。但如果提交的變更有問題，他可以在 Pull Request 中反饋。之後新加的提交也會評論之後接著顯示出來

在功能還沒有完全開發完的時候，也可能發起一個 Pull Request。比如開發者在實現某個需求時碰到了麻煩，他可以發一個包含正在進行中工作的 Pull Request。其它的開發者可以在 Pull Request 提供建議，或者甚至直接新增提交來解決問題。

2）在 GitFlow 工作流中使用 Pull Request

GitFlow 工作流和功能分支工作流類似，但圍繞專案釋出定義一個嚴格的分支模型。在 GitFlow 工作流中使用 Pull Request 讓開發者在釋出分支或是維護分支上工作時，可以有個方便的地方對關於釋出分支或是維護分支的問題進行交流。

GitFlow 工作流中 Pull Request 的使用過程和上一節中完全一致：當一個功能、釋出或是熱修復分支需要 Review 時，開發者簡單發起一個 Pull Request，團隊的其它成員會通過 Bitbucket 收到通知。

新功能一般合併到 develop 分支，而釋出和熱修復則要同時合併到 develop 分支和 master 分支上。Pull Request 可能用做所有合併的正式管理。

3）在 Forking 工作流中使用 Pull Request

在 Forking 工作流中，開發者 push 完成的功能到他自己的倉庫中，而不是共享倉庫。然後，他發起一個 Pull Request，讓專案維護者知道他的功能已經可以 Review 了。

在這個工作流，Pull Request 的通知功能非常有用，因為專案維護者不可能知道其它開發者在他們自己的倉庫添加了提交

由於各個開發有自己的公開倉庫，Pull Request 的源倉庫和目標倉庫不是同一個。源倉庫是開發者的公開倉庫，源分支是包含了修改的分支。如果開發者要合併修改到正式程式碼庫中，那麼目標倉庫是正式倉庫，目標分支是 master 分支。

Pull Request 也可以用於正式專案之外的其它開發者之間的協作。比如，如果一個開發者和一個團隊成員一起開發一個功能，他們可以發起一個 Pull Request，用團隊成員的 Bitbucket 倉庫作為目標，而不是正式專案的倉庫。然後使用相同的功能分支作為源和目標分支。

2 個開發者之間可以在 Pull Request 中討論和開發功能。完成開發後，他們可以發起另一個 Pull Request，請求合併功能到正式的 master 分支。在 Forking 工作流中，這樣的靈活性讓 Pull Request 成為一個強有力的協作工具。

3.示例

下面的示例演示了 Pull Request 如何在在 Forking 工作流中使用。也同樣適用於小團隊的開發協作和第三方開發者向開源專案的貢獻。

在示例中，小紅是個開發，小明是專案維護者。他們各自有一個公開的 Bitbucket 倉庫，而小明的倉庫包含了正式工程。

1）小紅 fork 正式專案

小紅先要 fork 小明的 Bitbucket 倉庫，開始專案的開發。她登陸 Bitbucket，瀏覽到小明的倉庫頁面，點 Fork 按鈕。

然後為 fork 出來的倉庫填寫名字和描述，這樣小紅就有了服務端的專案拷貝了。

2）小紅克隆她的 Bitbucket 倉庫

下一步，小紅克隆自己剛才 fork 出來的 Bitbucket 倉庫，以在本機上準備出工作拷貝。命令如下：

git clone https://[email protected]/user/repo.git

請記住，git clone 會自動建立 origin 遠端別名，是指向小紅 fork 出來的倉庫。

3）小紅開發新功能

在開始改程式碼前，小紅要為新功能先新建一個新分支。她會用這個分支作為 Pull Request 的源分支。

git checkout -b some-feature

4.編輯程式碼

git commit -a -m "Add first draft of some feature"

在新功能分支上，小紅按需要新增提交。甚至如果小紅覺得功能分支上的提交歷史太亂了，她可以用互動式 rebase 來刪除或壓制提交。對於大型專案，整理功能分支的歷史可以讓專案維護者更容易看出在 Pull Request 中做了什麼內容。

1）小紅 push 功能到她的 Bitbucket 倉庫中

小紅完成了功能後，push 功能到她自己的 Bitbucket 倉庫中（不是正式倉庫），用下面簡單的命令：

git push origin some-branch

這時她的變更可以讓專案維護者看到了（或者任何想要看的協作者）。

2）小紅髮起 Pull Request

Bitbucket 上有了她的功能分支後，小紅可以用她的 Bitbucket 賬號瀏覽到她的 fork 出來的倉庫頁面，點右上角的【Pull Request】按鈕，發起一個 Pull Request。彈出的表單自動設定小紅的倉庫為源倉庫，詢問小紅以指定源分支、目標倉庫和目標分支。

小紅想要合併功能到正式倉庫，所以源分支是她的功能分支，目標倉庫是小明的公開倉庫，而目標分支是 master 分支。另外，小紅需要提供 Pull Request 的標題和描述資訊。如果需要小明以外的人稽核批准程式碼，她可以把這些人填在【Reviewers】文字框中。

建立好了 Pull Request，通知會通過Bitbucket系統訊息或郵件（可選）發給小明。

3）小明 review Pull Request

在小明的 Bitbucket 倉庫頁面的 【Pull Request】Tab 可以看到所有人發起的 Pull Request。點選小紅的 Pull Request 會顯示出 Pull Request 的描述、功能的提交歷史和每個變更的差異（diff）。

如果小明想要合併到專案中，只要點一下【Merge】按鈕，就可以同意 Pull Request 併合併到 master 分支。

但如果像這個示例中一樣小明發現了在小紅的程式碼中的一個小 Bug，要小紅在合併前修復。小明可以在整個 Pull Request 上加上評註，或是選擇歷史中的某個提交加上評註。

4）小紅補加提交

如果小紅對反饋有任何疑問，可以在 Pull Request 中響應，把 Pull Request 當作是她功能討論的論壇。

小紅在她的功能分支新加提交以解決程式碼問題，並 push 到她的 Bitbucket 倉庫中，就像前一輪中的做法一樣。這些提交會進入的 Pull Request，小明在原來的評註旁邊可以再次 review 變更。

5）小明接受 Pull Request

最終，小明接受變更，合併功能分支到 master 分支，並關閉 Pull Request。至此，功能整合到專案中，其它的專案開發者可以用標準的 git pull 命令 pull 這些變更到自己的本地倉庫中。

5.總結

Pull Request 並不是為了替代任何基於 Git 的協作工作流，而是它們的一個便利的補充，讓團隊成員間的協作更輕鬆方便。