本文是www.git-tower.com總結的使用git的最佳實踐，其中的大部分實踐具有普適性，可用其他版本控制工具svn，cvs等。
原文:"best practice of version control in git"
每次提交的應該是一系列有關聯的變化。例如，修復了兩個不同的bug應該分別提交兩次。提交的變化少，
其他開發者更容易理解變化的內容，出現問題更容易回滾到原來的狀態。
譯者注：假想現在有2個bug，第一次提交時第1個bug修復完畢，第2個bug修復了一半，第二次提交時2個bug修復完畢。
後來發現需要先僅修復第1個bug，因為第一次提交時包含了第1個bug的修復**與第2個bug的半成品，所以需要恢復到上次
提交狀態之外的額外努力，使用版本控制帶來的便利就大打折扣了。
經常提交可以保證提交的變化少而且相互關聯。而且，可以更快地使其他開發者看到最新的**。這樣更容易讓所有人快速
合併變化，避免發生衝突。若偶爾提交一次且**變化較大，將使衝突很難解決。
不要提交未完成的**。這並不是要求你完成某個全面、大型的功能的**後再提交，而是：按邏輯將其分解成多個部分並盡早提交。
不要為了將**儲存到伺服器上而在下班前匆忙提交，如果僅僅是為了提交今天的工作內容，嘗試使用「git stash」代替」git commit」。
不要提交你」認為」已經完成的內容。先對改變的**作詳盡的測試並確保所做的改變沒有***。雖然提交半成品僅僅需要的
是原諒自己，然而向伺服器提交測試過的**再讓其他開發者使用更重要。
先簡短地總結對檔案所做的改變，插入空行，再寫詳細內容。詳細內容應該提供了以下幾個問題的答案：
— 改變的目的？
— 改變後與上次實現的區別？
將檔案備份到伺服器上是版本控制工具帶來的副產品，但是你不應該把版本控制系統用來備份檔案。使用版本控制時，應力求
每次提交的都是相關聯的變化(見第一條)——而不是提交一堆檔案。
譯者注：版本控制的目的是易於追蹤檔案變化，方便多人協作，實現開發中的工作流(branch, merge, tag...)
分支是git最強大的特性之一——這並非偶然：git最初的核心目標就是快速簡單地建立分支。分支是幫助劃分多個開發路線的完美
工具。你應該在開發工作流中廣泛應用分支:如增加新功能，修復bug，驗證想法...
通過 git help 獲取git命令的幫助
git 官方**:
學習git資源:
譯者：
garyelephant
mail:garygaowork#gmail.com
關注軟體團隊的高效執行，團隊管理。
版本控制的分支策略及初步實踐
這幾天在網上查詢了一些資料，了解到比較常見的版本控制 分支策略有三種 不穩定主幹策略 穩定主幹策略 敏捷 發布策略。下面是對這幾種策略的摘錄 不穩定主幹策略 使用用主幹作為新功能開發主線，分支用作發布。被廣泛的應用於開源專案。比較適合諸如傳統軟體產品的開發模式，比如微軟 的office等。bug修改...
版本控制的分支策略及初步實踐
這幾天在網上查詢了一些資料，了解到比較常見的版本控制分支策略有三種 不穩定主幹策略 穩定主幹策略 敏捷發布策略。下面是對這幾種策略的摘錄 不穩定主幹策略 使用用主幹作為新功能開發主線，分支用作發布。被廣泛的應用於開源專案。比較適合諸如傳統軟體產品的開發模式，比如微軟的office等。bug修改需要在...
版本控制的分支策略及初步實踐
這幾天在網上查詢了一些資料，了解到比較常見的版本控制分支策略有三種 不穩定主幹策略 穩定主幹策略 敏捷發布策略。下面是對這幾種策略的摘錄 不穩定主幹策略 使用用主幹作為新功能開發主線，分支用作發布。被廣泛的應用於開源專案。比較適合諸如傳統軟體產品的開發模式，比如微軟的office等。bug修改需要在...