导读

对之前学习的 Git 进行整理,以防忘记


1. 版本控制

网上对于版本控制的解读甚多,但无外乎就两个方面:
对个人:就是简单明了的后悔药,在不满意某次更改的时候可以快速回退到上个版本;
对团队:解决协同开发的痛点。
版本控制更常在团队协同开发中提起,我们以协同开发为例。
传统的文件系统只能对 文件 这一整体进行管理和控制,而不能对文件的内容进行管理。

举个例子:

某一传统的文件服务器上存有一空文件 main.js ,现团队分成两组为该文件添加两个 function。
小组 A 率先完成了 function A 的开发,共有 108 行代码,占据了 main.js 的 1 - 108 行。
小组 B 在一天后完成了 function B 的开发,共 78 行代码,占据了文件的 1 - 78 行。

问题来了,传统的文件系统不能管理文件内部的内容,你猜这个文件最后会是怎么样的?没错,这个 main.js 只会有小组 B 完成的 78 行代码。
为了提高开发效率,版本控制这一概念就被提出来了。

1.1. 版本控制需要什么

既然提出了版本控制理念,那么版本控制需要实现什么功能呢?

  1. 协同修改

    • 毫无疑问的,首先应当解决上述的痛点,即需要能够多人并行不悖的修改同一个文件。
  2. 数据备份

    • 在新的文件系统下,不仅要能保存目录和文件的当前状态,也应当能够保存每一个文件的历史状态。
  3. 版本管理

    • 不仅要能保存每一个历史版本,还不应保留重复的数据,避免空间浪费。
    • 这里超纲一下,在这个问题上 SVN 和 Git 的策略不同:

      • SVN 采用的策略是增量式管理
      • Git 采用的是文件系统快照的方式
  4. 权限控制

    • 对不同的开发人员进行不同的权限控制。在 Git 上,甚至能够对团队外的开发者贡献的代码进行审核(也是在 GitHub 上常说的 PR)。
  5. 历史记录

    • 应当能够查看文件每次修改的修改人、修改时间、修改内容和日志信息。
  6. 分支管理

    • 允许开发团队在工作过程中多条生产线同时推进任务,进一步提高效率。

1.2. 版本控制工具

随着版本控制理念的出现,基于该理念的版本控制工具也出现了。
总的来说,版本控制工具分为两类:集中式分布式

1.2.1. 集中式版本控制工具

常见的集中式版本控制工具有:CVS、SVN、VSS 等。
在集中式版本控制理念中,每一个开发者都是一个 client,文件和版本信息存储在 server 中,每一次交互都是 c 和 s 的交互。
显然这种集中式版本控制理念是有致命缺陷的,也就是单点故障

单点故障:当中央服务器出现宕机、甚至于损坏的时候,服务器所存储的版本信息将会丢失

集中式版本控制就像是 种子,当 Tracker 服务器被 ban 之后,寄托于该服务器的种子全部失效。

1.2.2. 分布式版本控制工具

常见的分布式版本控制工具有:Git、Bazaar、Darcs 等。
如果说集中式版本控制工具是种子,那么分布式版本控制工具就是磁链了。
没错,以分布式管理工具的代表 Git 为例,在分布式版本控制理念中,每一个开发者的本地都将存储版本信息,当任一设备故障时都能在别的设备中恢复。

即便如此,但事实上大多数都不会直接在本地直接开发,一般会把代码托管在 远端服务器上。

至此,本文的全部内容就结束了,感谢你的阅读,欢迎继续阅读本站的其他文章。