Subversion 用户眼中的 Git (2): 版本库, 工作区如影随形

Subversion 的工作区和版本库截然分开，工作区中的修改要提交到版本库，可能是本机另外一个目录的版本库，也可能是通过网络连接到服务器上的版本库。 而 Git 的工作区和版本库是如影随形的。没有使用过分布式版本控制系统的 Subversion 用户可能会感到困惑，也可能将如影随形的 .git 目录看作是 Subversion 工作区中的 .svn 目录的等价物，那可就错了…

Git 的版本库和工作区如影随形

Subversion 的工作区和版本库物理上分开：

• Subversion的版本库和工作区是存储在不同路径下，一般是在不同的主机中
• Subversion的企业级部署中，版本库在服务器上，只能通过 https, http, svn 等协议访问，而不能直接被用户接触到
• Subversion的工作区是一份版本库在某个状态下的快照，如：版本库最新的数据检出到工作区
• Subversion的工作区中每一个目录下都包含一个名为 .svn 的控制目录（隐藏的目录），该目录的作用是：
  • 标识工作区和版本库的对应关系。参见文件 .svn/entries
  • 包含一份该子目录下检出文件的原始拷贝。当文件改动的差异比较或者本地改动的回退时，可以直接参考原始拷贝而无须通过网络访问远程版本库
• Subversion 的 .svn 控制目录，会引入很多麻烦：
  • .svn 下的文件原始考本，会导致在目录下按照文件内容搜索时，多出一倍的搜索时间和搜索结果
  • .svn 很容易在集成时，引入产品中，尤其是 Web 应用。将 .svn 目录带入Web服务器会导致安全隐患。因为一个不允许目录浏览的Web目录，可以通过 .svn/entries 文件查看到该目录下可能存在的文件，进而 :silly:

Git 的版本库和工作区如影随形，在同一个目录下

• 最常见的模式是工作区和版本库在一起
  • 工作区的根目录有一个.git 子目录，这个名为 .git 的目录就是版本库本身，千万不要删除噢
  • 工作区中其他文件为工作区文件，可能是从 .git 中检出的，或者要检入的，或者是运行时、临时文件
  • 当然版本库可以脱离工作区而存在，成为 bare（赤裸？）版本库。可以用 --bare 参数来创建
  • 但是工作区不能脱离版本库而存在，即工作区的根目录下必须有一个名为 .git 的版本库克隆
• Git 的版本库因为就在工作区中，能直接被用户接触到
  • 用户可以编辑 .git/config 文件，修改配置，增添新的源
  • 用户可以编辑 .git/info/exclude 文件，创建本地忽略…
• Git 的工作区中只在工作区的根目录下有一个 .git 目录，此外再无任何控制目录。
  • 像 Subversion的泛滥的 .svn 目录的缺点都不存在
  • Git 工作区下唯一的 .git 目录是版本库，并非 .svn 的等价物，如果删除了 .git 目录，而又没有该版本库的其他镜像（克隆）的话，你破坏了整个历史，版本库也永远的失去了。
• Git 在本地的 .git 版本库，提供了完全的改动历史
  • 除了和其他人数据交换外，任何版本库相关的操作都在本地完成
  • 更多的本地操作，避免了冗长的网络延迟，大大节省了时间。例如：查看 log，切换到任何历史版本等操作都无须任何网络操作。

Git的版本库和工作区混在一起，安全么？

• 本地创建一个Subversion版本库，再在另外的目录检出，心理上感觉很安全。即使工作区删除了，或者工作区所在的分区格式化了，但是版本库仍在啊。
• 本地创建一个Git库，因为工作区和库是在同一个目录中，如果工作区删除了，或者所在的磁盘分区格式化了，数据不是全都没有了么？

其实Git更安全：

• 第一个办法：在一个磁盘分区中创建版本库（最好是用--bare 参数创建），然后在另外的磁盘分区中克隆一个新的作为工作区。在工作区的提交要不时的PUSH到另外分区的版本库，这样就实现了本地的数据镜像。你甚至可以在本地创建更多的版本库镜像，安全性要比Subversion的一个库加上一个工作区安全多了吧。
• 另外的办法：把你的版本库共享给他人，当他人克隆了你的版本库时，你就拥有了一个异地备份。