##一。只打包提交有關聯的變更（COMMIT RELATED CHANGES）
commit 應該是對相關變更的打包，比如修復兩個不同的 bug 應該是兩個獨立的 commit，這樣更細緻的 commit 能讓其他開發者更容易理解變更並在出錯的時候輕鬆回滾。Git 中的暫存區和暫存能力其實只是某個檔案的一部分，所以很容易就能建立粒度很細的 commit。
##二。經常提交（COMMIT OFTEN）
經常提交能保證每個 commit 足夠細緻，而且有助於保證只打包提交有關聯的變更。更重要的是，還允許你經常和別人共享程式碼。這樣每個人都能更輕鬆地週期性地整合變更，避免 merge 衝突，相反地，如果只有幾個重大 commit 還很少共享，就很難處理 merge 衝突。
##三。不要提交沒幹完的活兒（DON'T COMMIT HALF-DONE WORK）
應該只 commit 成品程式碼，並不是要求 commit 前必須要做完整個大功能模組，恰恰相反，把整個功能模組的實現分割成邏輯塊並記得經常儘早 commit 就好了，切記不要在每天下班前都習慣性的 commit 一下。如果想 commit 只是因為需要一個乾淨的工作區（為了檢查某個分支，或者是想拉取變更等等），那可以考慮用 Git 的 stash 命令而不是 commit。
##四。提交之前先測試（TEST CODE BEFORE YOU COMMIT）
不要自己覺得幹完了就急著 commit，應該徹底測試一遍確保真的幹完了而且沒有（你所知道的）副作用。把半成品 commit 到本地版本庫裡只會給自己帶來麻煩，而要 push 或者共享程式碼給別人時，保證程式碼被測試過是非常重要的。
##五。認真填寫提交資訊（WRITE GOOD COMMIT MESSAGES）
commit 資訊應該以對所做變更的簡短（建議不超過 50 個字元）總結開頭，然後用空行把總結和下面的資訊主體分開，資訊主體應該詳細解釋以下問題：
-
這次變更的原因是什麼？
-
和之前的實現有什麼區別？
和 git 原生資訊保持一致，例如 git merge，應該用祈使句、一般現在時描述，不要用過去時態和單數第三人稱形式。
##六。版本控制系統不是個備份系統（VERSION CONTROL IS NOT A BACKUP SYSTEM）
把檔案備份在遠端伺服器上對版本控制系統來說是個極大的副作用，但不應該把 VCS（版本控制系統）當備份系統來用，用 CVS 的時候，應該更多地注意 commit 的語義（詳見 只打包提交有關聯的變更），不要只是單純地塞滿檔案。
##七。多用分支（USE BRANCHES）
分支其實才是 Git 最強大的功能，這並非偶然：快捷的分支操作從一開始就是核心需求。分支是避免開發過程中各項工作相互混淆的完美工具，應該在開發工作流程中廣泛使用分支：添新功能，改 bug，試新想法……
##八。對工作流程達成一致（AGREE ON A WORKFLOW）
Git 支援各種工作流程：long-running branches、Topic branches、merge 或 rebase、git 流（git-flow）……到底選擇哪一個取決於很多因素：具體專案、整體開發以及開發工作流程和（或許最重要的是）團隊成員的偏好。無論選哪個，只要確保每個人都對工作流程達成一致就好。
##九。幫助文件（HELP & DOCUMENTATION）
可以方便地獲取命令列幫助：git help
##十。免費線上資源（FREE ONLINE RESOURCES）
-
Git Tower：http://www.git-tower.com/learn
-
Github 簡明指南：http://rogerdudler.github.io/git-guide/
-
Git 官網：http://www.git-scm.org/
-
《Pro Git》：百度網盤，500+ 頁的 PDF，需要用高端功能的話可以翻書
###參考資料
暫無評論，快來發表你的看法吧