一、版本控制
1.1 何为版本控制
版本控制(Revision control)是一种在开发的过程中用于管理我们对文件、目录或工程等内容的修改历史,方便查看更改历史记录、备份,以便恢复以前的版本的软件工程技术。
版本控制其实最重要的是可以记录文件的历史修改记录,从而让用户能够查看历史版本, 方便版本切换。
1.2 为什么需要版本控制
在使用版本控制之前,许多人习惯用复制整个项目目录的方式来保存不同的版本,或许还会改名加上备份时间以示区别,如下图所示:
这么做唯一的好处就是简单,但是特别容易犯错。 有时候会混淆所在的工作目录,一不小心会写错文件或者覆盖意想外的文件。
1.3 本地版本控制系统
为了解决这个问题,人们很久以前就开发了许多种本地版本控制系统(Version Control System,VCS),大多都是采用某种简单的数据库来记录文件的历次更新差异。
其中最流行的一种叫做 RCS,现今许多计算机系统上都还看得到它的踪影。 RCS 的工作原理是在硬盘上保存补丁集(补丁是指文件修订前后的变化);通过应用所有的补丁,可以重新计算出各个版本的文件内容。
1.3.1 集中化的版本控制系统
接下来人们又遇到一个问题,如何让在不同系统上的开发者协同工作? 于是,集中化的版本控制系统(Centralized Version Control Systems,简称 CVCS)应运而生。
这类系统,诸如 CVS(Concurrent Versions System)、SVN(Subversion)以及 Perforce 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。
多年以来,这已成为版本控制系统的标准做法。
这种做法带来了许多好处,特别是相较于老式的本地 VCS 来说。 现在,每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限,并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
事分两面,有好有坏。 这么做最显而易见的缺点是中央服务器的单点故障:
- 如果中央服务器宕机一小时,那么在这一小时内,谁都无法提交更新,也就无法协同工作。
- 如果中心数据库所在的磁盘发生损坏,又没有做恰当备份,毫无疑问你将丢失所有数据——包括项目的整个变更历史,只剩下人们在各自机器上保留的单独快照。
本地版本控制系统也存在类似问题,只要整个项目的历史记录被保存在单一位置,就有丢失所有历史更新记录的风险。
1.3.2 分布式版本控制系统
于是分布式版本控制系统(Distributed Version Control System,简称 DVCS)面世了。
在这类系统中,像 Git、Mercurial、Bazaar 以及 Darcs 等,客户端并不只提取最新版本的文件快照, 而是把代码仓库完整地镜像下来,包括完整的历史记录。 这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复,因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份。
在分布式版本控制系统中,由于大家都拥有一个完整的版本库,不需要联网也可以提交修改,所以中心服务器就显得不那么重要了。那开发成员之间如何交换修改呢?由于大家都拥有一个完整的版本库,所以只需把各自的修改推送给对方,就可以互相看到对方的修改了。
分布式的版本控制系统出现之后,解决了集中式版本控制系统的缺陷:
- 在服务器断网的情况下也可以进行开发(因为版本控制是在本地进行的)
- 每个客户端保存的也都是整个完整的项目(包含历史记录,更加安全)
不过分布式版本控制系统一般也有一个「中心服务器」,但它只是用于方便大家的交换而已(挂了也没关系),而 GitHub 就是这么一个平台。
附上 SVN 迁移至 Git 的工具:GitHub - nirvdrum/svn2git: Ruby tool for importing existing svn projects into git.
1.4 使用版本控制的优点
- 实现跨区域多人协同开发
- 追踪和记载一个或者多个文件的历史记录
- 组织和保护你的源代码和文档
- 统计工作量
- 并行开发、提高开发效率
- 跟踪记录整个软件的开发过程
- 减轻开发人员的负担,节省时间,同时降低人为错误
一句话总结,版本控制就是用于管理多人协同开发项目的技术。
1.5 评论大佬
看完文章,刚开始看评论的时候,感觉:“一个一个问题的问题真好,我也有这样的疑问”,各位网友的回答也都很清楚,直到我看到 -廖雪峰- 老师的评论
集中式和分布式的区别是:
你的本地是否有完整的版本库历史!
假设SVN服务器没了,那你丢掉了所有历史信息,因为你的本地只有当前版本以及部分历史信息。
假设GitHub服务器没了,你不会丢掉任何git历史信息,因为你的本地有完整的版本库信息。你可以把本地的git库重新上传到另外的git服务商。
才感觉真正明白(当然我也不太清楚我是不是真的明白)
我的理解是:Git 其实就是每个人电脑上都装一个svn服务器,你写了代码提交到自己电脑服务器上就是Commit;但是如果你想多人协作,就要把你的改动发送到你**每一个同事 **的svn服务器上就是push;
关于有人有疑问说
分布式的版本控系统如果要在多个人之间协作不也是需要一个像github一样的的远程版本库吗,这与集中式的有什么区别呢?
接着按照上面的理解,假如你还有10个同事,你每一次更改都要提交10次,其他同事有更改也要分别向我们提交,是不是觉得好烦,所以我们说干脆找一台固定电脑(服务器)用来统一规定把修改推给这台电脑,这样只需要提交1次就行了,其他人去这台机器上同步就好了。
发现没有,Git的中央服务器可以没有,我们只是为了方便才这么做的。
此时,如果这个中央服务器坏了,你只需要重新弄个电脑,把自己电脑上的同步一份过去,大家约定好都提交到这个新电脑上就行了。【所有的版本和历史都在,因为大家电脑上都是一样的】
而集中式的SVN就不同了,你从中央服务器上下载好完整的代码,正常工作(写代码)是可以,但是如果断网了,你就无法回滚版本;这时你可能谁说,先不提交,等联网了我再提交。
不好意思,这次断网是因为服务器报废了,是蒸发的那种,硬盘灰飞烟灭了。等你再次连上网的时候,就是你永远丢失了历史版本的时候,想回滚就只能靠做梦了。
比特币的区块链设计就类似git,人手一份全账本,只是用p2p全网同步,而git通常搞个中心化服务来同步
svn像银行,完整账本只有银行有,作为终端节点可以向银行查询账本,但如果某一天银行没了,整个完整账本就没了
分布式的核心设计是同步,而不是主从
软件架构,核心思想其实是非常简单的
二、Git 概述
2.1 Git 是什么
Git 是一个免费的、开源的分布式版本控制系统,可以快速高效地处理从小型到大型的各种项目。Git 易于学习,占地面积小,性能极快。 它具有廉价的本地库、方便的暂存区域和多个工作流分支等特性。其性能优于 Subversion、CVS、Perforce 和 ClearCase 等版本控制工具。
2.2 Git 好用在哪里
2.2.1 SVN
SVN 是集中式版本控制系统,版本库是集中放在中央服务器的,而工作的时候,用的都是自己的电脑,所以:
- 首先要从中央服务器得到最新的版本,然后工作。
- 完成工作后,需要把自己做完的活推送到中央服务器上。
集中式版本控制系统是必须联网才能工作,对网络带宽要求较高。
2.2.2 Git
而 Git 是分布式版本控制系统,没有中央服务器,每个人的电脑就是一个完整的版本库,工作的时候不需要联网了,因为版本都在自己电脑上。
协同的方法是这样的:比如说自己在电脑上改了文件A,其他人也在电脑上改了文件A,这时,你们两之间只需把各自的修改推送给对方,就可以互相看到对方的修改了。
像 Git 这种分布式版本控制工具,客户端提取的不再是最新版本的文件快照,而是把代码仓库完整地镜像下来(本地库)。
2.3 Git 简史
很多人都知道,Linus 在 1991 年创建了开源的 Linux。从此,Linux 系统不断发展,已经成为最大的服务器系统软件了。
Linus 虽然创建了 Linux,但 Linux 的壮大是靠全世界热心的志愿者参与的,这么多人在世界各地为 Linux 编写代码,那 Linux 的代码是如何管理的呢?事实是,在 2002 年以前,世界各地的志愿者把源代码文件通过 diff 的方式发给 Linus,然后由 Linus 本人通过手工方式合并代码!
你也许会想,为什么 Linus 不把 Linux 代码放到版本控制系统里呢?不是有 CVS、SVN 这些免费的版本控制系统吗?这是因为 Linus 坚定地反对 CVS 和 SVN,这些集中式的版本控制系统不但速度慢,而且必须联网才能使用。有一些商用的版本控制系统,虽然比 CVS、SVN 好用,但那是付费的,和 Linux 的开源精神不符。
到了 2002 年,Linux 系统已经发展了十年,代码库之大让 Linus 很难继续通过手工方式管理了,社区的弟兄们也对这种方式表达了强烈不满,于是 Linus 选择了一个商业的版本控制系统 BitKeeper,BitKeeper 的东家 BitMover 公司出于人道主义精神,授权 Linux 社区免费使用这个版本控制系统。
安定团结的大好局面在 2005 年就被打破了。Samba 文件服务器开发人 Andrew Tridgell 写了连接 BitKeeper 储存库的简单程序,被 BitMover 创办人 Larry McVoy 指控对 BitKeeper 进行逆向工程,因此决定停止 BitKeeper 对 Linux 的支持。顿时 Linux 核心开发受到严峻的挑战,这就迫使 Linux 开源社区(特别是 Linux 的缔造者 Linus Torvalds)基于使用 BitKeeper 时的经验教训,开发出自己的版本系统。
之后,Linus 花了两周时间自己用 C 写了一个分布式版本控制系统,这就是 Git!一个月之内,Linux 系统的源码已经由 Git 管理了。
Git迅速成为最流行的分布式版本控制系统。尤其是 2008 年,GitHub网站上线了,它为开源项目免费提供 Git 存储,无数开源项目开始迁移至 GitHub,包括 jQuery、Ruby、PHP 等等。
三、Git 安装
3.1 傻瓜式安装
- 首先从官网地址下载最新的 Git:Git (git-scm.com)
- 双击安装包进行安装,一路点击 Next 使用默认配置就行
如果你想知道安装过程中的具体内容,可以看一下下面的内容,非必须~
3.2 安装界面详解
-
Git 安装位置,要求是非中文并且没有空格的目录。
-
Git 选项配置,推荐默认设置,然后下一步。
-
Git 安装目录名,不用修改,直接点击下一步。
-
Git 的默认编辑器,建议使用默认的 Vim 编辑器,然后点击下一步。
-
默认分支名设置,选择让 Git 决定,分支名默认为 master,下一步。
-
修改 Git 的环境变量,选第一个,不修改环境变量,只在 Git Bash 里使用 Git。
-
个人建议选择第二个选项,后期如果要使用 Sourcetree 这个可视化 Git 工具,有大用处。
-
-
选择后台客户端连接协议,选默认值 OpenSSL,然后下一步。
-
配置 Git 文件的行末换行符,Windows 使用 CRLF,Linux 使用 LF,选择第一个自动 转换,然后继续下一步。
-
选择 Git 终端类型,选择默认的 Git Bash 终端,然后继续下一步
-
选择 Git pull 合并的模式,选择默认,然后下一步。
-
其他配置,选择默认设置,然后下一步。
-
实验室功能,技术还不成熟,有已知的 bug,不要勾选,然后点击右下角的 Install 按钮,开始安装 Git。
3.3 安装成功测试
-
右键任意位置,在右键菜单里选择 Git Bash Here 即可打开 Git Bash 命令行终端。
-
在 Git Bash 终端里输入
git --version
查看 git 版本。
参考资料
- Git实用教程1:世界上最先进的分布式版本控制系统简介(有彩蛋),《极客Python之Git实用教程》,Python交流,鱼C论坛 - Powered by Discuz! (fishc.com.cn)
- Git - Book (git-scm.com)