【譯】如何高效的使用 Git

原文鏈接

代碼昨天還是運行好好的今天就不行了。

代碼被刪了。

突然出現了一個奇怪的 bug，但是沒人知道怎么回事。

如果你出現過上面的任何一種情況，那本篇文章就是為你准備的。

除了知道 git add, git commit , git push 之外，Git 中還需要其他重要的技術需要掌握。長遠來看對我們是有幫助的。這里我將向你展示 Git 的最佳實踐。

Git 工作流

當有多個開發者同時涉及到一個項目時那么就非常有必要正確使用 Git 工作流。

這里我將介紹一種工作流，它在一個多人大型項目中將非常有用。

前言

突然有一天，你成為了一個項目的技術 Leader 並計划做出下一個 Facebook。在這個項目中你有三個開發人員。

1. Alice：一個開發小白。
2. Bob：擁有一年工作經驗，了解基本開發。
3. John：三年開發經驗，熟練開發技能。
4. 你：該項目的技術負責人。

Git 開發流程

Master 分支

1. Master 分支應該始終和生產環境保持一致。
2. 由於 master 和生產代碼是一致的，所以沒有人包括技術負責人能在 master 上直接開發。
3. 真正的開發代碼應當寫在其他分支上。

Release(發布) 分支

1. 當項目開始時，第一件事情就是創建發布分支。發布分支是基於 master 分支創建而來。
2. 所有與本項目相關的代碼都在發布分支中，這個分支也是一個以 release/ 開頭的普通分支。
3. 比如這次的發布分支名為 release/fb。
4. 可能有多個項目都基於同一份代碼運行，因此對於每一個項目來說都需要創建一個獨立的發布分支。假設現在還有一個項目正在並行運行，那就得為這個項目創建一個單獨的發布分支比如 release/messenger。
5. 需要單獨的發布分支的原因是：多個並行項目是基於同一份代碼運行的，但是項目之間不能有沖突。

Feature(功能分支) branch

1. 對於應用中的每一個功能都應該創建一個獨立的功能分支，這會確保這些功能能被單獨構建。
2. 功能分支也和其他分支一樣，只是以 feature/ 開頭。
3. 現在作為技術 Leader，你要求 Alice 去做 Facebook 的登錄頁面。因此他創建了一個新的功能分支。把他命名為 feature/login。Alice 將會在這個分支上編寫所有的登錄代碼。
4. 這個功能分支通常是基於 Release(發布) 分支 創建而來。
5. Bob 的任務為創建添加好友頁面，因此他創建了一個名為 feature/friendrequest 的功能分支。
6. John 則被安排構建消息流，因此創建了一個 feature/newsfeed 的功能分支。
7. 所有的開發人員都在自己的分支上進行開發，目前為止都很正常。
8. 現在當 Alice 完成了他的登錄開發，他需要將他的功能分支 feature/login 發送給 Release(發布) 分支。這個過程是通過發起一個 pull request 完成的。

Pull request

首先 pull request 不能和 git pull 搞混了。

開發人員不能直接向 Release(發布) 分支推送代碼，技術 Leader 需要在功能分支合並到 Release(發布) 分支之前做好代碼審查。這也是通過 pull request 完成的。

Alice 能夠按照如下 GitHub 方式提交 pull request。

在分支名字的旁邊有一個 “New pull request” 按鈕，點擊之后將會顯示如下界面：

• 比較分支是 Alice 的功能分支 feature/login。
• base 分支則應該是發布分支 release/fb。

點擊之后 Alice 需要為這個 pull request 輸入名稱和描述，最后再點擊 “Create Pull Request” 按鈕。

同時 Alice 需要為這個 pull request 指定一個 reviewer。作為技術 Leader 的你被選為本次 pull request 的 reviewer。

你完成代碼審查之后就需要把這個功能分支合並到 Release(發布) 分支。

現在你已經把 feature/login 分支合並到 release/fb，並且 Alice 非常高興他的代碼被合並了。

代碼沖突 😠

1. Bob 完成了他的編碼工作，同時向 release/fb 分支發起了一個 pull request。
2. 因為發布分支已經合並了登錄的代碼，這時代碼沖突發生了。解決沖突和合並代碼是 reviewer 的責任。在這樣的情況下，作為技術 Leader 就需要解決沖突和合並代碼了。
3. 現在 John 也已經完成了他的開發，同時也想把代碼合並到發布分支。但 John 非常擅長於解決代碼沖突。他將 release/fb 上最新的代碼合並到他自己的功能分支 feature/newsfeed （通過 git pull 或 git merge 命令）。同時他解決了所有存在的沖突，現在 feature/newsfeed 已經有了所有發布分支 release/fb 的代碼。
4. 最后 John 創建了一個 pull request，由於 John 已經解決了所有問題，所以本次 pull request 不會再有沖突了。

因此通常有兩種方式來解決代碼沖突：

• pull request 的 reviewer 需要解決所有的代碼沖突。
• 開發人員需要確保將發布分支的最新代碼合並到功能分支，並且解決所有的沖突。

還是 Master 分支

一旦項目完成，發布分支的代碼需要合並回 master 分支，同時需要發布到生產環境。

因此生產環境中的代碼總是和 master 分支保持一致。同時對於今后的任何項目來說都是要確保 master 代碼是最新的。

我們現在團隊就是按照這樣的方式進行開發，確實可以盡可能的減少代碼管理上的問題。

題外話

像之前那篇《如何成為一位「不那么差」的程序員》說的那樣，建議大家都多看看國外的優質博客。

甚至嘗試和作者交流，經過溝通原作者也會在原文中貼上我的翻譯鏈接。大家互惠互利使好的文章轉播的更廣。

你的點贊與轉發是最大的支持。