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
。