写在前面的话
- 本系列的文章不完全适合对Git零基础的人看,你可能在看到某些章节的时候需要翻阅其他的一些”大众资料”[Git最基础的一些操作知识,只要百度就能搜到的知识]
- 本系列的文章会陆续更新一些我工作中遇到的Git的问题
- 为什么要写这一系列文章?本来很久之前就想写了,一直被诸多借口搁置了,入职租租车(为全球喜欢自驾游的驴友提供租车的平台)后,由于在GitLab上revert了一次代码,导致代码发布流程失败了,同时也被运维哥哥叼了[但是我觉得不应该有问题,我怀疑一定是发布脚本有bug],于是翻阅了大量的Git书籍和资料[当时只是想证明不是我的锅],在学习过程中发现了Git还有很多的有用的秘密操作,同时也开始养成写作习惯,遂有此系文章[不知道后续会不会停止这股热情,但是先开始吧,开始了再去想怎么坚持,不然是没有用的]!
1.什么是”版本控制”？
确保不同人所编辑的同一东西能集体得到更新，并在必要时候可以对没一个修改状态进行：查看、恢复
2.为什么会有”版本控制系统”?
“工具”的产生都是为了解决”生产”上的烦恼
- 你可以想象一下现在你要写“毕业论文”或者你老板叫你改一个“还没有拿定主意”的设计稿？你可能会频繁修改很多个版本，修改过程中你会频繁的：删除、修改、增加，你也不确定到底最终那个版本会是你需要的？你要怎么做？
- 每一个版本都复制一份完整的”资料”，或者把每个版本之间的差异都记录保存起来就可以了！
- 保存版本太多了，你怎么知道自己保存的东西到底是什么呢？
- 你可以再回过头去看每一个版本的”资料”,或者在命名的时候定义一个”完美”的规则,你能够通俗易懂的规则
- 如果是有很多个人和你一起完成手里的工作呢？如何防止命名的重复？如何防止相互修改的东西进行覆盖了?……
- 各自复制+重命名版本号：名字混乱(起名字真的很难起)、被覆盖了就”完蛋”了、不能协作
你所能想到的问题，肯定是有方法可以解决的！但是如果有一个工具可以帮你完成以上的问题，何乐而不为呢？
3.版本系统的几个重要”代表”和”节点”
1. 本地版本系统:RCS
解决了当时的需求，但是随着需求的复杂，缺点也突显出来了
- 类似”系统补丁”，在硬盘上保存”差集”，回退时进行大量计算比较得出不同
- 不能协作，个人电脑容易”犯傻”，遇到了问题：如何让不同人在不同系统上的开发者协同工作？
2.集中式版本管理:CVS、SVN(CVS的进阶产品)
解决了本地版本系统遗留的问题,但是随着时间推移,现在缺点也逐渐突显出来了,尽管还有比较多企业在用着SVN
- 有一个单一的集中管理的服务器，保存所有文件的修订版本与版本之间的差异
- 协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新
- 需要回退版本或者跟新时候,工具通过算法回溯的去计算,恢复到指定版本状态的”资料”
但是如果”中心服务器”宕机了,那么意味着所有人都不能拉取、更新、比较历史版本差异…..,所有人都要停下等中心机器恢复工作！
3.分布式版本管理:Git、Bazaar
- 尽管这一点不是所有分布式版本管理工具的特征,但这是绝大多书分布式管理工具共有的方式,
- 分布式客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来
- 将整个仓库克隆下来，那么就不怕任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复
- 许多这类系统都可以指定和若干不同的远端代码仓库进行交互,当需要的时候才进行推送,不需要推送的时候你可以照常在本地进行代码:比较差异、分支切换、检出历史版本代码……
4.为什么会有”Git”?
因为2005年，BitKeeper的商业公司与Linux内核开源社区的合作关系结束，Linux之父一气之下开发了自己的版本控制系统，虽然网上说了很多种，但是不管到底那个才是正确的，最后要求设计出来的版本控制系统满足以下要求：
- 速度
- 安全
- 简单的设计
- 对非线性开发模式的强力支持(允许成千上万的分支并行开发)
- 完全分布式
- 有能力高效的管理类似Linux内核一样的超大规模项目(速度与数据量)
