版本控制之最佳實踐（Git版）

現如今，應該每個開發者都在使用版本控制工具了吧。然而，如果你理解版本控制的基本規則，你便能更好地發揮它的效用。在此，我們匯總了一些最佳實踐，希望你在使用Git做版本控制時能夠了然于心、得心應手。

1.  相關的改動才放一起提交

一次提交（git commit）應該只包含相關的改動。比如說，修復兩個不同的bug就應該分開來做兩次提交。提交的改動越小（或越少），其他開發者理解起來就越容易；如果改動有問題，退回去也比較方便。Git有一個暫存區域（staging area）的概念，它還允許你暫存文件的某些部分，這更便于你創建非常細粒度的提交。

2.  經常性地提交

經常提交勢必讓你每次提交的東西都很少，也有助于你只提交相關的改動。并且，你還能更頻繁地與別人共享代碼。通過這種方式，所有人在集成代碼時都會感覺更輕松，也就能避免一些不必要的沖突。相比之下，如果每次提交的東西很多、改動很大、時間間隔很長，那么在代碼合并（merge）過程中產生的沖突就很難解決了。

3.  別提交半成品

你應該只在完工之后才提交。這并不是逼你把一個大塊頭功能完整實現好之后再提交。恰恰相反！你應該把大功能的實現分解成合乎邏輯的小塊工作，并且記住要早一些、經常性地提交你的代碼。只是要切忌為了提交而提交，比如在下班離開公司之前把一些東西倉促放入倉庫中。如果你這么做只是為了從服務器抓取一份干凈的代碼（git checkout <branch>或者git pull），可以考慮使用Git的“Stash”功能。

4.  提交之前必須測試

你“認為”已經完工了，然后就可以提交了嗎？千萬要抵得住這種誘惑！你應該進行全面的測試，以確保你真的是“完工”了，并且（在你能夠識別的范圍內）沒有副作用。盡管將半成品提交到本地倉庫不傷大雅（原諒你的庸人自擾），但當你把代碼推送（git push）到服務器與別人共享時，這個問題就大了——在這之前，請務必測試你的代碼！

5.  提交時須帶上適當的描述

在描述的開頭部分，你應該簡單總結一下你所做的改動（別超過50個字）。然后，用一個空行將開頭與主體部分隔離開來。在主體部分，你應該詳細回答這些問題：為什么要做這次改動？跟以前的實現有什么不一樣？請使用祈使語氣和現在時態（比如，要使用“change”這個單詞，而不用使用 “changed”或“changes”），為的是與像git merge這樣的命令自動產生的描述保持一致。

6.  版本控制有別于備份系統

把你的文件備份到遠程的服務器上是版本控制系統的一個不錯的副作用。但是，你不應該只把版本控制當備份系統來使用。版本控制追求的是每次提交的意義（請回過去閱讀第一條：把相關的改動放在一次提交里）——你不應該填鴨式地塞入一堆毫不相干的文件。

7.  使用分支

分支是Git最強大的功能之一。這并不是偶然的——從一開始，簡單、快速創建分支的能力就是對Git的一個核心需求。使用分支能夠有效地避免不同開發工作之間的相關干擾。你應該在開發過程中廣泛使用分支，它可以用于開發新功能、修復bug、試驗新的想法……

8.  采用一致的工作流程

Git允許你采納很多種不同的工作流程：持久存在的分支、主題分支、合并或復位、Gitflow（點我！）……你到底應該選擇哪一種呢？這取決于幾個因素：你的項目，開發與部署的整體流程，還有（可能是最重要的）就是大家的個人偏好。不管你們選擇哪種工作流程，請確保團隊中的每個人都對工作流程有相同的理解并且嚴格遵循。

原文鏈接：http://www.git-tower.com/learn/version-control-best-practices.html