當談到版本控制時，我主張進行許多小的、集中的提交，而不是大型的提交。
只要我還活著，我就會為地球做出微小的改變。
— 受驚的兔子
目標不只是讓承諾變小，而是讓它們集中且有目的。每次提交都應該代表對程式碼庫的一次邏輯變更。
在一天結束時，我們可能會做出相同的更改，但是小的提交可以幫助我們管理時間並確保正確完成任務，同時為未來留下有用的信息。
將大型專案分解為較小的任務。這是一種傳統的專案管理技能，是充分利用時間並取得成功成果的關鍵部分。帕金森定律表明，任務會隨著分配的時間而擴展，因此能夠識別更多、更小的任務有助於限制時間的流逝。
思考任務如何轉化為描述性提交訊息。如果任務或訊息重疊或相似，您可以合併這些任務嗎？如果不是，請找出關鍵差異以區分它們。 專業提示：如果您的提交訊息中出現「和」一詞，或需要多個句子來解釋，您的提交應該被拆分。
確保您的提交使專案處於工作狀態。雖然並不總是可行，但當多個開發人員在單一儲存庫上工作時，該指南確實很有幫助。當我們讓專案正常運作時，我們可以更頻繁地建立和合併分支並限制衝突。而且，如果您需要回滾更改，您更有可能保持應用程式正常運作。
在提交之前檢查您自己的變更以確保重點。有時我們會發現機會主義的改變或忽略了首要任務。雖然我們不想丟失這些見解和更新，但有多種方法可以隔離版本控制工具和 IDE 中的更改，以保持提交的不同。
隨著提交數量的增加，很難讓您的提交保持有意義。為了清晰和一致性，考慮採用像常規提交這樣的風格。
小型提交的好處在幾個關鍵領域變得顯而易見：
小而集中的提交更容易理解和驗證。審閱者可以單獨查看不同的提交，並專注於每個較小工作單元的相關細節。
較小的提交可以降低審查者疲勞的風險並產生更高的整體品質。
請一個程式設計師檢查 10 行程式碼，他會發現 10 個問題。讓他做500行，他會說看起來不錯。
– 吉雷‧厄齊爾
<script> // Detect dark theme var iframe = document.getElementById('tweet-306836785739210752-603'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=306836785739210752&theme=dark" } </script>
小提交可以更輕鬆地識別問題的引入位置。透過精細提交，您可以更有效地使用 git bisect 等工具來找出問題。一旦發現缺陷，小的提交可以幫助我們限制更改現有程式碼的風險和測試範圍。
每次提交都應該講述一個關於單一變更的故事。當提交量很小時，這個故事對於未來的開發者（包括你自己）來說會變得更清晰、更有意義。
隨著專案年齡的增加，提交歷史記錄可以告訴我們所採取和放棄的路徑、已解決的錯誤以及需要注意的風險。提交訊息越好、越具體，就越容易理解專案歷史。
當提交較小時，不僅會降低因重疊變更而導致合併衝突的風險，而且更容易解決較小變更的衝突。
如前所述，如果出現問題，回滾小提交的風險比嘗試撤消大塊互連更改的風險要小。
未提交的程式碼就像有未儲存的文件。一行程式碼被修改和簽入之間的時間越長，丟失該更改的機會就越大。意外刪除；覆蓋；在切換分支之前未能儲存變更；重置分支而不是檔案...我們可能會透過多種方式遺失工作。
我是像 Git 這樣的現代版本控制，分支實際上是免費的。雖然 git stash 在緊要關頭可能很有用，但它需要幾乎相同的努力來創建一個臨時分支，如果它最終有價值的話，可以將其合併到功能或維護分支中。
提交的更改可以推送到伺服器上儲存庫的分支或分支，允許其他人協作查看和處理它們，並確保您的區域設定係統不會出現單點故障，從而導致您的工作損失。
在功能分支中建立許多小提交時，可能需要在最後將它們壓縮為單一提交，最好使用拉取請求，這樣您就不會丟失在程式碼審查期間非常有用的離散歷史記錄。
我更喜歡保留歷史記錄，但這也取決於這些合併的範圍和頻率。
我們通常不需要最終體現出每一個小的變化，但是如果提交不共享一個主旨——一個單一的總體主題——那麼它們可能不應該被壓制一起。
這與清潔歷史福利有關。在工作進行時，這些單獨的訊息可能會讓程式碼審查中更容易發現錯誤或不一致之處：
refactor: JIRA-12345 - Replace guards with optional chaining refactor: JIRA-12354 - Replace logical OR with nullish coalescing
一旦工作經過驗證並準備好合併，單一壓縮的提交就可以代表它們：
refactor: JIRA-12345 - ES2020 update
如果您的分支包含許多重構提交，請在對專案進行其他工作之前考慮合併和壓縮這些提交。這使得重構能夠在更廣泛的歷史中被表示為單一提交，同時與專案工作保持分離。
這進一步將不同任務的風險隔離到單獨的歷史條目中，並鼓勵縮短分支生命週期，因此
如果您不習慣這種風格，可能需要適應，但是小的提交可以幫助提高您的程式碼品質和開發流程。
練習創建較小的提交。與幾乎所有版本控制一樣，您今天的工作回報將為您自己和其他人帶來好處，但那一天可能會比您預期的更早到來。
以上是做出小承諾的詳細內容。更多資訊請關注PHP中文網其他相關文章！
