Git詳解——Feature Branching:最流行的工作流
在前面的 Git入門——團隊工作的基本工作模型 中 ,介紹了一種最基本的團隊工作模型。在這種模型里,所有人都工作在 master 上,寫完了的 commit 可以通過 push 來發送到中央倉庫,並且可以使用 pull 來獲取到 別人的最新 commit s。
這種工作模型解決了團隊合作最基本的問題:多人並行開發和版本管理。事實上,這也是早期的 VCS ——中央式 VCS 的工作模型。
但這種工作模型也有它的限制:使用這種工作模型時,每個人的程式碼在被大家看到的時候,就是它進入正式的生產庫的時候。所有人的工作都會被直接 push 到 master
這裡,我將介紹的是目前最流行(不論是中國還是世界)的團隊開發的工作流:Feature Branching。
簡介
這種工作流的核心內容可以總結為兩點:
- 任何新的功能(feature)或 bug 修復全都新建一個 branch
- 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 的話你可以這樣做:
- 把 branch push 到中央倉庫;
- 在中央倉庫處建立一個 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 這種工作流。它的概念很簡單:
- 每個新功能都新建一個 branch 來寫;
- 寫完以後,把程式碼分享給同事看;寫的過程中,也可以分享給同事討論。另外,藉助 GitHub 等服 務提供方的 Pull Request 功能,可以讓程式碼分享變得更加方便;
- 分支確定可以合併後,把分支合併到 master ,並刪除分支。
這種工作流由於功能強大,而且概念和使用方式都很簡單,所以很受歡迎。再加上 GitHub 等平臺提供 了 Pull Request 的支援,目前這種工作流是商業專案開發中最為流行的工作流。