版本控制的極佳實踐

            本文是www.git-tower.com總結的使用Git的最佳實務，其中的大部分實踐具有普適性，可用其他版本控制工具SVN，CVS等。　　

            原文:http://www.git-tower.com/files/cheatsheet/Git_Cheat_Sheet_grey.pdf

                 "Best Practice of Version Control in Git"

          1. 提交相互關聯的變化(Commit Related Changes)

         每次提交的應該是一系列有關聯的變化。例如，修複了兩個不同的bug應該分別提交兩次。提交的變化少，

其他開發人員更容易理解變化的內容，出現問題更容易復原到原來的狀態。　　

        譯者註：假想現在有2個bug，第一次提交時第1個bug修複完畢，第2個bug修複了一半，第二次提交時2個bug修複完畢。

後來發現需要先僅修複第1個bug，因為第一次提交時包含了第1個bug的修複代碼與第2個bug的半成品，所以需要恢複到上次

提交狀態之外的額外努力，使用版本控制帶來的便利就大打折扣了。

          2.經常提交(Commit Often)        

         經常提交可以保證提交的變化少而且相互關聯。而且，可以更快地使其他開發人員看到最新的代碼。這樣更容易讓所有人快速

合并變化，避免發生衝突。若偶爾提交一次且代碼變化較大，將使衝突很難解決。

          3.不要提交半成品(Don’t Commit Half-done Work)

        

         不要提交未完成的代碼。這並不是要求你完成某個全面、大型的功能的代碼後再提交，而是：按邏輯將其分解成多個部分並儘早提交。

         不要為了將代碼儲存到伺服器上而在下班前匆忙提交，如果僅僅是為了提交今天的工作內容，嘗試使用“git stash”代替”git commit”。

          4.提交之前先測試(Test Code Before You Commit)

         不要提交你”認為”已經完成的內容。先對改變的代碼作詳盡的測試並確保所做的改變沒有副作用。雖然提交半成品僅僅需要的

是原諒自己，然而向伺服器提交測試過的代碼再讓其他開發人員使用更重要。

          5.寫有用的提交記錄(Write Good Commit Message)

         先簡短地總結對檔案所做的改變，插入空行，再寫詳細內容。詳細內容應該提供了以下幾個問題的答案：

                  — 改變的目的？

                  — 改變後與上次實現的區別？

          6.版本控制不是檔案備份(Version Control Is Not A Backup System)

         將檔案備份到伺服器上是版本控制工具帶來的副產品，但是你不應該把版本控制系統用來備份檔案。使用版本控制時，應力求

每次提交的都是相關聯的變化(見第一條)——而不是提交一堆檔案。

         譯者註：版本控制的目的是易於追蹤檔案變化，方便多人協作，實現開發中的工作流程(branch, merge, tag...)

          7.使用分支(Use Branches)

          分支是Git最強大的特性之一——這並非偶然：Git最初的核心目標就是快速簡單地建立分支。分支是協助劃分多個開發路線的完美

工具。你應該在開發工作流程中廣泛套用分支:如增加新功能，修複bug，驗證想法...

             

          8.尋求協助(Help & Documentation)

          通過 git help <command>擷取git命令的協助　　

          Git 官方網站: 

http://www.git-scm.com　　

          學習Git資源:

                                 http://progit.org　　

                                 http://book.git-scm.org　　

                                 http://gitref.org

 轉載本文請註明作者和出處[Gary的影響力]http://garyelephant.me，請勿用於任何商業用途！

Author: Gary Gao( garygaowork[at]gmail.com) 關注互連網、分布式、高效能、NoSQL、自動化、軟體團隊