虽说自己使用过git,但是并不是太了解git,于是今天去搜索了一下,顺藤摸瓜的,了解了一下版本管理工具,现在和大家分享一下。
Git的诞生
相传,Linus虽然创建了Linux,但是Linux的壮大是靠全世界热心的志愿者参与的,那么这么多人在世界各地为Linux编写代码,Linux的代码是如何管理的呢?
事实是,在2002年以前,世界各地的志愿者把源代码文件通过diff的方式发给Linus,然后由Linus本人通过手工方式合并代码!
inus虽然创建了Linux,但Linux的壮大是靠全世界热心的志愿者参与的,这么多人在世界各地为Linux编写代码,那Linux的代码是如何管理的呢?
你也许会想,为什么Linus不把Linux代码放到版本控制系统里呢?不是有CVS、SVN这些免费的版本控制系统吗?因为Linus坚定地反对CVS和SVN,这些集中式的版本控制系统不但速度慢,而且必须联网才能使用。有一些商用的版本控制系统,虽然比CVS、SVN好用,但那是付费的,和Linux的开源精神不符。
不过,随着时间的发展,Linux系统已经发展了10年,代码库之大让Linus很难继续通过手工方式管理了,社区的弟兄们也对这种方式表达了强烈不满,于是Linus选择了一个商业的版本控制系统BitKeeper,BitKeeper的东家BitMover公司出于人道主义精神,授权Linux社区免费使用这个版本控制系统。
事实是,在2002年以前,世界各地的志愿者把源代码文件通过diff的方式发给Linus,然后由Linus本人通过手工方式合并代码!
你也许会想,为什么Linus不把Linux代码放到版本控制系统里呢?不是有CVS、SVN这些免费的版本控制系统吗?因为Linus坚定地反对CVS和SVN,这些集中式的版本控制系统不但速度慢,而且必须联网才能使用。有一些商用的版本控制系统,虽然比CVS、SVN好用,但那是付费的,和Linux的开源精神不符。
安定团结的大好局面在2005年就被打破了,原因是Linux社区牛人聚集,不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议(这么干的其实也不只他一个),被BitMover公司发现了(监控工作做得不错!),于是BitMover公司怒了,要收回Linux社区的免费使用权。
Linus可以向BitMover公司道个歉,保证以后严格管教弟兄们,嗯,这是不可能的。实际情况是这样的:
Linus花了两周时间自己用C写了一个分布式版本控制系统,这就是Git!一个月之内,Linux系统的源码已经由Git管理了!牛是怎么定义的呢?大家可以体会一下。
Git迅速成为最流行的分布式版本控制系统,尤其是2008年,GitHub网站上线了,它为开源项目免费提供Git存储,无数开源项目开始迁移至GitHub,包括jQuery,PHP,Ruby等等。
历史就是这么偶然,如果不是当年BitMover公司威胁Linux社区,可能现在我们就没有免费而超级好用的Git了。
当然了,这个是一种说法,也可能是虚构的,毕竟我没有找到证据,证明就是这样。所以我就这么一写,你也就这么一看,希望大家不要较真,如果能给大家了解Git而增添了一些趣味,那就更好,没有也无妨。
版本控制工具
我们先来看一张图片,了解一下版本控制工具的发展:
- CVS是一个C/S系统,多个开发人员通过一个中心版本控制系统来记录文件版本,从而达到保证文件同步的目的。
- SVN是Subversion的简称,是一个开放源代码的版本控制系统,相较于RCS、CVS,它采用了分支管理系统,它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Subversion。说得简单一点SVN就是用于多个人共同开发同一个项目,共用资源的目的。
- Git是一个开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
- gitHub是一个面向开源及私有软件项目的托管平台,因为只支持git 作为唯一的版本库格式进行托管,故名gitHub。
- 所以目前来说性价比最高的是Git。
版本控制工具的区别
特征 | CVS | Git | Subversion |
是否原子提交 | CVS: 没有. CVS提交不是原子的 | Git: 是的. 提交都是原子的 | Subversion: 提交都是原子的 |
文件和目录是否可以移动或重命名 | CVS: 不是. 重命名不支持. 如果手动进行, 可能会损坏历史记录 | Git: 支持重命名, 这是很实用的目的. git甚至能检测到重命名之后文件的改变. 尽管如此, 基于特殊的存储结构, 重命名不会被显示的记录, git能够推导出来(在实际使用中很容易做到) | Subversion: 是的. 支持重命名 |
在移动或重命名之后智能合并 | CVS: 不能. 重命名都不支持, 就不必说智能了 | Git: 不支持. 细节在Git FAQ里: “Git有一个重命名的命令git mv, 但是这仅仅是为了便利. 效果和移掉某个文件, 增加另外一个文件没有任何区别” | Subversion: 不支持. “svn help me“中提到“注意: 这个子命令相当于拷贝和删除.“并且可能有个bug |
文件和目录拷贝 | CVS: 不能. 拷贝不支持 | Git: 不能. 拷贝不支持 | Subversion: 是的. 并且拷贝非常容易(O(1)). 包括产生分支 |
远程存储仓库的备份 | CVS: 间接的. 可以使用John Polstra写的CVSup | Git: 是的. 是git的内部特征 | Subversion: 间接的. 可以使用Chia-liang Kao的SVN::Mirror插件(好像是台湾人)或Shlomi Fish的SVN-Pusher工具 |
是否传递变更到父仓库 | CVS: 不会 | Git: 是的(Linux内核开发过程经常使用这个特征) | Subversion: 是的, 使用要么是Chia-Ling Kao的SVN::Mirror脚本或者Shlomi Fish的svn-push工具 |
仓库权限 | CVS: 很有限. “pre-commit hook scripts“能够被用来实现各种权限控制系统 | Git: 请看和Git一起附带的contrib/hooks/update-paranoid. 看和svnperms类似的path_rules的代码 | Subversion: 是的. 基于HTTP权限的WebDAV-based模块能够支持基于目录级的仓库 |
变更集 | CVS: 不是. 变更是基于文件的 | Git: 是的. 是支持的, 创建他们很容易 | Subversion: 部分支持. 对于一次提交会隐式创建一个变更集 |
跟踪线性的文件历史 | CVS: 是的. cvs annotate | Git: 是的.(git blame) | Subversion: 是的(svn blame) |
能够只在仓库的单目录下作用 | CVS: 是的 | Git: 不是. 尽管如此, 提交多少能被限制, 请看“Repository Permissions” | Subversion: 是的 |
跟踪未提交的变化 | CVS: 是的. 通过cvs diff | Git: 是的. 另外, 分支在git里非常智能, 在某些工作流里能够被当成是另外一个未提交代码的存储库. 请看“git stash“命令 | Subversion: 是的. 使用svn diff |
基于单个文件的提交信息 | CVS: 不是. 提交信息是基于单次变化的 | Git: 是的. 提交信息基于变更集 | Subversion: 不是. 没有这个特征 |
文档 | CVS: 非常棒. 有很多在线的tutorials和资源, 在线的书籍. 命令行客户端也支持一个在线的帮助系统 | Git: 良好. 短的帮助比较简洁难懂. man页很有分量, 但容易误解. 有很多tutorial | Subversion: 很好. 有一些在线的书籍和一些在线的tutorials和资源. 并且书籍是以docbook/xml写的所以很容易变换成其他格式. 命令行同样提供了在线的帮助系统 |
配置是否轻松 | CVS: 好. 是个事实上的标准. 基于每个系统都有并且很容易配置 | Git: 好. 在现有平台上二进制可用. 需要C编译器和Perl. 在windows上需要cygwin. 并有一些Unix特征 | Subversion: Subversion服务器需要安装在apache2模块里(如果有人希望HTTP作为底层协议的话)或使用它自身的服务器. 客户端需要Subversion特征的逻辑还有WebDAV库(针对HTTP). 安装组件很直接, 但是需要一些额外的工作(假定subversion在某些平台没有二进制包可用) |
命令集 | CVS: 包含了3个经常用到的命令的简单的命令集(cvs commit, cvs update和cvs checkout)和其它一些 | Git: 命令集很丰富, 并且和CVS不兼容 | Subversion: 类CVS的命令集, 能够很容易被CVS用户使用 |
网络支持 | CVS: 好. cvs在不同的场合使用不同的协议. 协议能够通过ssh链接的加密隧道进行 | Git: 非常棒. 能够使用本地的git协议, 但也能在rsync, ssh, HTTP和HTTPS上使用 | Subversion: 非常好. Subversion服务器支持WebDAV+DeltaV(基于HTTP或HTTPS)作为底层协议, 或者它自身的协议同样能在ssh链接通道里使用. |
可移植性 | CVS: 好. 客户端能在UNIX, Windows和Mac OS上使用. 服务器端能在UNIX, 附有UNIX模拟层的Windows上使用 | Git: 客户端运行在大多数的UNIX系统上, 但没有MS-Windows本地程序. 基于cygwin的系统看起来也能使用 | Subversion: 非常好. 客户端和服务器端都能在UNIX, Windows和Mac OS X上运行 |
web接口 | CVS: 是的. CVSweb, ViewVC, Chora和wwCVS | Git: 是的. Gitweb包含在发布包中 | Subversion: 是的. ViewVC, SVN::Web, WebSVN, ViewSVN, mod_svn_view, Chora, Trac,SVN::RaWeb::Light,SVN Browser, Insurrection和perl_svn.另外, Subversion的apache服务也提供了一个基础的web接口 |
图形用户界面 | CVS: 非常好. 有很多图形界面可以用: WinCVS, Cervisia(对于KDE), TortoiseCVS(Windows浏览器插件) | Git: Gitk包含在发行版中. Qqit和Git-gui工具也可使用 | Subversion: 非常好. 有很多GUIs可用: RapidSVN(跨平台), TortoiseSVN(Windows浏览器插件), Jsvn(java), 等. 大多数都还在开发中 |
表格转自网上,侵删。这张图介绍比较详细,但是看起来很乱,我来通俗易懂的说一下。
Git与CVS 的区别 :
- 分支更快、更容易。
- 支持离线工作;本地提交可以稍后提交到服务器上。
- Git 提交都是原子的,且是整个项目范围的,而不像 CVS 中一样是对每个文件的。
- Git 中的每个工作树都包含一个具有完整项目历史的仓库。
Git与SVN 的区别
1.Git是分布式的,SVN不是
但是Git并不是目前第一个或唯一的分布式版本控制系统。还有一些系统如 Bitkeeper, Mercurial 等也是运行在分布式模式上的,但Git在这方面做的更好,而且有更多强大的功能特征。
2.Git把内容按元数据方式存储,而SVN是按文件
因为.git目录是处于你的机器上的一个克隆版的版本库,它拥有中心版本库上所有的东西,例如标签,分支,版本记录等。.git目录的体积大小跟.svn比较,你会发现它们差距很大。
3.Git没有一个全局版本号,而SVN有
目前为止这是跟SVN相比Git缺少的最大的一个特征。
4.版本库:SVN只能有一个指定中央版本库
当这个中央版本库有问题时,所有工作成员都一起瘫痪直到版本库维修完毕或者新的版本库设立完成。而 Git可以有无限个版本库。或者,更正确的说法,每一个Git都是一个版本库,区别是它们是否拥有活跃目录(Git Working Tree)。如果主要版本库(例如:置於GitHub的版本库)发生了什么事,工作成员仍然可以在自己的本地版本库(local repository)提交,等待主要版本库恢复即可。工作成员也可以提交到其他的版本库!
5.分支(Branch)在SVN,分支是一个完整的目录
而且这个目录拥有完整的实际文件。如果工作成员想要开启新的分支,那将会影响很大!而 Git,每个工作成员可以任意在自己的本地版本库开启无限个分支。
6.对网络的依赖,SVN>Git
没有网络的时候SVN无法提交(commit)到中央版本库,但是Git可以不依赖网络做任何事情,对分支和合并还有更好的支持
总而言之,Git性价比最高。
最后,小提示+总结
里程碑 = 稳定版本号. 里程碑的含义是: 一个阶段比较稳定的版本,正式提交发布出去.提供zip下载.
操作步骤:
- 在github网站上.进入项目首页.
- 横栏按钮(commits, branches, release等),找到release按钮.
- 找到按钮:Create a new release点击进入下一页面.
- 填入版本号,以及说明信息.
- 完成后,点击publish release,将软件发布出去.
- 这样就完成里程碑建立,同时会自动生成zip下载链接.
小Tips
- 每次提交前,diff自己的代码,以免提交错误的代码
- 关闭项目前,整理好自己的工作区
- 并行的项目,使用分支开发
- 遇到冲突时,搞明白冲突的原因,千万不要随意丢弃别人的代码
- 产品发布后,记得打tag,方便将来拉分支修bug
部分内容转自网上,由本人整理发布,侵删。
感谢你的阅读
2018年4月28日 下午4:02
测试
2018年4月28日 下午4:02
@小红帽 测试!2