大学生网站建设策划书,随州网站推广,网站建设与管理大纲,快速申请wordpressGit 是最流行的版本管理工具#xff0c;可以说是任何程序员都应该掌握的工具。 当然#xff0c;其他人也可以学习它用来进行版本控制 为此#xff0c;我将之前学习 Git 时的笔记整理了下#xff08;预计有二十篇#xff09;#xff0c;作为博客发出来#xff0c;希望能帮…Git 是最流行的版本管理工具可以说是任何程序员都应该掌握的工具。 当然其他人也可以学习它用来进行版本控制 为此我将之前学习 Git 时的笔记整理了下预计有二十篇作为博客发出来希望能帮到你。 本文简单介绍下什么是版本控制以及常见的版本控制工具
在学习之前希望读者有一点点编程经验并且对一些常见的 Linux 命令有所了解这样能更好理解。
本系列主要是参考廖雪峰老师的 Git 教程 和书籍《Git 权威指南》以及自己的使用经验来撰写。
在版本管理工具出现之前……
举个笔者的例子。笔者在写毕业论文的时候由于篇幅非常多经常需要修改但有时候可能会用到之前的版本因此笔者会先备份之前的 Word 文档然后再修改。这就造成了文档非常非常多……
写过毕设或其他长篇大论的文案的人应该都遇到过这种场景。
此时我们是手工管理版本的。对于每个文件你可能几天内都记得每个版本的区别但如果过了一周、过了一个月呢除非有特别记录相信大家都记不清了只能一个个文件打开来认真比对非常麻烦。
如果是多个人共同编写一个文档更麻烦。例如笔者所在的公司是内网没有腾讯文档或者石墨文档之类的在线工具如果要填表并且是经常需要填表都是各自填好后发邮件交由专门的人来合并…… 特别麻烦。
为此我们需要这样一个软件
能帮我们记录每次文件的改动能够方便的查看之前的改动让同事或朋友协作编辑而不是手工传来传去手工合并
这样的软件就叫版本控制工具有了它我们就脱离了手工管理版本的“史前时代”进入到了版本控制的 20 世纪。作为程序猿我们主要是需要版本控制工具来管理我们的一个项目的代码当然你也可以用它来管理其他文件的版本并且一个大型项目经常是需要多人协作的纯靠手工来管理代码版本不太实际。
常见的版本控制工具
我们依次来简单介绍以下几个工具大部分笔者都曾在工作中用过
diff 和 patch 命令CVS全称 Concurrent Versions System第一个被广泛使用的版本管理工具SVN修正了 CVS 的一些稳定性问题是目前用得最多的集中式版本库控制系统Git目前世界上最先进的分布式版本控制系统没有之一必学其他版本控制工具了解即可
版本库的概念
存储版本的地方存放各个版本之间差异的地方通常称为版本库。通常版本库是以文件夹的形式存放在磁盘上
Git 是用一个目录来存储各个版本和差异的文件目录名字为 .gitSVN 同理用 .svn 目录来存储的CVS 同理用 .csv 目录来存储的
一般情况下这几个目录是隐藏的防止被随意的删除和修改等在 Windows 上可以通过显示隐藏文件夹来查看Linux 下可以用 ls -ah 命令查看
集中式和分布式的概念
在介绍版本控制工具之前我们还有必要介绍一下集中式版本控制系统和分布式版本控制系统的概念。
集中式版本库是放在一个中央服务器上的干活的时候需要联网才能从服务器下载最新版本到自己电脑上因为大多数时候我们都是在自己电脑上开发开发完后再上传到服务器上。如果网速慢……那就有的等了。好比一个图书馆要看书得先从图书馆里借书用完了后要还回去需要来来回回跑图书馆。
而且集中式容易出现单点故障的问题。万一服务器坏了那么就完了…… 因此得额外对服务器进行备份。
图片来自 集中式 vs 分布式 - 廖雪峰的官方网站
分布式每个人自己的电脑上就有一个完整的版本库获取版本的时候不需要联网。等需要合并文件的时候再将各自的修改上传到中央服务器上。就好比每个人都有一个完整的图书馆如果要合并文件每个人都将自己的修改放到中央图书馆里相当于只用去一次图书馆合并完后每个人再从中央图书馆里更新。
图片来自 集中式 vs 分布式 - 廖雪峰的官方网站
一句话集中式和分布式的区别是你的本地是否有完整的版本库历史。每个人都是本地版本库的主人对版本库的操作包括查看提交日志、提交、创建里程碑和分支、合并分支、回退等所有操作都直接在本地完成而不需要网络连接。
假设 SVN 服务器没了那就丢掉了所有历史信息因为你的本地只有当前版本以及部分历史信息。
假设 Git 的中央服务器没了你不会丢掉任何 git 历史信息因为你的本地有完整的版本库信息。你可以把本地的 git 库重新上传到另外的 git 服务器重新搭建一个「图书馆」。
廖雪峰老师的比喻 比特币的区块链设计就类似 git人手一份全账本只是用 p2p 全网同步而 git 通常搞个中心化服务来同步。 svn 像银行完整账本只有银行有作为终端节点可以向银行查询账本但如果某一天银行没了整个完整账本就没了。 分布式的核心设计是同步而不是主从。 软件架构核心思想其实是非常简单的。
diff 命令
diff 意指 difference。diff 是命令行工具可以通过他们来比较两个文件的差异后续我们学习 Git 的时候也经常用 diff 命令来查看文件的差异diff 可以说是版本控制的基础工具。
我们来看个例子推荐读者一起来实践在 Linux 下实践下该命令。 PS如果没有 Linux 环境读者可以先参考下一篇博客安装好 Git 后然后在 Git Bash 里运行。
先创建两个文件并写入不同内容Windows 用户可以用右键-新建文本文件后打开并输入内容
$echo This is hello file hello.txt
$echo This is world file world.txt
$echo Welcome to diff hello.txt
$echo Welcome to diff world.txt -- 此时文件内容分别如下
$cat hello.txt
This is hello file
Welcome to diff$cat world.txt
This is world file
Welcome to diff
然后我们就可以用 diff 命令来比较两个文件的差异了。我们将差异结果输出到一个文件
$diff -u hello.txt world.txt diff.txt-u 参数很重要它使得差异带有上下文。
我们查看下 diff.txt 的内容
$cat diff.txt
--- hello.txt 2023-01-10 21:56:47.050201742 0800world.txt 2023-01-10 22:08:41.473521836 0800-1,2 1,2
-This is hello file
This is world fileWelcome to diff我们来说明下这个文件的内容
文件的第 1 行和第 2 行分别记录了原始文件和目标文件的文件名及时间戳。以三个减号—开始的行标识的是原始文件以三个加号开始的行标识的是目标文件。文件的第 5,6,7 行以减号-开始的行是只出现在原始文件中的行以加号开始的行是只出现在目标文件中的行以空格开始的行是在原始文件和目标文件中都出现的行
第 4~7 行是一个差异小节就是两个文件之间的一个差异 -1,2 1,2
-This is hello file
This is world file
每个差异小节以一行差异定位语句开始其前后分别用两个 进行标识。其中
-1,2 的含义本差异小节的内容相当于是原始文件从第 1 行开始的 2 行1,2 的含义本差异小节的内容相当于是目标文件从第 1 行开始的 2 行
因为命令 diff 是用于行比较的所以即使一个字不同也显示为一整行的修改Git 对 diff 进行了扩展并且还提供一种逐词比较的差异比较方法。
除了-u 参数diff 还有以下选项就不一一演示了
-b忽略空格-B忽略空行-i忽略大小写-c显示文件所有内容并标识不同-r对比目录
patch 命令
patch 相当于 diff 的反向操作。有了原始文件和 diff 文件就可以还原出目标文件patch 一词有“打补丁”的意思。
我们来实践下首先用 hello.txt 的内容将 world.txt 覆盖这样两个文件的内容都是原始文件的内容
$cp hello.txt world.txt
$cat world.txt
This is hello file
Welcome to diff
然后用 patch 命令来还原目标文件
$patch world.txt diff.txt
patching file world.txt$cat world.txt
This is world file
Welcome to diff可以看到 world 文件回来了。
注意经测试如果 diff 和 patch 的文件中的换行符不是 Linux 环境下的 LF 换行符那么 patch 就会失败笔者推测是这两个命令没有考虑其他换行符的情况报错如下
$ patch world2.txt diff.txt
patching file world2.txt
Hunk #1 FAILED at 1 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file world2.txt.rej
diff 和 patch 小结
严格来说 diff 和 patch 命令不是版本控制工具而是比较差异的工具。
diff 和 patch 命令存在一个局限就是不能对二进制文件进行处理。对二进制文件的修改或添加会在差异文件中缺失进而丢失对二进制文件的改动或添加。
实际上大部分版本控制工具都不能很好的管理二进制文件虽然也能由版本控制工具来管理 但是不能比较两者有什么差异一堆 0 和 1 的比较是看不出来改了什么内容的。
Git 对差异文件格式提供了扩展支持支持二进制文件的比较解决了这个问题。
在没有版本控制系统的情况下可以用这 diff 和 patch 记录并保存改动前后的差异还可以将差异文件注入版本控制系统如果有。
Linus 在 19912002 年就是用 diff 和 patch 维护 Linux 不同版本间差异的。感兴趣的读者可以看看 Linus Torvalds 于 2007 年 5 月 3 日在 Google 的演讲Tech Talk: Linus Torvalds on git - YouTube。
在当时已经有一些版本控制工具了CVS 和 SVN但不好用是集中式版本控制系统而一些商用软件比起 CVS 和 SVN 好用一点但那是收费的与 Linux 的开源精神不符合…… 因此后面 Linus 开发了 Git。
CVS
CVS 的历史CVSConcurrent Versions System诞生于 1985 年是由荷兰阿姆斯特丹 VU 大学的 Dick Grune 教授实现的。当时 Dick Grune 和两个学生共同开发一个项目但是三个人的工作时间无法协调到一起迫切需要一个记录和协同开发的工具软件。于是 Dick Grune 开发出有史以来第一个被大规模使用的版本控制工具。
可以看到CVS 是被逼出来的用人工管理版本太麻烦了没办法才开发出来。
CVS 的特点
最早被广泛使用到现在也有不少人用开源且免费集中式版本控制系统
使用 CVS 管理版本的时候每个目录下面都有一个目录叫做 CVS这样实现起来简单单独拿一个目录出来就可以当作版本库。但 CVS 也有缺点
不能对重命名进行版本控制缺乏对原子提交的支持如果有网络中断或其他不可控因素会导致客户端向服务器端提交不完整的数据这设计就很不合理了最基本的功能有这样的缺陷随着文件的变多效率会越来越慢
CVS 的成功导致了版本控制系统的大爆发各式各样的版本控制系统如雨后春笋般诞生了并且 CVS 的不少理念都成为了后续版本控制的标准。
新的版本控制系统或多或少地解决了 CVS 版本控制系统存在的问题在这些版本控制系统中最典型的就是 Subversion。
SVN
Subversion由于其命令行工具名为 svn因此通常被简称为 SVN。SVN 由 CollabNet 公司于 2000 年资助并开发目的是创建一个更好用的版本控制系统以取代 CVS。
SVN 的前期开发使用 CVS 做版本控制到了 2001 年SVN 已经可以用于自己的版本控制了
SVN 实现了原子提交的功能不会像 CVS 那样出现文件的部分内容被提交而其余的内容没有被提交的情况。
SVN 还有一个创举就是在工作区跟踪目录下.svn 目录为当前目录中的每一个文件都保存一份冗余的原始拷贝。这样做的好处是部分命令不再需要网络连接例如文件修改的差异比较以及错误更改的回退等。
SVN 还有不少闪亮的功能特性使得 SVN 在 CVS 之后诞生的诸多版本控制系统中脱颖而出成为开源社区一时的新宠也成为当时各个企业进行版本控制的最佳选择之一。
但是SVN 在本质上并没有突破都属于集中式版本控制系统在查看日志和提交的时候如果网速慢就很让人抓狂。
对于 CVS 和 SVN 来说笔者在公司内的局域网内用过网速还是可以的。但是论起好用还得是 Git。
Git
书接上文我们来继续介绍 Git。
在 Git 出现之前Linux 之父 Linus 坚决反对使用集中式版本控制工具在 1991-2002 这十余年间Linus 宁可以手工修补文件的方式维护 Linux 的代码。
经过十余年的发展Linux 的代码库已经变的非常大了还用手工维护非常不方便Linux 社区意见也很大。因此在 2002~2005 年期间Linus 选择了一个商业版本控制系统 BitKeeper 作为 Linux 内核的代码管理工具BitKeeper 的东家 BitMover 公司出于人道主义精神授权 Linux 社区免费使用这个版本控制系统。
2005 年发生的一件事最终导致了 Git 的诞生。在 2005 年 4 月Andrew Tridgell即大名鼎鼎的 Samba 的作者试图对 BitKeeper 进行反向工程类似通过反编译等方式获得 BitKeeper 的源码以开发一个能与 BitKeeper 交互的开源工具。这激怒了 BitKeeper 软件的所有者 BitMover 公司要求收回对 Linux 社区免费使用 BitKeeper 的授权。
Linus 可以向 BitMover 公司道个歉保证以后严格管教弟兄们但实际上 Linus 会受这气直接花了两周时间自己用 C 写了一个分布式版本控制系统这就是 Git几个月之内Linux 系统的源码已经由 Git 管理了大家可以体会下什么叫
以下是 Git 诞生过程中的大事记来自维基百科
2005 年 4 月 3 日开始开发 Git。2005 年 4 月 6 日项目发布。2005 年 4 月 7 日Git 就可以作为自身的版本控制工具了。2005 年 4 月 18 日发生第一个多分支合并。2005 年 4 月 29 日Git 的性能就已经达到了 Linus 的预期。2005 年 6 月 16 日Linux 内核 2.6.12 发布那时 Git 已经在维护 Linux 核心的源代码了。
其他版本控制工具
分布式版本控制系统除了 Git 以及促使 Git 诞生的 BitKeeper 外还有类似 Git 的 Mercurial 和 Bazaar 等。这些分布式版本控制系统各有特点但最快、最简单也最流行的依然是 Git
除了之前介绍的版本控制工具还有不少商用版本控制系统占了一部分市场份额。但商用的一般有如下缺陷
采用黑盒子式的版本库设计。大部分商用产品是不会给使用者源码的给了谁还买啊因此让人捉摸不透其内部是怎么实现的也加大了将代码迁移到其他版本库的成本使得企业只能一直用这个产品。商业版本控制工具很难定制化需求因为公司需要赚钱总不能免费帮忙开发需求。商业版本控制工具注定是小众软件专门提供给企业使用培训新员工也很麻烦。
接下来简单说说笔者知道的一些商用工具。
ClearCase
Rational 公司该公司后面被 IBM 收购了出品过 ClearCase 版本控制工具但据说很难用搜索到的评价如下
为什么有些大公司技术弱爆了 - 知乎毕业第一年在腾讯工作做 QQ 游戏大厅当时用的 IDE 是 VC2006用的版本控制工具叫 ClearCase估计用过的人不多IBM 开发的。特点是极其严谨、非常强大但流程极为繁琐用起来简直让人抓狂这还是腾讯花了 3000 万找 IBM 买的。廖雪峰老师点评安装包比 Windows 还大运行比蜗牛还慢能用 ClearCase 的一般是世界 500 强他们有个共同的特点是财大气粗或者人傻钱多。
VSS
微软公司出品的搜索到的相关平均如下 廖雪峰老师点评微软自己也有一个集中式版本控制系统叫 VSS集成在 Visual Studio 中。由于其反人类的设计连微软自己都不好意思用了。 维基百科Microsoft Visual SourceSafe 是美国微软公司出品的版本控制系统简称 VSS。 软件支持 Windows 系统所支持的所有文件格式兼容 Check out-Modify-Check in独占工作模式与 Copy-Modify-Merge并行工作模式。VSS 通常与微软公司的 Visual Studio 产品同时发布并且高度集成。VSS 使用文件系统作为存储方式每次版本变更时就需要大量地读写硬盘。这也是 VSS 最广受垢弊的缺点。 VSS 虽然是微软公司的产品但微软内部却很少使用它。微软内部使用一个名为 SLM 的版本控制系统直至 1999 年。之后微软内部改以使用修改自 Perforce 的 SourceDepot。
小结
本文主要介绍了如下内容
为什么我们需要版本控制集中式和分布式的概念常见的版本控制工具介绍简单演示了下 diff 和 patch 命令简单介绍了版本控制工具的历史
在可以选择的情况下强烈推荐使用 Git 作为版本控制管理工具。
