在前面的 Git入門——團隊工作的基本工作模型 中 ，介紹了一種最基本的團隊工作模型。在這種模型里，所有人都工作在 master 上，寫完了的 commit 可以通過 push 來發送到中央倉庫，並且可以使用 pull 來獲取到 別人的最新 commit s。

 

這種工作模型解決了團隊合作最基本的問題：多人並行開發和版本管理。事實上，這也是早期的 VCS ——中央式 VCS 的工作模型。

 

但這種工作模型也有它的限制：使用這種工作模型時，每個人的程式碼在被大家看到的時候，就是它進入正式的生產庫的時候。所有人的工作都會被直接 push 到 master

，這導致每個人的程式碼在正式啟用前無法被別人看到（嚴格來講是有辦法的，別人可以直接從你的電腦上 pull ，Git 的「分散式」不是說說的。但——這種做法超級不方便），這樣就讓程式碼在正式啟用前的討論和 review（審閱）非常不方便。現在的商業團隊，開發專案多是採用「邊開發邊釋出、邊開發邊更新、邊開發邊修復」的持續開發策略，所以程式碼分享的不便會極大地影響團隊的開發效率。

 

這裡，我將介紹的是目前最流行（不論是中國還是世界）的團隊開發的工作流：Feature Branching。

 

簡介

這種工作流的核心內容可以總結為兩點：

1. 任何新的功能（feature）或 bug 修復全都新建一個 branch
   來寫；
2. branch 寫完後，合併到 master ，然後刪掉這個 branch 。

 

 

這就是這種工作流最基本的模型。

從上面的動圖來看，這種工作流似乎沒什麼特別之處。但實質上，Feature Branching 這種工作流，為團隊開發時兩個關鍵的問題——程式碼分享和一人多工——提供了解決方案。

1、程式碼分享

假設你在一個叫做「掘金」的團隊工作，現在你要開發一個叫做「掘金小冊」的功能，於是你建立了一個新的 branch 叫做 books ，然後開始在 books 上進行開發工作。

git checkout -b books

 

在十幾個 commit s 過後，「掘金小冊」的基本功能開發完畢，你就把程式碼 push 到中央倉庫（例如 GitHub）去，然後告訴同事：「嘿，小冊的基本功能寫完了，分支名是 books ，誰有空的話幫我 review 一下吧。」

git push origin books

 

 

 

然後你的同事明明正好有空，他就從中央倉庫拉下來了你的程式碼開始讀：

# 明明的電腦：
git pull
git chekcout books

 

讀完以後，明明對你說說，嗯我看完了，我覺得不錯，可以合併到 master ！

於是你就把 books 合併到了 master 上去： 

git checkout master
git pull   # merge 之前 pull 一下，讓 master 更新到和遠端倉庫同步
git merge books

 

 

緊接著，你把合併後的結果 push 到了中央倉庫，並刪掉了 books 這個 branch ： 

git push
git branch -d books
git push origin -d books  # 用 -d 引數把遠端倉庫的 branch 也刪了

 

 

如果同事有意見

上面講的是明明對你的程式碼沒有意見，而假如他在你的程式碼里看到了問題，例如他跑來對你說：「嘿， 你的程式碼縮排為什麼用的是 TAB？快改成空格，不然砍死你哦。」

 

這時，你就可以把你的縮排改成空格，然後做一個新的提交，再 push 上去，然後通知他：「我改完 啦！」

 

明明 pull 下來你的新提交看了看：「嗯，這下可以合併了。」

於是你依照上面的那一套操作，把程式碼合併進 master ，並 push 了上去，然後刪掉了 books 。

瞧，程式碼在同事豎大拇指之前都不會正式釋出到 master ，挺方便的吧？

 

Pull Request

事實上，上面講的這個流程，還可以利用 Pull Request 來進一步簡化。 Pull Request 並不是 Git 的內容，而是一些 Git 倉庫服務提供方（例如 GitHub）所提供的一種便捷功能，它可以讓團隊的成員方便地討論一個 branch ，並在討論結束後一鍵合併這個 branch 到 master 。

 

同樣是把寫好的 branch 給同事看，使用 Pull Request 的話你可以這樣做：

1. 把 branch push 到中央倉庫；
2. 在中央倉庫處建立一個 Pull Request。以 GitHub 為例：

 

 

 

然後你的同事就可以在 GitHub 上看到你建立的 Pull Request 了。他們可以在 GitHub 的這個頁 面檢視你的 commit s，也可以給你評論表示贊同或提意見，你接下來也可以根據他們的意見把新 的 commit s push 上來，這也頁面會隨著你新的 push 而展示出最新的 commit s 。

 

在討論結束以後，你們一致認為這個 branch 可以合併了，你只需要點一下頁面中那個綠色的 "Merge pull request" 按鈕，GitHub 就會自動地在中央倉庫幫你把 branch 合併到 master 了：

 

然後你只要在本地 pull 一下，把最新的內容拉到你的電腦上，這件事情就算完成了。 另外，GitHub 還設計了一個貼心的 "Delete branch" 按鈕，方便你在合併之後一鍵刪除 branch 。

 

 

2、一人多工

除了程式碼分享的便捷，基於 Feature Branch 的工作流對於一人多工的工作需求也提供了很好的支 持。

 

安安心心做事不被打擾，做完一件再做下一件自然是很美好的事，但現實往往不能這樣。對於程式設計師來 說，一種很常見的情況是，你正在認真寫著程式碼，忽然同事過來跟你說：「內個……你這個功能先放一 放吧，我們最新討論出要做另一個更重要的功能，你來做一下吧。」

 

其實，雖然這種情況確實有點煩，但如果你是在獨立的 branch 上做事，切換任務是很簡單的。你只要稍微把目前未提交的程式碼簡單收尾一下，然後做一個帶有「未完成」標記的提交（例如，在提交資訊 里標上「TODO」），然後回到 master 去建立一個新的 branch 就好了。

git checkout master
git checkout -b new_feature

 

上面這兩行程式碼有更簡單的操作方式，不過為了小冊內容的簡潔性，我就不引入更多的內容了， 有興趣的話可以自己搜尋一下。

 

如果有一天需要回來繼續做這個 branch ，你只要用 checkout 切回來，就可以繼續了。

 

小結

這一節介紹了 Feature Branching 這種工作流。它的概念很簡單：

1. 每個新功能都新建一個 branch 來寫；
2. 寫完以後，把程式碼分享給同事看；寫的過程中，也可以分享給同事討論。另外，藉助 GitHub 等服 務提供方的 Pull Request 功能，可以讓程式碼分享變得更加方便；
3. 分支確定可以合併後，把分支合併到 master ，並刪除分支。

 

這種工作流由於功能強大，而且概念和使用方式都很簡單，所以很受歡迎。再加上 GitHub 等平臺提供 了 Pull Request 的支援，目前這種工作流是商業專案開發中最為流行的工作流。