以正確的方式對您的代碼庫進行更改

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

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

核心要點

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

為什麼要費心？

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

團隊合作或個人工作都應避免單打獨鬥

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

原子提交與臃腫提交

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

混亂的、臃腫的方式

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

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

當我們需要更改或恢復某些內容時，這些信息將非常重要。我們將試圖在一堆乾草中找到一根針，我們最終可能會查看代碼庫，並在調試時花費寶貴的時間。

原子方式

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

現在我們開始有所了解了，因為我們開始更清楚地了解那個提交發生了什麼。

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

良好提交的結構

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

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

讓我們來看一個模板並將其分解：

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

類型、組件或子系統

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

（必填）主題

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

在主題格式方面，我通常遵循以下簡單準則：

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

（可選）正文

有時，我們需要提供比主題行中適合的更多細節來提供上下文，例如修復持續存在的錯誤時，或破解算法時。

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

不要忘記處理問題！

最後，還有一個處理問題的問題(雙關語！)。任何體面的中大型軟件開發項目都應該使用問題跟踪器來跟踪任務、改進和錯誤——無論是 Atlassian Jira、Bugzilla、GitHub 的問題跟踪器還是其他。

問題管理

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

你可以：

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

只需要使用這些關鍵詞和問題的 ID 號即可。

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

所有這些引用都將對在跟踪器上打開該問題的任何人可見，這使得跟踪給定任務或錯誤的進度變得容易。

總結

你不會總是做得對(我個人也不是！)。事情會變得混亂，有時你不會遵循你為自己或你的團隊設定的規則——這是流程的一部分。但希望你知道，只需對你的工作流程進行一些升級，你就可以做到井井有條，從長遠來看，為你和你的團隊節省時間。

我還從經驗中得知，項目涉及十名開發人員還是完全由你處理，這幾乎沒有什麼區別。簡而言之，以正確的方式提交代碼更改——這是良好項目管理的關鍵部分。

進一步閱讀

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

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

• 代碼庫和源代碼有什麼區別？

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

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

在代碼庫中提交更改涉及更改源代碼，然後將這些更改保存到代碼庫。此過程通常在像 Git 這樣的版本控制系統中完成。當你提交更改時，你實際上是在那個時間點拍攝你的工作快照。這允許你跟踪你所做的更改，並在必要時恢復到以前的版本。

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

以正確的方式提交更改對於維護代碼庫的完整性至關重要。它確保代碼庫保持乾淨和易於管理，使其他開發人員更容易理解和處理代碼。它還有助於跟踪更改並識別何時以及在何處將錯誤引入代碼。

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

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

• 什麼是版本控制系統，它與代碼庫有什麼關係？

版本控制系統是一種幫助管理代碼庫更改的工具。它在一個特殊類型的數據庫中跟踪對代碼的每一次修改。如果出現錯誤，開發人員可以倒回時間並比較代碼的早期版本，以幫助修復錯誤，同時最大限度地減少對所有團隊成員的影響。

• 如何避免提交更改時發生衝突？

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

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

代碼庫在軟件開發中起著至關重要的作用。它作為所有源代碼的中央存儲庫，允許開發人員協同工作並同時處理軟件的不同部分。它還有助於跟踪更改並維護項目的歷史記錄。

• 代碼庫和代碼存儲庫有什麼區別？

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

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

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

• 代碼庫和構建之間的關係是什麼？

構建是將代碼庫中的源代碼轉換為可執行程序的過程。代碼庫作為構建過程的輸入，輸出是可以安裝並在計算機上運行的軟件產品。構建過程可以包括編譯代碼、鏈接庫以及打包軟件以進行分發。

以上是以正確的方式對您的代碼庫進行更改的詳細內容。更多資訊請關注PHP中文網其他相關文章！