1. 代碼昨天還是運行好好的今天就不行了。
2. 代碼被刪了。
3. 突然出現(xiàn)了一個奇怪的 bug，但是沒人知道怎么回事。

如果你出現(xiàn)過上面的任何一種情況，那本篇文章就是為你準(zhǔn)備的。

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

Git 工作流

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

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

前言

突然有一天，你成為了一個項目的技術(shù) Leader 并計劃做出下一個 Facebook。在這個項目中你有三個開發(fā)人員。

1. Alice：一個開發(fā)小白。
2. Bob：擁有一年工作經(jīng)驗，了解基本開發(fā)。
3. John：三年開發(fā)經(jīng)驗，熟練開發(fā)技能。
4. 你：該項目的技術(shù)負責(zé)人。

Git 開發(fā)流程

Master 分支

1. Master 分支應(yīng)該始終和生產(chǎn)環(huán)境保持一致。
2. 由于 master 和生產(chǎn)代碼是一致的，所以沒有人包括技術(shù)負責(zé)人能在 master 上直接開發(fā)。
3. 真正的開發(fā)代碼應(yīng)當(dāng)寫在其他分支上。

Release(發(fā)布) 分支

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

Feature(功能分支) branch

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

Pull request

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

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

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

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

• 比較分支是 Alice 的功能分支?feature/login。
• base 分支則應(yīng)該是發(fā)布分支?release/fb。

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

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

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

現(xiàn)在你已經(jīng)把?feature/login?分支合并到?release/fb，并且 Alice 非常高興他的代碼被合并了。

代碼沖突

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

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

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

還是 Master 分支

一旦項目完成，發(fā)布分支的代碼需要合并回 master 分支，同時需要發(fā)布到生產(chǎn)環(huán)境。

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

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

題外話

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

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

標(biāo)簽： 代碼 開發(fā)者

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。