早知道就好了，這些使用 Git 的正確姿勢！

昨天代碼還好好地今天都不行了 T_T

代碼不小心被刪了！！！

突然出現了一個奇怪的 bug 但是大家都摸不著頭腦？？？

…

如果你有過上述經歷，那這篇文章就是為你而寫的！

除了知道git add ，git commit ， git push之外，Git 還有很多重要的技巧。如果能掌握這些技巧，將受益無窮。我將會在這篇文章里介紹一些使用 Git 的正確姿勢 。

Git 工作流

每當項目有多個開發者參與時，正確的 Git 工作流就顯得非常重要了。下面我會介紹一個在多人大項目中非常有效的工作流。

情景

你一夜之間被認命為一個項目的技術負責人，這個項目旨在打造下一個 Facebook。你的團隊有三個開發者：

1. Alice：一年工作經驗，熟悉編程

2. Bob：一年工作經驗，熟悉編程

3. John：三年工作經驗，精通編程

4. 你：技術負責人

Git 開發流程

Master branch （主分支）

1. Master 分支應該始終有生產環境代碼(production code）的副本

2. 任何人（包括技術負責人在內）都不允許直接在 master 分支上寫代碼，因為它只是生產環境代碼的副本

3. 實際代碼寫在其他分支中

Release branch（發布分支）

1. 項目開始時，首先要為項目創建 release branch。 release branch是從 master branch 創建的。

2. 與此項目有關的所有代碼都在 release branch 里。release branch 其實只是一個前綴為release/ 的普通分支。

3. 讓我們把這個例子中的 release branch 取名為 release/fb。

4. 由於同一代碼庫上可能運行著多個項目，所以需要為每一個項目創建一個單獨的 release branch。假設還有另一個項目同時運行著，那麼這個項目就有一個比如叫 release/messenger 的單獨的 release branch。

5. Release branch 的存在是為了讓同一代碼庫能同時運行多個項目而不會相互干擾。

Feature branch （功能分支）

1. 對於構建在應用程序中的每個功能，都會創建一個單獨的 feature 分支。這確保了各個功能能被獨立構建。

2. Feature 分支只是有著 feature/ 前綴的普通分支。

3. 現在，作為技術負責人的你讓 Alice 給你們的 Facebook 寫一個登陸界面，於是她創建了一個新的 feature 分支，我們就叫它 feature/login。Alice 將會把所有登陸環節的代碼都寫在這個 feature 分支上。

4. 這個 feature 分支是從你們的 release 分支創建的。

5. Bob 的任務則是寫添加好友頁面，所以Bob 創建了一個叫做 feature/friendrequest的 feature 分支。

6. John 的任務是構建 newsfeed，所以John創建了名叫 feature/newsfeed 的 feature 分支。

7. 所有開發者寫的代碼都在他們各自的feature 分支，到目前為止一切順利。

8. 現在，假設 Alice 已經完成了登陸代碼，她需要把代碼從她的 feature 分支 feature/login 發送到 release 分支 release/fb。這是通過 pull 請求 完成的。

Pull 請求（Pull Request)

首先要指出，pull 請求和 git pull是兩回事。

開發者不能直接把代碼推送到 release 分支。feature 分支上的代碼需要經過技術負責人的審查，才能推送到 release 分支。這時候需要 pull 請求。

在 Github 中，你可以像下面那樣提出 pull 請求：

在分支名的右邊有個"New pull request（新 pull 請求）" 選項，點擊它就會打開如下畫面：

上圖中：

● compare 分支是 Alice 的 feature 分支 feature/login.

● base 分支是release 分支 release/fb.

這一步完成之後，Alice 需要為這個 pull 請求輸入標題和描述，最終點擊" Create Pull Request（創建 Pull 請求）。Alice 也需要為這個 pull 請求指定一個審查者，因為你是技術負責人，所以她輸入了你的名字。

技術負責人審查 pull 請求的代碼之後，把代碼從 feature 分支合併(merge)到 release 分支。

這樣你就成功把 feature/login 分支的代碼合併(merge)到 release/fb 分支了，Alice 表示很開心她的代碼被合併了。

代碼衝突

1. Bob 也寫完了代碼，提出了一個 從feature/friendrequest 到 release/fb 的pull 請求。

2. 由於 release 分支已經有登陸功能的代碼，引起了代碼衝突。審查者有責任解決代碼衝突併合並代碼，於是作為技術負責人的你出馬解決了問題，合併了衝突的代碼。

3. 現在 John 也完成了他的代碼，想要把代碼加到 release 分支中。但是老鳥 John 非常擅長處理代碼衝突。所以 John 從 release/fb 分支抓取了最新的代碼到他自己的分支 feature/newsfeed 上（通過 ****git pull 或 git merge都行）。John 解決了所有的代碼衝突，現在 feature/newsfeed 分支也像 release/fb 一樣包含了現有的全部代碼。

4. 最後，John 提出了 pull 請求。因為他之前已經合併好了代碼，這次的 pull 請求沒有出現代碼衝突。

綜上，有兩種方法來解決代碼衝突：

● 第一種：由pull 請求的審查者解決代碼衝突。

● 第二種：開發者確保 release 分支的最新代碼已經合併到自己的 feature 分支，自己處理好代碼衝突。

又回到 master 分支

當項目完成，release 分支里的代碼被合併到 master 分支，然後代碼被部署到生產中。因此，生產中的代碼和 master 分支中的代碼始終保持同步。 這也確保了對於任何未來的項目， master 分支中都提供了最新的代碼。

恭喜 ，你現在 get 使用 Git 的正確姿勢了！Git 還有一些別的概念如修改提交、重寫歷史等同樣很有用，但 Git 工作流對於大項目的成功來說至關重要。

編譯/ 佑銘

知乎機構號：來自矽谷的終身學習平台——優達學城（http://Udacity.com），專註於技能提升和求職法則，讓你在家能追隨 Google、Facebook、IBM 等行業大佬，從零開始掌握數據分析、機器學習、深度學習、人工智慧、無人駕駛等前沿技術，激發未來無限可能！