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

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

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

Git 工作流

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

這里我將介紹一種工作流，它在一個(gè)多人大型項(xiàng)目中將非常有用。

前言

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

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

Git 開(kāi)發(fā)流程

Master 分支

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

Release(發(fā)布) 分支

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

Feature(功能分支) branch

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

Pull request

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

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

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

在分支名字的旁邊有一個(gè) “New pull request” 按鈕，點(diǎn)擊之后將會(huì)顯示如下界面：

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

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

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

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

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

代碼沖突

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

因此通常有兩種方式來(lái)解決代碼沖突：

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

還是 Master 分支

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

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

我們現(xiàn)在團(tuán)隊(duì)就是按照這樣的方式進(jìn)行開(kāi)發(fā)，確實(shí)可以盡可能的減少代碼管理上的問(wèn)題。

題外話

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

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

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

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