# 版本控制的最佳實踐 ## 提交對映改動 一次提交要包括一個相關改動。例如，對于兩個錯誤的修復應該進行兩次不同的提交。精簡的提交可以讓其他的開發團隊人員更簡單地明白其改動的用義。如果其中一次提交的改動出現了問題，也可以方便地回滾到改動之前的狀態。借助暫存功能來標記相關的改動文件，Git 可以為你打造出非常精準的提交。 ## 頻繁地提交改動 經常性地提交改動可以確保不會出現特別龐大的提交，同時也可以比較精準地對應到所需要的改動上。此外，通過頻繁地提交也可以比較快速地和其他開發人員來共享你的改動。同樣也會避免在整合代碼時出現過多的合并沖突。相反的，非常龐大的提交會加大整合代碼時出現沖突的風險，解決這些沖突也會非常復雜。 ## 不要提交不完整的改動 雖然原則上來說不要提交一些還沒有完成的改動，但是對于一個非常龐大的新功能來說，也并不意味著你必須整體完成這個功能后才可以提交。恰恰相反，你必須把那些改動正確地分割成一些有意義的邏輯模塊來進行頻繁地提交。如果你僅僅是因為急著想要下班，或者是想要得到一個干凈的工作副本（比如想要切換到另一個分支上），你可以利用 Git 所提供的儲藏（Stash）功能來解決這些問題。切記不要把那些不完整的改動提交到倉庫中。 ## 提交前測試那些改動 不要理所當然地認為自己完成的改動都是正確的。所有的改動一定要通過徹底地測試才表示它真正地被完成了。盡管這些改動可能僅僅是提交到了你的本地倉庫中，只有你自己才能看到，但完整的測試同樣是非常重要的，因為這些代碼可能之后會被推送和共享到遠程給其他的開發人員。 ## 高質量的提交注釋 提交注釋的標題需要一個少于50個字符的簡短說明。在一個空白的分割行之后要對改動的細節進行一個詳細地描述。例如嘗試著回答兩個問題：出于什么原因需要進行這次修改？具體改動了些什么？為了和自動生成的提交注釋保持一致（例如 git merge 可能會自動生成提交），一定要使用現在時祈使句（例如要使用 change ，而不要使用 changed 和 changes）。 ## 版本控制不是備份系統 版本控制系統具有一個很強大的附帶功能，那就是服務器端的備份功能。但是千萬不要把 VCS 僅僅當成一個備份系統。特別需要注意的是，只能提交那些有意義的改動。VCS 不是用來備份文件用的。（請參閱 <提交對映改動>） ## 使用分支功能 分支是 Git 一個非常強大的功能，當然這不是偶然的。自始至終，Git 的宗旨就是提供一個即快速又簡單的分支功能。它是一個優秀的工具，并且可以幫助解決開發人員在日常工作中存在的代碼沖突的問題，因此分支功能應該廣泛地被運用在不同的開發主題中。比如添加新功能，修復錯誤，嘗試新的想法等等。 ## 遵循一個工作流程 Git 可以支持很多不同的工作流程：長期分支、功能分支、合并以及 rebase、git-flow 等等。選擇什么樣的開發流程要取決如下一些因素：項目開發的類型，部署模式和（可能是最重要的）開發團隊成員的個人習慣。不管怎樣，選擇什么樣的流程都需要得到所有開發成員的一致認可，并且一直遵循它。