版本控制之最佳實踐（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