[譯] 爲什麼每次 Git Commit 要儘量小？

原文：medium.com/better-prog…

Photo by Vlad Tchompalov on Unsplash

大部分與軟件工程或程序開發有關的人都應該熟悉 Git 等版本控制系統。

一般，你會階段性的做出改變、編寫一段 commit message，而後將改變推送到倉庫中。如下是一個例子：

git add .
git commit -m "[#2313213] 修正了 tooltip 中的 XSS 安全性"
git push # 向倉庫中推送了 2 個改變過的文件
複製代碼

可是，你可能見到過包含了不少已改變文件的 commit，由於其包含了各類各樣的主題：

git commit -m "[#3313212] 修正了 tooltip 中的 XSS 安全性 + 改善了 dropdown 的可訪問性 + 爲 user-dropdown.component 增長了單元測試 + 更新依賴項" # 向倉庫中推送了 20 個改變過的文件
複製代碼

也有那種語焉不詳的 commit：

git commit -m "改了點東西" # 向倉庫中推送了 15 個改變過的文件
複製代碼

在使用了 Scrum 的敏捷環境或其它相關的敏捷方法論中，指望能快速而按期地交付用戶價值。

受合做者的影響，我也嘗試着採用其 小步提交併持續改善 的習慣。做爲同時對其背後的商業和技術感興趣的一員，這種方式引發了個人共鳴。

持續集成幫助咱們及早發現問題

在本文中，我主要將概述爲何我喜歡這種方式。咱們將看看在軟件項目中小步提交的優點。

小步提交併持續改善的優點

• 儘早地從工具（如一臺 CI 服務器上的單元測試）和其它人（開發者、測試人員、產品經理）那裏獲得反饋，既有利於持續改善，又能避免將來大的改動
• 當對一個 pull request 進行代碼審查時，小的提交易於理解
• 有助於寫出更好的 commit message。因爲比起大的提交，小步提交更聚焦、範圍更窄，因此一般更容易總結其目的
• 改善你的工做績效（別當真）

也並不是總要小步提交：

• 把代碼改動過多地分散到小的 commit 中實際上也難以審查。若是分別在 12 個文件中重命名了一個變量，你可不能建立 12 次單獨的 commit。這些改變是一回事，應該統一 commit。
• 若是小的 commit 過多，雖然其自己易於理解，但極可能就會由於數量太多而累積成爲一個大的 pull request，這樣仍是難以審查。所以，應該避免形成會拖延太久的分支，這與持續改善的想法背道而馳

總結

如你所見，在軟件項目中 commit 儘量小有不少好處，也會有些問題。我認爲，把握住最重要的方面，也就是儘快取得反饋且易於審查就夠了。

--End--

查看更多前端好文
請搜索 fewelife 關注公衆號

轉載請註明出處