建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
毋庸置疑，由于Git允許開(kāi)發(fā)人員能夠同時(shí)在相同的代碼庫(kù)上工作，因此它在各類(lèi)軟件開(kāi)發(fā)中起到了重要的作用。不過(guò)，我們也發(fā)現(xiàn)部分開(kāi)發(fā)人員由于未能遵循Git的相關(guān)最佳實(shí)踐(請(qǐng)參見(jiàn)--https://acompiler.com/git-best-practices/)，因此導(dǎo)致了各種程序在運(yùn)行，以及代碼調(diào)用過(guò)程中所暴露出來(lái)的棘手問(wèn)題。下面，我將和您討論在GIT中，影響代碼質(zhì)量的七項(xiàng)優(yōu)秀實(shí)踐，希望能夠?qū)δ娜粘ｉ_(kāi)發(fā)項(xiàng)目提供幫助。
成都創(chuàng)新互聯(lián)是一家專(zhuān)注于成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站與策劃設(shè)計(jì),隆林網(wǎng)站建設(shè)哪家好?成都創(chuàng)新互聯(lián)做網(wǎng)站,專(zhuān)注于網(wǎng)站建設(shè)十載,網(wǎng)設(shè)計(jì)領(lǐng)域的專(zhuān)業(yè)建站公司;建站業(yè)務(wù)涵蓋:隆林等地區(qū)。隆林做網(wǎng)站價(jià)格咨詢(xún):18980820575
1.原子性提交(Atomic Commit)
眾所周知：向Git提交內(nèi)容，就意味著您已經(jīng)確認(rèn)了代碼的更改，并希望將其作為新的受信任版本，保存到Git存儲(chǔ)庫(kù)中。不過(guò)，版本控制系統(tǒng)通常不會(huì)限制您提交代碼的方式。也就是說(shuō)，您可以采取如下三種方式中的任何一種：
- 一次性提交上千個(gè)更改。
- 提交所有的dll和其他依賴(lài)項(xiàng)。
- 將有問(wèn)題的代碼檢入存儲(chǔ)庫(kù)中。
可見(jiàn)，此舉并不能保證更新代碼的一致性，有時(shí)甚至?xí)尨a的整體質(zhì)量有所下降。因此我們需要一些時(shí)間來(lái)檢查代碼(請(qǐng)參見(jiàn)-- https://dzone.com/articles/what-is-code-review-and-why-do-you-need-it)。在此，為了保障團(tuán)隊(duì)的總體生產(chǎn)力水平，我們可以采用原子性提交(請(qǐng)參見(jiàn)-- https://acompiler.com/git-commands/)，例如：在執(zhí)行原子性提交時(shí)，您的某項(xiàng)更改提交可能會(huì)涉及多個(gè)文件，那么我們應(yīng)當(dāng)確保這是全局性的寫(xiě)入，進(jìn)而避免出現(xiàn)任何不一致的情況。和我們以前熟悉的數(shù)據(jù)庫(kù)原子性一樣，我們顯然需要將其貫徹到針對(duì)Git的操作中。
2.明確地說(shuō)明提交的內(nèi)容
許多開(kāi)發(fā)人員只是一味地執(zhí)行更改，提交，以及推送等操作流程，從來(lái)不會(huì)顧及提交文件的類(lèi)型和必要性。這樣就會(huì)導(dǎo)致諸如：dll和pdf等不需要的文件類(lèi)型，被提交到了存儲(chǔ)庫(kù)中。因此，在將代碼檢入存儲(chǔ)庫(kù)之前，您可以考慮如下兩個(gè)問(wèn)題：
- 您是否確實(shí)需要檢入所有的文件?
- 它們是否為源代碼中必要的部分?
您可以簡(jiǎn)單地使用.gitignore文件(請(qǐng)參見(jiàn)-- https://acompiler.com/git-commands/)，來(lái)避免在存儲(chǔ)庫(kù)中出現(xiàn)那些不需要的文件。.gitignore文件既能夠?yàn)槲覀兲岣叽鎯?chǔ)庫(kù)的清晰度，又有助于我們保持代碼的整潔性。據(jù)此，您可以自由地提交各種代碼文件，那些.dll和.class等自動(dòng)生成的非必要文件，則會(huì)被自動(dòng)地忽略掉。如果您要同時(shí)處理多個(gè)存儲(chǔ)庫(kù)，則可以使用全局.gitignore文件，而無(wú)需反復(fù)地進(jìn)行添加或推送。
3.掌握各種Git命令
毫無(wú)疑問(wèn)，Git是一個(gè)功能強(qiáng)大、且超級(jí)實(shí)用的工具。如果您能夠像對(duì)待Linux/Unix操作系統(tǒng)那樣，熟練地掌握各種基本的git命令(請(qǐng)參見(jiàn)--https://acompiler.com/git-commands/)，那么您就能夠更有效地使用該工具，并在操作Git的過(guò)程中達(dá)到事半功倍的效果。
在使用Git時(shí)，您可能會(huì)碰到一些語(yǔ)法規(guī)則等困難，而Git提供了非常友好的聯(lián)機(jī)幫助。您可以使用“git help+命令名稱(chēng)”從git的bash中了解有關(guān)某個(gè)Git命令的更多信息。這種快捷的查找方式，幾乎含括了您可能用到的所有g(shù)it命令。
4.梳理工作流程
如果您的團(tuán)隊(duì)正在某個(gè)Git管理項(xiàng)目上協(xié)同工作，那么整個(gè)開(kāi)發(fā)團(tuán)隊(duì)必須確保并使用相同的工作流程。統(tǒng)一流程無(wú)疑會(huì)給大家?guī)?lái)如下三項(xiàng)優(yōu)勢(shì)：
- 讓開(kāi)發(fā)的整個(gè)過(guò)程更具有條理性。
- 良好的Git工作流程可始終確保分支(branches)處于整潔狀態(tài)。
- 讓團(tuán)隊(duì)的溝通更加流暢，并提高輸出代碼的整體質(zhì)量。
5.先測(cè)試后推送
我們需要在提交代碼，或?qū)⒋a推送到生成環(huán)境之前，對(duì)各項(xiàng)更改進(jìn)行充分地測(cè)試。過(guò)去，我們想方設(shè)法阻止項(xiàng)目成員將有缺陷的代碼，直接提交的本地存儲(chǔ)庫(kù)中。如今，我們同樣需要本著敏捷開(kāi)發(fā)的思想，避免那些有問(wèn)題的源代碼，給在線(xiàn)協(xié)作團(tuán)隊(duì)造成困擾。在具體實(shí)踐中，我們需要做到：
- 鼓勵(lì)整個(gè)團(tuán)隊(duì)在提交之前，針對(duì)其代碼的更改部分開(kāi)展相關(guān)的單元測(cè)試，這是從根源上避免代碼缺陷的流出。
- 如果在構(gòu)建的過(guò)程中，發(fā)現(xiàn)了任何代碼的錯(cuò)誤，應(yīng)立即終止構(gòu)建。大家可通過(guò)“會(huì)診”的方式，及時(shí)修復(fù)該錯(cuò)誤，以避免此類(lèi)錯(cuò)誤流入Git中，甚至被其他的代碼段所調(diào)用到。
6.保護(hù)主(master)分支
由于Git中的默認(rèn)分支是master，因此我們需要確保master分支上的代碼，能夠穩(wěn)定地處于生產(chǎn)環(huán)境之中。您可以通過(guò)諸如：前后鉤子(pre and post hooks)、以及公司相關(guān)策略等多種方式，來(lái)保護(hù)master分支。此外，您還可以在master分支上啟用如下防護(hù)措施：
- 確保master分支不會(huì)被意外或有意地刪除。
- 在master分支上的各種提交歷史記錄，不應(yīng)被覆蓋掉。
- 在master中，代碼不應(yīng)在未經(jīng)審查的情況下，被直接檢入。
7.分支管理
Git提供了強(qiáng)大的分支模型。您應(yīng)該將手頭的代碼保留在與主分支完全隔離的其他分支中。無(wú)論您是要添加一個(gè)新功能，還是修復(fù)一些錯(cuò)誤，亦或需要進(jìn)行重構(gòu)，都請(qǐng)首先創(chuàng)建一個(gè)新的分支。在完成了必要的更改之后，請(qǐng)審查代碼，再發(fā)出拉取請(qǐng)求，將其合并到主分支中，并保持同步。
小結(jié)
上面便是我們?cè)谑褂肎it時(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
【譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為.com】
名稱(chēng)欄目：提高GIT中代碼質(zhì)量的七點(diǎn)優(yōu)秀實(shí)踐
分享路徑：http://m.fisionsoft.com.cn/article/dpsepch.html
