我想現在很少有軟體專案不透過工具進行版本控制的，今天就來聊聊透過版本控制工具（revision control system）提交變動的時機吧。這邊會以比較主流的 Git 作為版本控制工具去聊，不確定是否對其他版本控制工具的使用有所幫助。

這裡所指的提交，就是 Git 的 commit，所謂的變動就是每個提交的差異之處，所以本篇要探討的其實就是什麼時候要進行一次 commit。這個議題其實已經被許多人談過了，在寫文前也猶豫了滿久的，但還是嘗試將自己的觀點寫出來，希望不算是重造輪子。

當我們要去變動程式碼時，通常會有目的，像是是為了修復什麼錯誤、或是要識做什麼新功能，最簡的方式就是只要完成這個目的就提交一次。

但是有時候要完成一個目的，可能要變動的部分太多、或是有些順帶要做的事，比如說調整設定、重構既有的程式碼、修改既有程式碼的介面等，這時候就會建議再將一個大目的拆分成比較小的目的、或是動作，而將比較大的目的作為 Pull Request 的標題。這時候旁人就可以嘗試藉由提交的訊息來暸解妳為這個目的進行實作的脈絡，或是逐個提交檢視變動，減少一次要瀏覽大量程式碼難以聚焦的負擔。

在每個提交時，除了表示做了什麼（Do What），盡量也敘述是為了什麼而做（For What）好去銜接脈絡。比如說，為了建立 User 相關資源而建立資料庫的遷移檔和 Model、為了待會的變動，順手將這段程式碼先進行重構（這表示這份提交並沒有動到業務邏輯、原本的功能，而會在待會的提交才進行，通常我也建議這兩件事要分開提交）、為了某個議題（附上連結）而進行變動⋯⋯等等。

但有時候在實作時，總是難以這麼有條理的提交，可能是做到哪就提交到哪，離開位置提交、想耍廢滑個社交網路時提交、被打斷時提交⋯⋯各種各種。這時候會建議在給人檢視前，先 git rebase 整理好整個變動的脈絡。日後在查找變動原因或臭蟲時也比較方便追蹤。

自己寫專案久了，有時候在提交上會比較隨興，如果該專案只有自己要維護，且覺得未來不會花太多時間去檢視，頂多是當存檔點求心安，這時候提交隨興是無所謂的。但是若我們今天是要多人進行開發，能有條理地進行提交並附上相關訊息是有助於彼此同步對程式碼的認知，也能降低其他人進行 Code Review 的負擔。