Git學習2：為什麼工作區目錄下有.git目錄

SVN等版本控制系統的缺陷

在通過git init命令後在當前目錄出現.git目錄，該目錄預設是隱藏的，需要關閉顯示隱藏檔案才能看到。實際上執行git init命令後，當前目錄就成為了工作區（工作區可以理解為操作本地倉庫的車間），而且，可以發現如果繼續在工作區進行建立其他的資料夾檔案等操作，.git目錄只有一個。

不同於SVN、CVS等版本控制系統，以SVN為例，SVN會在每個子目錄下面建立.svn資料夾，該資料夾包含一些配置檔案，這些配置檔案可以建立對版本庫的跟蹤（實際上這是版本控制系統的共性）。這些配置檔案會記錄工作區的檔名稱、修改時間和版本等資訊，通過時間戳的對比可以快速掃描工作區的改動。在.svn資料夾下還包括原始檔案的拷貝，這些拷貝檔案可以脫離版本庫獨立操作。此外，SVN的版本庫與工作區是分離的。

注：.svn目錄並不是本地倉庫，而是為了建立與遠端版本倉庫的關聯而引入的配置檔案，所以SVN的版本庫與工作區是分離的。

SVN這樣的設計的好處是在提交的時候可以只針對差異部分進行提交，因為改動的檔案可以與原始檔案的拷貝進行差異比較。然而，缺點就是會加倍佔用工作區的空間，而且當在工作區目錄下針對檔案內容進行搜尋的時候，會因為.svn目錄還有原始檔案的拷貝使得搜尋結果加倍，混淆真正的搜尋結果。

Git的設計

Git將版本庫放在本地的做法可以讓除了與遠端倉庫的互動操作外的所有操作都可以在本地實現。由於Git本身的分散式設計，使得Git的同步與更新在網際網路下實現，而SVN只能只能在限定的網路內（往往是區域網）才能使用，所以在需要頻繁更換工作環境（假設網路也發生了變化）的情況下，使用SVN簡直是一個災難。除了不會在搜尋內容時出現加倍的搜尋結果外，Git還可以使用一個簡單的命令完成工作區檔案內容的搜尋——git grep。

git grep “工作區檔案內容”

雖然Git將倉庫放在本地使得操作非常簡便，但是從安全的角度分析，是不是很不安全呢？因為如果因為某個錯誤的操作將工作區所在的資料夾整個刪除了，那麼這樣是危險的。事物總有其兩面性，但是考慮到之前SVN等版本控制系統將版本庫與工作區分離的設計，因為兩者是分離的，那麼就必須引入第三方的配置檔案等機制實現對工作區檔案的跟蹤，這樣的機制勢必就會出現類似SVN的問題。這讓我想起一句話：“進步是需要付出代價的。”

然而，Git針對儲存安全的問題並不是無所作為，Git引入了克隆操作降低了因為版本庫和工作區放在一起導致被破壞的危險。當在工作區發生了修改，只需要手動使用git push或在克隆的工作區使用git pull就可以輕鬆實現兩個工作區的同步與更新。