导读
对之前学习的 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. 版本控制需要什么
既然提出了版本控制理念，那么版本控制需要实现什么功能呢？
- 协同修改
- 毫无疑问的，首先应当解决上述的痛点，即需要能够多人并行不悖的修改同一个文件。
- 数据备份
- 在新的文件系统下，不仅要能保存目录和文件的当前状态，也应当能够保存每一个文件的历史状态。
- 版本管理
- 不仅要能保存每一个历史版本，还不应保留重复的数据，避免空间浪费。
- 这里超纲一下，在这个问题上 SVN 和 Git 的策略不同：
- SVN 采用的策略是增量式管理
- Git 采用的是文件系统快照的方式
- 权限控制
- 对不同的开发人员进行不同的权限控制。在 Git 上，甚至能够对团队外的开发者贡献的代码进行审核（也是在 GitHub 上常说的 PR）。
- 历史记录
- 应当能够查看文件每次修改的修改人、修改时间、修改内容和日志信息。
- 分支管理
- 允许开发团队在工作过程中多条生产线同时推进任务，进一步提高效率。
1.2. 版本控制工具
随着版本控制理念的出现，基于该理念的版本控制工具也出现了。
总的来说，版本控制工具分为两类：集中式 和 分布式。
1.2.1. 集中式版本控制工具
常见的集中式版本控制工具有：CVS、SVN、VSS 等。
在集中式版本控制理念中，每一个开发者都是一个 client，文件和版本信息存储在 server 中，每一次交互都是 c 和 s 的交互。
显然这种集中式版本控制理念是有致命缺陷的，也就是单点故障：
单点故障：当中央服务器出现宕机、甚至于损坏的时候，服务器所存储的版本信息将会丢失
集中式版本控制就像是种子，当 Tracker 服务器被 ban 之后，寄托于该服务器的种子全部失效。
1.2.2. 分布式版本控制工具
常见的分布式版本控制工具有：Git、Bazaar、Darcs 等。
如果说集中式版本控制工具是种子，那么分布式版本控制工具就是磁链了。
没错，以分布式管理工具的代表 Git 为例，在分布式版本控制理念中，每一个开发者的本地都将存储版本信息，当任一设备故障时都能在别的设备中恢复。
即便如此，但事实上大多数都不会直接在本地直接开发，一般会把代码托管在 远端服务器上。
至此，本文的全部内容就结束了，感谢你的阅读，欢迎继续阅读本站的其他文章。
版权声明：本文为原创文章，版权归 夕綺Yuuki 所有。
本文链接：https://kira.cool/note/195-Study-Git-1
本文章采用 CC BY-NC-SA 4.0 International 协议进行许可。这意味着您可以自由的复制、转载和修改，惟须注明文章来源且禁止用于商业目的。
This article is licensed under the CC BY-NC-SA 4.0 International License, which means you are free to copy, distribute, and modify it, but must attribute the source and prohibit commercial use.
Comments NOTHING