【51CTO.com快譯】

 毋庸置疑，由于Git允許開發(fā)人員能夠同時(shí)在相同的代碼庫上工作，因此它在各類軟件開發(fā)中起到了重要的作用。不過，我們也發(fā)現(xiàn)部分開發(fā)人員由于未能遵循Git的相關(guān)最佳實(shí)踐(請參見--https://acompiler.com/git-best-practices/)，因此導(dǎo)致了各種程序在運(yùn)行，以及代碼調(diào)用過程中所暴露出來的棘手問題。下面，我將和您討論在GIT中，影響代碼質(zhì)量的七項(xiàng)優(yōu)秀實(shí)踐，希望能夠?qū)δ娜粘ｉ_發(fā)項(xiàng)目提供幫助。

[[337166]]

1.原子性提交(Atomic Commit)

眾所周知：向Git提交內(nèi)容，就意味著您已經(jīng)確認(rèn)了代碼的更改，并希望將其作為新的受信任版本，保存到Git存儲庫中。不過，版本控制系統(tǒng)通常不會限制您提交代碼的方式。也就是說，您可以采取如下三種方式中的任何一種：

• 一次性提交上千個更改。
• 提交所有的dll和其他依賴項(xiàng)。
• 將有問題的代碼檢入存儲庫中。

可見，此舉并不能保證更新代碼的一致性，有時(shí)甚至?xí)尨a的整體質(zhì)量有所下降。因此我們需要一些時(shí)間來檢查代碼(請參見-- https://dzone.com/articles/what-is-code-review-and-why-do-you-need-it)。在此，為了保障團(tuán)隊(duì)的總體生產(chǎn)力水平，我們可以采用原子性提交(請參見-- https://acompiler.com/git-commands/)，例如：在執(zhí)行原子性提交時(shí)，您的某項(xiàng)更改提交可能會涉及多個文件，那么我們應(yīng)當(dāng)確保這是全局性的寫入，進(jìn)而避免出現(xiàn)任何不一致的情況。和我們以前熟悉的數(shù)據(jù)庫原子性一樣，我們顯然需要將其貫徹到針對Git的操作中。

2.明確地說明提交的內(nèi)容

許多開發(fā)人員只是一味地執(zhí)行更改，提交，以及推送等操作流程，從來不會顧及提交文件的類型和必要性。這樣就會導(dǎo)致諸如：dll和pdf等不需要的文件類型，被提交到了存儲庫中。因此，在將代碼檢入存儲庫之前，您可以考慮如下兩個問題：

• 您是否確實(shí)需要檢入所有的文件?
• 它們是否為源代碼中必要的部分?

您可以簡單地使用.gitignore文件(請參見-- https://acompiler.com/git-commands/)，來避免在存儲庫中出現(xiàn)那些不需要的文件。.gitignore文件既能夠?yàn)槲覀兲岣叽鎯斓那逦?，又有助于我們保持代碼的整潔性。據(jù)此，您可以自由地提交各種代碼文件，那些.dll和.class等自動生成的非必要文件，則會被自動地忽略掉。如果您要同時(shí)處理多個存儲庫，則可以使用全局.gitignore文件，而無需反復(fù)地進(jìn)行添加或推送。

3.掌握各種Git命令

毫無疑問，Git是一個功能強(qiáng)大、且超級實(shí)用的工具。如果您能夠像對待Linux/Unix操作系統(tǒng)那樣，熟練地掌握各種基本的git命令(請參見--https://acompiler.com/git-commands/)，那么您就能夠更有效地使用該工具，并在操作Git的過程中達(dá)到事半功倍的效果。

在使用Git時(shí)，您可能會碰到一些語法規(guī)則等困難，而Git提供了非常友好的聯(lián)機(jī)幫助。您可以使用“git help+命令名稱”從git的bash中了解有關(guān)某個Git命令的更多信息。這種快捷的查找方式，幾乎含括了您可能用到的所有g(shù)it命令。

4.梳理工作流程

如果您的團(tuán)隊(duì)正在某個Git管理項(xiàng)目上協(xié)同工作，那么整個開發(fā)團(tuán)隊(duì)必須確保并使用相同的工作流程。統(tǒng)一流程無疑會給大家?guī)砣缦氯?xiàng)優(yōu)勢：

• 讓開發(fā)的整個過程更具有條理性。
• 良好的Git工作流程可始終確保分支(branches)處于整潔狀態(tài)。
• 讓團(tuán)隊(duì)的溝通更加流暢，并提高輸出代碼的整體質(zhì)量。

5.先測試后推送

我們需要在提交代碼，或?qū)⒋a推送到生成環(huán)境之前，對各項(xiàng)更改進(jìn)行充分地測試。過去，我們想方設(shè)法阻止項(xiàng)目成員將有缺陷的代碼，直接提交的本地存儲庫中。如今，我們同樣需要本著敏捷開發(fā)的思想，避免那些有問題的源代碼，給在線協(xié)作團(tuán)隊(duì)造成困擾。在具體實(shí)踐中，我們需要做到：

• 鼓勵整個團(tuán)隊(duì)在提交之前，針對其代碼的更改部分開展相關(guān)的單元測試，這是從根源上避免代碼缺陷的流出。
• 如果在構(gòu)建的過程中，發(fā)現(xiàn)了任何代碼的錯誤，應(yīng)立即終止構(gòu)建。大家可通過“會診”的方式，及時(shí)修復(fù)該錯誤，以避免此類錯誤流入Git中，甚至被其他的代碼段所調(diào)用到。

6.保護(hù)主(master)分支

由于Git中的默認(rèn)分支是master，因此我們需要確保master分支上的代碼，能夠穩(wěn)定地處于生產(chǎn)環(huán)境之中。您可以通過諸如：前后鉤子(pre and post hooks)、以及公司相關(guān)策略等多種方式，來保護(hù)master分支。此外，您還可以在master分支上啟用如下防護(hù)措施：

• 確保master分支不會被意外或有意地刪除。
• 在master分支上的各種提交歷史記錄，不應(yīng)被覆蓋掉。
• 在master中，代碼不應(yīng)在未經(jīng)審查的情況下，被直接檢入。

7.分支管理

Git提供了強(qiáng)大的分支模型。您應(yīng)該將手頭的代碼保留在與主分支完全隔離的其他分支中。無論您是要添加一個新功能，還是修復(fù)一些錯誤，亦或需要進(jìn)行重構(gòu)，都請首先創(chuàng)建一個新的分支。在完成了必要的更改之后，請審查代碼，再發(fā)出拉取請求，將其合并到主分支中，并保持同步。

小結(jié)

上面便是我們在使用Git時(shí)，需要遵循的七項(xiàng)優(yōu)秀實(shí)踐。當(dāng)然，為了進(jìn)一步提高代碼質(zhì)量和整體生產(chǎn)率，您也可以借鑒AFTER技術(shù)，具體內(nèi)容可參考--https://acompiler.com/after-technique/。

【原標(biāo)題】7 Best Practices in GIT for Your Code Quality ，作者: Rajeev Bera

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】