背景：

? ? ? ? ?原本在學校跟隨導師做項目的時候，就一直在使用版本管理，主要是用來記錄項目的修改，項目成員之間的溝通和交流。使用的服務端是Visual SVN，客戶端是TortoiseSVN，常用的TortoiseSVN指令也僅限于SVN Update和SVN Commit，前者用來從服務器更新，以期望查看其他同學的修改，后者用來將自己的修改提交到服務器，使得團隊共享修改。由于項目組中的成員比較少，主要的代碼修改也只有我一人完成，因此TortoiseSVN也就淪為了記錄我修改本地代碼過程的工具。其實這與我平時寫工作日志（word格式）、代碼中添加注釋（注釋中一般會出現修改原因、修改者、修改時間、備注）的習慣有一些冗余。

? ? ? ? 隨后進入職場，接觸的項目越來越大、開發者越來越多，就慢慢開始了解TortoiseSVN的其它功能。例如查看文件修改日志Show log、回滾已提交的修改操作Revert、創建分支Branch/Tag、創建補丁Create patch等。在逐漸熟悉和使用的情況下，逐漸感覺到TortoiseSVN似乎還缺少一點什么功能？比如下述場景就經常發生：我從項目SVN服務器拷貝自己負責的代碼到我的本本，然后按照項目計劃開始修改自己的模塊（此時就像在本地開發調試一樣），但是突然臨時接到上級指示，有一個緊急的Bug要處理。此時我只能先創建補丁文件（Create patch），然后將目前的修改回滾到初始狀態（即我從SVN服務器拷貝時的版本），如是我才能開始修改緊急的bug。等待修補完成后，再將先前的patch文件應用回來。這里面我會同時做好相應的工作記錄（word文檔），這里面就會記錄我初始修改模塊時的相關步驟和細節，記錄bug修補的過程，然后接著記錄模塊的修改。如此，結合TortoiseSVN的提交日志和我的word工作文檔，我才能精確的定位我開發過程中的任意時刻——方便后續思路的整理和延續，如下圖所示：如果每次TortoiseSVN提交的時間粒度是按照黃色箭頭所示，那么中間的紅色修改我只能在我的word工作日志中查看，但是word中畢竟記錄的是思路，具體的代碼文件我只能手動拷貝到word日志中記錄的相應位置，或者創建patch文件保存到制定位置，如果TortoiseSVN提交的時間粒度是途中箭頭所示，那么這與word日志的工作幾乎重復，可以達到隨意定位修改的目的，但是需要注意的是，在團隊開發中，如此頻繁的TortoiseSVN提交時絕對不可能的，一是SVN服務器要求完整的功能修改完成后才能提交，而是如此頻繁的提交會增加服務器負擔，也會使得自己不完整的代碼模塊影響整個項目的功能。

? ? ? ? 看到這里，你是不是覺得好復雜，好麻煩，但是對于碼農來說，良好的記錄和注釋是必須的，這樣你才能更好的對自己的代碼負責。這種開發狀態我已經堅持了多年，也習以為常了，直到某一天我接觸了Git后，我才恍然發現，原來還有一種所謂的分布式版本管理工具，可以記錄我的本地修改。真是令我喜大普奔。

? ? ? ? 下面介紹一下怎么利用Git來管理本地的代碼修改。

Git管理本地代碼修改：

1）Git與SVN的區別：

? ? ? ? 關于兩者的分析和討論早已遍布各大論壇、貼吧，這里我不評價兩者孰優孰劣。僅從自己實際的代碼開發工作，從提高我本人代碼開發效率的角度來說一下我對兩者的看法。正如背景中所述，SVN的使用已有多年，簡單的來說就是有一個服務器會存儲你對代碼的修改，這里的修改必須是你確定提交（Commit）到服務器的。對于兩次提交的間隔粒度完全取決于開發者本人，如果僅僅是利用SVN來管理自己的代碼開發記錄，你完全可以隨意提交以期望來記錄自己完整的開發流程（這種方式在團隊合作中是堅決不允許的）。SVN的結構分為版本庫和工作副本，版本庫就是放在服務端的“數據庫”用來記錄你每次的提交，記錄的內容包括所有版本庫控制范圍內的文件的改動；工作副本就是你自己本機中的代碼工程，它是服務器中代碼工程的一個拷貝，SVN將版本庫和工作副本存放在不同的位置。具體的示意圖如下（自己思路的直接體現，可能不一定完全符合SVN的工作過程，但是大意是正確的，便于大家理解）：

? ? ? ? 從上圖可以看出，SVN版本管理的基本流程，服務端保存的是你每次對工程進行的修改，當然第一次提交時記錄的就是你的初始工程文件。那么從上圖SVN服務端的目錄結構中我們并未直接看到我們提交的工程文件，而利用TortoiseSVN （本地服務器）和VisualSVN（遠端服務器）的Repo-browse卻可以看到我們具體的項目文件，如下圖。那么我們提交的文件又存到哪里了呢？直觀猜測的話應該是db目錄下的某些文件，因為隨著提交次數的增加，該文件的大小也在變化。搜索一下相關資料，找到了如下的回答：

“svn有兩種存儲方式：BDB和FSFS，目前用的最多的是FSFS方式，這種方式的話，一般是存儲在\db\revs文件夾下，里面有一堆以版本號命名的文件，如：0、1、2、3、4......，那個就是我們的工程文件。svn先把0版本的狀態壓縮成1個文件，然后每次版本更新時就針對變動的部分做一個壓縮文件，每次都是增加一個增量包，最后在服務器上能看到文件名為從0開始到最終版本的一系列文件”

“SVN服務器端不是簡單將上傳的文件一個一個存放起來的，SVN服務器端默認采用的FSFS格式是將每次commit的內容增量方式存放的，每個增量包存成1個文件，這個增量包中包括了這次commit的全部數據。也就是說你不可能在服務器端存放該版本庫的文件夾下找到你上傳的某個文件”。

? ? ? ? 至此我們就明白了SVN服務端的結構。至于客戶端就沒什么難的了。就是通過網絡協議將服務端的版本庫下載到本地，存儲在.svn目錄下，除此以外的就是自己的工程文件了（如果你是從遠端SVN服務器下載的別人的工程，那么就是別人的工程文件）。.svn中記錄的是你從SVN服務器下載時刻時服務器工程文件的狀態，再下一次提交時刻，會與SVN服務器通訊來查看服務器和你本地兩端的修改狀況。

? ? ? ? 由此我們可以看出要想對本地的修改進行記錄，必須要與SVN服務器進行通訊，無法只是單純的保存本地的修改。這也是我尋求Git的主要目的。百度百科對Git的描述是：“Git是一個開源的分布式版本控制系統，用以有效、高速的處理從很小到非常大的項目版本管理。分布式和集中式的最大區別在于開發者可以本地提交。每個開發者機器上都有一個服務器的數據庫。”——反正就是一句話，Git可以完成上述我想要的本地修改記錄。

2）Git管理本地代碼修改

? ? ? ? 第一步，Git的版本庫和工作副本在同一目錄下，叫做.git。安裝完Git后，可以直接在任意目錄下單擊右鍵，選擇Git Init Here，建立Git版本庫，即.git文件夾。（謹記：這是我們在本地建立的版本庫，壓根兒沒有服務器毛關系啊，^_^。）

? ? ? ? 第二步，直接將我們需要管理的本地工程拷貝到.git同目錄下。隨后我們想正常開發一樣打開工程進行操作即可，直到我想保存一下修改狀態時，我們就可以轉到第三步。

? ? ? ? 第三步，在工程文件夾中右鍵，選擇Git Gui，會彈出管理窗口，這里會顯示我們所做的修改，在紅色框中列出的是我們做過修改的文件，橙色框中可以看到所做的修改。綠色框中顯示的是修改的緩沖區，通過在紅色框中選擇指定文件進入到綠色的緩沖區后，我們可以單擊黃色按鈕“提交”，至此本次我們對本地文件的修改記錄就已經提交了。

? ? ? ? 第四步，在工程文件夾右鍵，選擇Git History，我們既可以看到本地的此次修改記錄。

? ? ? ?

? ? ? ? ?至此我們就很容易的實現了對本地代碼修改的記錄，而這整個過程中，根本沒出現服務器。這是與SVN最大的區別。

? ? ? ? 今天就記錄到這里，明天會對背景中的場景的進行詳細的介紹，給出Git的解決方案。

?

（未完待續……）

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的版本控制：SVN和GIT的一些使用感受的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。