提交要對應(yīng)修改
一次提交應(yīng)該對應(yīng)一個(gè)相關(guān)的改動它抱。例如：兩個(gè)不同的錯(cuò)誤應(yīng)該對應(yīng)兩次不同的提交，使它更容易讓其他開發(fā)人員明白這個(gè)改動朴艰，如果這次改動存在問題观蓄，也可以方便的回滾到改動之前的狀態(tài)。通過暫存區(qū)標(biāo)記功能祠墅，Git可以輕松打造非常精確的提交侮穿。
經(jīng)常的提交修改
經(jīng)常的提交改動可以更方便地為它做注釋，從而更容易確保提交的注釋和改動的一致性毁嗦。通過頻繁的提交來與其他的開發(fā)人員共享這些改動亲茅，那樣就會避免或減少代碼整合時(shí)帶來的沖突。反之狗准，非常龐大的提交將會增大整合時(shí)出現(xiàn)沖突的風(fēng)險(xiǎn)克锣。
不要提交不完整的改動
對于一個(gè)很大的功能模塊來說，完成后在提交并不意味這必須整體完成后才可以腔长，而是要把它正確分割成小的完整的邏輯模塊進(jìn)行經(jīng)常性的提交袭祟。一定不要提交一些不完整的改動，僅僅是因?yàn)橄掳唷?br> 同樣捞附，如果只是為了得到一個(gè)干凈的工作區(qū)域也不需要立刻提交榕酒∨卟玻可以通過Git的Stash命令把這些改動移到另外的分支。
提交前進(jìn)行代碼測試
不要提交還沒有經(jīng)過完整測試的改動想鹰。只有經(jīng)過測試紊婉，并確定無誤的改動才能提交。把改動發(fā)送給開發(fā)團(tuán)隊(duì)其他成員前辑舷，必須確定所有修改已經(jīng)完整測試過喻犁。這樣才算真正的完成。
高質(zhì)量的提交注釋
提交注釋的開頭需要一個(gè)少于50個(gè)字的簡短說明何缓。在一個(gè)空白分割行之后要寫出一個(gè)詳細(xì)的提交細(xì)節(jié)肢础。比如回答如下的兩個(gè)問題：
- 出于什么理由需要這個(gè)修改
- 基于當(dāng)前版本，具體改動啦什么
為了和自動生成的注釋保持一致（例如：git merge),一定要是用現(xiàn)在時(shí)態(tài)祈使句（比如使用change 而不是changed 或 changes）.
版本控制不是備份
版本控制系統(tǒng)具有一個(gè)很強(qiáng)大的附帶功能碌廓，那就是服務(wù)器端的備份功能传轰。但是不要把VCS當(dāng)成一個(gè)備份系統(tǒng)，一定要注意谷婆。只需要提交哪些有意義的改動慨蛙。而不要僅僅作為文件存儲系統(tǒng)來使用。
使用分支功能
自始至終纪挎，Git 的核心就是提供一個(gè)快速期贫，簡單和靈活的分支功能。分支是一個(gè)非常優(yōu)秀的工具异袄，用來幫助開發(fā)人員解決在日常團(tuán)隊(duì)開發(fā)中存在的代碼沖突的問題通砍。因此分支功能應(yīng)該廣泛的運(yùn)用在不同的開發(fā)流程中。比如：開發(fā)新的功能烤蜕，bug fix等等封孙。
合理的工作流程
Git 可以支持很多不同流程：長期分支，特性分支讽营，合并或重置敛瓷， git-flow等等，選擇哪一種流程要取決于如下一些因素：什么項(xiàng)目斑匪，什么樣的開發(fā)，部署模式和團(tuán)隊(duì)人員的個(gè)人習(xí)慣锋勺。不管怎樣蚀瘸，選擇什么樣的流程都要得到所用開發(fā)人員的認(rèn)同并且一直遵守他。
使用幫助文檔
顯示給定git指令的幫助文檔
$ git help <command>
開發(fā)的在線資源
http://www.git-tower.com/learn
http://www.rogerdudler.github.io/git-guide/
http://www.git-scm.org/
