1.3 代碼管理工具：Git

曾幾何時，你有沒有遇到過這種情況：你正在開發一個51單片機項目，昨天的代碼運行得還好好的，今天早上起來，吃了兩個包子后，突然靈感乍現，文思泉涌，添加了一些代碼，修改了一些參數，重新編譯運行，發現硬件不工作了！尤其是和硬件時序、通信協議相關的，很容易遇到這種情況。于是你又想把今天修改的東西改回去，但是改來改去，因為修改的地方太多，你甚至都忘記了到底修改了哪些地方！

吃一塹長一智，在一個坑里跌倒過，下次你肯定不會這么干了。于是你開始步步為營、穩扎穩打：在軟件開發過程中，每實現一個功能，每前進一步，都趕緊存檔備份，保存為一個版本，然后以這個版本為基點進行下一個版本的開發。客戶不停地提需求，改需求，你就不停地備份版本，這就像你在那傷感的6月里寫畢業論文一樣，你不停地改論文，導師不停地打回來，到最后就變成了圖1-2的樣子。

不同版本的論文之間到底修改了哪些東西？時間久了，記憶如潮水般退去，可能也就慢慢忘記了。有沒有更好的方法去記錄這些詳細的變化呢？答案是有的，我們可以使用版本控制系統來記錄每一次的修改和變化。

1.3.1 什么是版本控制系統

版本控制系統就和各大銀行柜臺的會計一樣，每個客戶存入、取出的每一筆錢都記錄在賬，都有詳細記錄可查：時間、地點、人物、存取的現金數額，都一一記錄在案。版本控制系統也有類似的功能，它會跟蹤并記錄一個項目中每一個文件的變化：誰創建了它，誰修改了它，又是誰刪除了它，是什么時候，修改了什么內容，都一一記錄在案。自從有了版本控制系統，工程師之間互相推卸責任的機會大大減少了：你修改了什么，都有詳細的記錄在案，都保存在版本庫中，鐵證如山，隨便翻一翻就可以查得到。

版本控制系統一般分為集中式版本控制系統和分布式版本控制系統，如圖1-3所示。顧名思義，集中式版本控制系統就是軟件的各個版本快照只保存在服務器上，服務器中包含各個版本的軟件代碼。用戶如果想要觀看某個版本的代碼，首先要從版本庫中將該版本的代碼拉取到本地的計算機上，然后才能查看和修改，最后將自己的修改保存到服務器上。集中式版本控制系統的一個缺點就是數據存儲在服務器上，使用時要聯網，如果哪一天斷網了，就不能工作了，員工就可以提前下班了。如果哪一天某個加班的員工受了委屈，為泄私憤，直接登錄服務器刪庫跑路，如果數據沒有備份，那么問題就嚴重了，基本上就很難恢復了。除此之外，集中式版本控制系統一般都是收費的，所以現在遠遠沒有免費的分布式版本控制系統受歡迎。

顧名思義，分布式版本控制系統就是不再將整個版本庫保存在一個服務器上，而是保存在每個員工的計算機中。這樣做的好處是：即使服務器崩潰了，或者離職的員工刪除了服務器的代碼，只要數據在任何一個員工的計算機中有備份，都可以直接恢復，因為每個計算機保存的版本庫數據都是一樣的。自從有了分布式版本控制系統，老板再也不怕員工刪庫跑路了！集中式和分布式版本控制系統典型的代表就是小烏龜和Git，如圖1-4所示。

早期使用TortoiseSVN的比較多，自從Linux內核的作者Linus開發出Git這款免費的版本控制工具后，Git變得越來越流行，原先使用TortoiseSVN的軟件項目也開始逐漸轉向Git。Git逐漸成為軟件工程師的一個標配技能，越來越多的公司開始使用Git來管理軟件項目，你不會使用Git拉取和提交代碼，就無法融入團隊參與開發。

1.3.2 Git的安裝和配置

安裝Git非常簡單，以Ubuntu為例，在聯網環境下，直接使用下面的命令即可完成安裝。

Git安裝好之后，還不能立即使用，在使用之前還需要做一些配置，如你提交代碼時的一些信息：提交人是誰？提交人的郵箱是多少？如何聯系？這些信息是必須要有的，當別人看到你的修改，想和你聯系時，可以通過這些配置信息找到你。

Git可以通過不同的參數，靈活設置這些配置的作用范圍。

● --global：配置～/.gitconfig文件，對當前用戶下的所有倉庫有效。

● --system：配置/etc/gitconfig文件，對當前系統下的所有用戶有效。

● 無參數：配置.git/config文件，只對當前倉庫有效。

1.3.3 Git常用命令

配置完畢后，我們就可以使用Git命令來管理我們的軟件代碼了，常用的Git命令如下。

● git init：創建一個本地版本倉庫。

● git add main.c：將main.c文件的修改變化保存到倉庫的暫存區。

● git commit：將保存到暫存區的修改提交到本地倉庫。

● git log：查看提交歷史。

● git show commit_id：根據提交的ID查看某一個提交的詳細信息。

學習Git，首先要明白幾個重要的基本概念：工作區（Working Directory）、暫存區（Staging Area）和版本庫（Repository）。版本庫里保存的是我們提交的多個版本的代碼快照，如果你想查看某個版本的代碼，可以通過git checkout命令將版本庫里這個版本的代碼拉取出來，釋放到工作區。在工作區，你可以瀏覽某一個版本的代碼、修改代碼。如果你想把你的修改保存到版本庫中，可以先將你的修改保存到暫存區，接著修改，再保存到暫存區，直到真正完成修改，再統一將暫存區里所有的修改提交到版本庫中，如圖1-5所示。

這個時候你可能就犯嘀咕了：為什么還需要一個暫存區呢？將工作區的修改直接提交（Commit），保存到版本庫中豈不是更方便？其實，筆者也曾思考過這個問題，個人理解是：對于一個版本庫來說，你的任何一個提交，包括修改、添加文件、刪除文件等操作都會有一個記錄，而在實際工作中，對于一個工程師來說，在開發一個功能時，可能會分成很多步，如果每一小步都去提交一次，意義不是很大，而且不是一個完整的功能，別人可能就搞不懂你的提交到底實現了什么功能。如有一個提交：將大象放到冰箱里，別人一看可能就知道是怎么回事。但在實際的開發過程中，我們可能分步開發。

● 打開冰箱門。

● 把大象放到冰箱里。

● 關上冰箱門。

如果將每次很小的修改都做一次提交，就不是很合適，從原則上講，我們的每一次提交，都是一個里程碑：要么新增了一個功能，要么修改了一個Bug，要么優化了一個功能。在實際開發中的每一小步，都可以先保存到暫存區，等整體功能完成后，再統一提交比較合理。

講了這么多，為了讓大家更快地上手Git，還是給大家演示一遍。首先我們新建一個目錄tmp，在tmp目錄下新建一個C源文件main.c。

然后在tmp目錄下新建一個Git倉庫，并將main.c提交到倉庫中。

在上面的操作步驟中，每執行一步，我們都可以使用git status命令來查看文件的狀態，你會發現每一步操作后，main.c的文件狀態都會發生變化：從untracked到changes to be commited，工作區的狀態也會跟著變化。提交成功后，我們可以使用git log來查看提交信息，包括提交的ID、提交作者、提交時間、提交信息說明等。

如果提交后你又修改了main.c文件，想把這個修改再次提交到倉庫，可以使用下面的命令。

通過上面的命令，我們可以將main.c的第二次修改提交到本地倉庫，然后使用git log或者git show命令來查看我們新的提交信息和修改變化。其中git show后面的一串數字字符串是每一次提交的commit ID。

如果你想讓你的提交不影響整個項目，不影響其他人使用，則可以創建一個自己的分支my_branch，切換到my_brancn分支上，然后在這個分支上修改代碼就可以了。提交時再將你的修改用上面的方法提交到my_branch分支上。通過這種操作，你的所有修改都提交到你自己創建的分支my_branch上，而不會影響master主分支上的代碼，不會影響其他人。

掌握上面的常用命令，我們就可以使用Git進行代碼的修改、提交了。除了上面的常用命令，Git還有很多其他更好用的命令，如分支管理、分支的合并和衍合、標簽管理等，實際使用場景也遠比上面的復雜，如遠程倉庫的代碼拉取和提交、合并提交時的代碼沖突等。大家有興趣，可以觀看《Linux三劍客》視頻教程或者參考相關文檔自行學習。