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

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

但這種工作模型也有它的限制：使用這種工作模型時，每個人的代碼在被大家看到的時候，就是它進入正式的生產庫的時候。所有人的工作都會被直接 push 到 master ，這導致每個人的代碼在正式啟用前無法被別人看到（嚴格來講是有辦法的，別人可以直接從你的電腦上 pull

這裏，我將介紹的是目前最流行（不論是中國還是世界）的團隊開發的工作流：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 的支持，目前這種工作流是商業項目開發中最為流行的工作流。

Git詳解——Feature Branching：最流行的工作流