高效的代碼提交：避免未來問題的最佳實(shí)踐

糟糕的代碼提交會(huì)帶來巨大的麻煩。你是否曾苦苦追尋某個(gè)特定更改的意圖，或是當(dāng)前代碼的狀態(tài)？正確的代碼提交方式能有效避免這些難題。本文將深入探討軟件提交的最佳實(shí)踐。

核心要點(diǎn)

• 正確的代碼提交能防止混淆，節(jié)省未來時(shí)間。提交應(yīng)具有原子性，一次只處理一個(gè)特定問題，而不是臃腫地影響大量文件並添加多個(gè)功能。
• 良好的提交應(yīng)清晰、有見地且具有原子性。提交結(jié)構(gòu)應(yīng)包含類型或組件、清晰的主題以及可選的正文以提供更多上下文或細(xì)節(jié)。
• 應(yīng)在提交信息中處理問題，使用關(guān)鍵詞和問題 ID 號(hào)。這便於跟蹤項(xiàng)目中的任務(wù)、改進(jìn)和錯(cuò)誤。
• 無論團(tuán)隊(duì)規(guī)模大小，正確的代碼提交對(duì)良好的項(xiàng)目管理至關(guān)重要。它維護(hù)了代碼庫的完整性，使其他開發(fā)人員更容易理解和處理代碼。

為什麼要費(fèi)心？

如果你已經(jīng)將項(xiàng)目存儲(chǔ)在 GitHub 上，你可能會(huì)認(rèn)為文件是安全的，無論何時(shí)需要更新代碼，你都可以提取更改，這就足夠了。所有這些都可能是真的。但是，讓我們看看通過付出更多努力可以避免哪些潛在問題，以及如果你這樣做會(huì)獲得哪些額外的好處。

團(tuán)隊(duì)合作或個(gè)人工作都應(yīng)避免單打獨(dú)鬥

上述理由通常來自習(xí)慣於獨(dú)自工作的開發(fā)人員。但當(dāng)他們需要與其他人共享代碼時(shí)，事情就會(huì)變得混亂，需要大量的解釋。記住，我們的工作不僅僅是編寫代碼。我們還需要管理事情，這需要一定程度的組織性和方法論。雖然團(tuán)隊(duì)合作更容易暴露由組織不善造成的問題，但我們也可以從更好的方法中受益，即使是獨(dú)自工作時(shí)也是如此。

原子提交與臃腫提交

我們都需要撤銷一個(gè)小小的更改，卻發(fā)現(xiàn)自己在一個(gè)巨大的提交中搜索它，這個(gè)提交更改了數(shù)十個(gè)文件並添加了多個(gè)功能。如果該更改位於僅處理該特定問題的單個(gè)提交中，那麼回滾將容易得多。

混亂的、臃腫的方式

<code>git add *
git commit -m "new components"</code>

在這個(gè)例子中，我們可以肯定有很多文件受到了影響。此外，“new components”這個(gè)信息並沒有告訴我們太多信息——例如哪些組件、這些組件的哪些功能，以及功能是新的還是重構(gòu)。此外，是否解決了任何現(xiàn)有的錯(cuò)誤？

當(dāng)我們需要更改或恢復(fù)某些內(nèi)容時(shí)，這些信息將非常重要。我們將試圖在一堆乾草中找到一根針，我們最終可能會(huì)查看代碼庫，並在調(diào)試時(shí)花費(fèi)寶貴的時(shí)間。

原子方式

<code>git add *
git commit -m "new components"</code>

現(xiàn)在我們開始有所了解了，因?yàn)槲覀冮_始更清楚地了解那個(gè)提交發(fā)生了什麼。

訣竅是，我們可以將更改作為工作流程的一部分半自動(dòng)提交。也就是說，執(zhí)行一個(gè)執(zhí)行非常具體操作的工作塊(實(shí)現(xiàn)特定功能、修復(fù)錯(cuò)誤、優(yōu)化算法)，進(jìn)行測(cè)試(如果需要，編寫單元測(cè)試)，在記憶新鮮時(shí)添加描述，然後立即提交。重複此過程。

良好提交的結(jié)構(gòu)

這些規(guī)則並非一成不變，但可以幫助你評(píng)估良好的提交可能是什麼樣子：

• 清晰：對(duì)提交更改所做的工作沒有疑問。
• 有見地：清楚地描述代碼的功能，必要時(shí)提供鏈接或額外信息，並標(biāo)記正在處理的錯(cuò)誤或問題。
• 原子性：一次只處理一件事情(考慮一個(gè)“工作塊”，可以是 20 分鐘到 2 小時(shí)，如果是一個(gè)快速的錯(cuò)誤修復(fù)，甚至可以是 2 分鐘)。

讓我們來看一個(gè)模板並將其分解：

<code>git add ui/login.html static/js/front-end.js
git commit -m "validate input fields for login"</code>

類型、組件或子系統(tǒng)

這將是一組可以組合在一起的軟件項(xiàng)目功能。例如，AngularJS 中所謂的類型，或 SrummVM 中所謂的子系統(tǒng)。

（必填）主題

主題是一行簡(jiǎn)單直接的描述，說明提交所做的工作，以便每個(gè)人都能一目了然。

在主題格式方面，我通常遵循以下簡(jiǎn)單準(zhǔn)則：

1. 使用祈使句(“change”而不是“changed”)
2. 不要大寫第一個(gè)字母
3. 末尾不要加句點(diǎn)(.)
4. 如果有可選正文，則附加“(…)”

（可選）正文

有時(shí)，我們需要提供比主題行中適合的更多細(xì)節(jié)來提供上下文，例如修復(fù)持續(xù)存在的錯(cuò)誤時(shí)，或破解算法時(shí)。

在這些情況下，你可以簡(jiǎn)單地輸入雙換行符(以便主題用作標(biāo)題)，然後輸入所需的信息。

不要忘記處理問題！

最後，還有一個(gè)處理問題的問題(雙關(guān)語！)。任何體面的中大型軟件開發(fā)項(xiàng)目都應(yīng)該使用問題跟蹤器來跟蹤任務(wù)、改進(jìn)和錯(cuò)誤——無論是 Atlassian Jira、Bugzilla、GitHub 的問題跟蹤器還是其他。

問題管理

如果你不知道，大多數(shù)係統(tǒng)都可以直接從提交信息中管理問題！

你可以：

• 關(guān)閉/解決問題
• 如果問題之前已關(guān)閉，則重新打開問題
• 如果功能被推遲到以後，則保留問題

只需要使用這些關(guān)鍵詞和問題的 ID 號(hào)即可。

此外，你仍然可以引用問題作為提供上下文的方式，即使你不想修改其狀態(tài)——例如，“參見 #12”。

所有這些引用都將對(duì)在跟蹤器上打開該問題的任何人可見，這使得跟蹤給定任務(wù)或錯(cuò)誤的進(jìn)度變得容易。

總結(jié)

你不會(huì)總是做得對(duì)(我個(gè)人也不是！)。事情會(huì)變得混亂，有時(shí)你不會(huì)遵循你為自己或你的團(tuán)隊(duì)設(shè)定的規(guī)則——這是流程的一部分。但希望你知道，只需對(duì)你的工作流程進(jìn)行一些升級(jí)，你就可以做到井井有條，從長(zhǎng)遠(yuǎn)來看，為你和你的團(tuán)隊(duì)節(jié)省時(shí)間。

我還從經(jīng)驗(yàn)中得知，項(xiàng)目涉及十名開發(fā)人員還是完全由你處理，這幾乎沒有什麼區(qū)別。簡(jiǎn)而言之，以正確的方式提交代碼更改——這是良好項(xiàng)目管理的關(guān)鍵部分。

進(jìn)一步閱讀

• 使用 Git 歷史記錄講述故事。 Seb Jabocs 在 FutureLearn 上的一篇有趣的文章。
• Angular 的提交信息指南。即使你不使用 Angular，這也是一篇有益的閱讀材料。
• FreeBSD 提交者指南。如果有一個(gè)的話，這是一個(gè)關(guān)於該主題的深入指南。
• 如何正確組織代碼庫中的文件並避免混亂。我們解釋瞭如何為大型和小型項(xiàng)目組織文件，提供一些易於遵循的最佳實(shí)踐。
• 快速入門 Git。本簡(jiǎn)明指南旨在幫助初學(xué)者在一個(gè)週末內(nèi)快速掌握 Git。
• 專業(yè) Git。 Wiley 的這本書更進(jìn)一步，為開發(fā)人員提供了他們需要成為 Git 大師的深入研究。

關(guān)於代碼庫和提交更改的常見問題解答 (FAQ)

• 代碼庫和源代碼有什麼區(qū)別？

代碼庫是指用於構(gòu)建特定軟件或應(yīng)用程序的整個(gè)源代碼集合。它包括所有版本的代碼和分支。另一方面，源代碼是當(dāng)前正在處理的代碼庫的一部分。它是用編程語言編寫的代碼，然後編譯成可執(zhí)行程序。

• 代碼庫中的提交更改是如何工作的？

在代碼庫中提交更改涉及更改源代碼，然後將這些更改保存到代碼庫。此過程通常在像 Git 這樣的版本控制系統(tǒng)中完成。當(dāng)你提交更改時(shí)，你實(shí)際上是在那個(gè)時(shí)間點(diǎn)拍攝你的工作快照。這允許你跟蹤你所做的更改，並在必要時(shí)恢復(fù)到以前的版本。

• 以正確的方式提交更改的重要性是什麼？

以正確的方式提交更改對(duì)於維護(hù)代碼庫的完整性至關(guān)重要。它確保代碼庫保持乾淨(jìng)和易於管理，使其他開發(fā)人員更容易理解和處理代碼。它還有助於跟蹤更改並識(shí)別何時(shí)以及在何處將錯(cuò)誤引入代碼。

• 提交更改的一些最佳實(shí)踐是什麼？

提交更改的一些最佳實(shí)踐包括進(jìn)行小的、增量的提交，編寫清晰且描述性的提交信息，以及在提交之前測(cè)試你的更改。定期將你的本地代碼庫與主代碼庫同步也很重要，以避免衝突。

• 什麼是版本控制系統(tǒng)，它與代碼庫有什麼關(guān)係？

版本控制系統(tǒng)是一種幫助管理代碼庫更改的工具。它在一個(gè)特殊類型的數(shù)據(jù)庫中跟蹤對(duì)代碼的每一次修改。如果出現(xiàn)錯(cuò)誤，開發(fā)人員可以倒回時(shí)間並比較代碼的早期版本，以幫助修復(fù)錯(cuò)誤，同時(shí)最大限度地減少對(duì)所有團(tuán)隊(duì)成員的影響。

• 如何避免提交更改時(shí)發(fā)生衝突？

可以通過定期將你的本地代碼庫與主代碼庫同步來避免衝突。這確保你始終在處理代碼的最新版本。與你的團(tuán)隊(duì)溝通也很重要，確保每個(gè)人都知道正在進(jìn)行的更改。

• 代碼庫在軟件開發(fā)中的作用是什麼？

代碼庫在軟件開發(fā)中起著至關(guān)重要的作用。它作為所有源代碼的中央存儲(chǔ)庫，允許開發(fā)人員協(xié)同工作並同時(shí)處理軟件的不同部分。它還有助於跟蹤更改並維護(hù)項(xiàng)目的歷史記錄。

• 代碼庫和代碼存儲(chǔ)庫有什麼區(qū)別？

代碼庫是指軟件的整個(gè)源代碼集合，而代碼存儲(chǔ)庫是存儲(chǔ)和管理此代碼的地方。代碼存儲(chǔ)庫可以包含多個(gè)代碼庫，通常由版本控制系統(tǒng)管理。

• 如何確保我的提交有意義且有用？

為了確保你的提交有意義且有用，重要的是要進(jìn)行小的、增量的提交，每個(gè)提交都有其特定的目的。每個(gè)提交都應(yīng)該代表一個(gè)單一的邏輯更改。編寫清晰且描述性的提交信息也很重要，這些信息解釋了所做的更改以及原因。

• 代碼庫和構(gòu)建之間的關(guān)係是什麼？

構(gòu)建是將代碼庫中的源代碼轉(zhuǎn)換為可執(zhí)行程序的過程。代碼庫作為構(gòu)建過程的輸入，輸出是可以安裝並在計(jì)算機(jī)上運(yùn)行的軟件產(chǎn)品。構(gòu)建過程可以包括編譯代碼、鏈接庫以及打包軟件以進(jìn)行分發(fā)。

以上是以正確的方式對(duì)您的代碼庫進(jìn)行更改的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！