进入我的博客阅读体验更好哦！博客文章链接：为什么你需要Git? (lxq.icu)
前言
也许你没有听说过Git，但你一定或多或少听说过GitHub——一个基于Git的世界最大的开发平台。GitHub顾名思义，Git指的显然就是Git工具，而Hub表明了其汇总、统筹的作用，指明了其平台的属性。当然，GitHub本质来说实际是Git+互联网所诞生的一个产物，Git作为一种版本控制工具，远程仓库仅仅是它其中一项用途，其分布式的特点，强大的分支功能和优秀的内存组织形式等优点使得它在一众版本控制工具中脱颖而出，在管理软件项目、推进软件开发上起到了至关重要的作用。
版本控制与Git
首先，与GitHub中Git的第一印象（也许更像一种传输协议？）不同，Git是一种优秀的版本控制工具，广泛的被用于工程实践中。其次，版本控制工具不仅仅有Git一种，根据不同的使用场合版本控制工具不一定会选用Git，但毫无疑问，Git的优势足以胜任绝大多数任务。可能其唯一的缺点就是上手门槛较高（比起庞大复杂的图形化管理工具，Git更像是一个属于程序员的优秀简洁的命令行工具）。最后，随着版本控制需求的不断增长，Git也有可能被淘汰，但其所蕴含的版本控制智慧却不会消亡。
什么是版本控制工具？
随软件项目的日趋庞大、复杂，对不同软件版本进行管理和控制的需求也随之增加，为回应这种需求，版本控制工具应运而生。版本控制的任务是对目标在不同时期表现出的状态进行记录和维护，根据实际应用背景选择合适的版本间的拓扑结构。具体来说就是具有生成新版本、保证个版本间的协调独立、有效记录不同版本的状态、正确切换版本的功能。版本控制的作用主要表现在两方面：一是有助于实现并行开发，提高效率； 二是能够有效记录在不同时期软件开发过程中产生的各类工件，保证在需要时能够回溯版本，减少由于工件丢失、修改记录丢失以及相互覆盖的损失，达到有效保护项目数字资产的目的。[1]
并行开发
在此着重解释下并行开发。
在我看来版本控制所说的并行开发主要有两层含义：
-
从传统版本控制工具的角度来说，并行就是实现多版本同时进行，并在版本间建立合适的拓扑关系。拿游戏开发举例，当前版本是1.0，测试版本是1.1，现在需要将版本更新到2.0，但这并不意味着要丢弃1.1开发的内容，借助版本控制工具可以先行更新2.0，在将来的版本中合并1.1。
-
从Git这类分布式的工具的角度来说，并行开发同时还意味着多人同时开发。相较于集中式的版本控制工具（如接下来要论述的SVN）只有一个版本库，分布式的工具有着多个独立的版本库，这就使得能够本地化地进行多人并行开发。
Git历史
Git源于2005年Linux社区的一件不愉快的往事：蒸蒸日上的Linux内核开发团队与其采用的版本控制软件BitKeeper的开发商交恶，失去了BitKeeper的使用权，于是Linux之父——Linus Torvalds不得不寻求替代方案。但在当时现有的开源软件中他并没有找到合适的替代工具，最终他决定自己写一个，这就是Git。Git在之后经过Linux内核开发团队和Linux社区的众多开发者的改进和迭代，如今越来越受到个人和团队开发者的青睐。
不过，Git的原生环境毕竟是Linux，这也导致了Git被移植到Windows后一度表现不佳。
从比较中看Git
没有比较就无法体现Git的优越性，也就无法说明Git何以被众多开发者所青睐。
SVN作为典型的集中式版本控制工具常常被用来与Git作比：
这张图截自Git官网，左侧第一列是各操作的名称，中间一列是操作的规模，右侧三列分别是Git的耗时，SVN的耗时以及SVN耗时相较于Git耗时的倍数。
很明显，从图中我们可以看出Git在所有操作的表现中都优于SVN，当然其中的原因不尽相同。接下来我主要从三个方面比较Git与SVN：
存储
存储方式
SVN与Git最根本的区别在于SVN是集中式系统而Git是分布式系统。
SVN将文件存储在一个中央服务器中，开发者通过客户端连到这台服务器，取出最新的文件或者提交更新。集中式系统可以清晰地看到工作的实时进展状况，但严重依赖于客户端和服务器的网络连接。SVN在冲突解决中表现较差，后提交的人可能会遇上版本库在工作期间更新而导致的冲突。此外由于集中式系统的文件存储在一个服务器中，若服务器宕机则工作无法进展；若服务器操作不当则有文件丢失的风险。
每一个使用Git的开发者都有一个独立的版本库，开发者可以本地进行更新、修改，再通过网络提交到远程仓库。Git在冲突解决中不存在先后问题，而是根据需要进行冲突解决，同时由于版本库的低耦合，减少了溯源、调试的工作量。此外，多个版本库意味着Git有多个备份，不存在文件丢失的风险。
版本库
SVN由于其集中存储的特点，只有一个中央服务器维持一个版本库。
Git由于其每一个开发者都有一个独立的版本库，所以理论上Git拥有无限个版本库。
记录方式
SVN记录文件的具体差异，例如在用户提交的内容前后，文件某一行或某一个文件进行了增删操作。
Git并不保存用户提交内容的前后差异，而是存储在某个时间的快照(snapshot)。快照的作用就相当于将旧文件所占的空间保留下来，并且保存一个引用，而新文件中会继续使用与旧文件内容相同部分的磁盘空间，不同部分则写入新的磁盘空间。总的来说，Git其实也算是记录差异，只不过是在文件系统层次上实现的。
速度
分支模式
SVN 的分支是拷贝的目录，而Git的分支是一个指向某次提交的指针。所以SVN的分支昂贵，而 Git 的分支切换非常迅速，且创建成本非常低。当然，Git之所以能使用指针是因为其优秀的内存组织形式。
网络依赖
SVN的读取和更新都严重依赖于网络，但Git由于其分布式的特点，可以本地进行各种操作，只需要在需要合并的时候通过网络与远程仓库链接即可。
安全
内容完整性
SVN的版本库在服务器上，所以在底层原理上并没有采用一些方法保证内容的完整性。
Git从底层原理来看，采用哈希表进行查找、通过简单的存储键值对的方式来实现内容寻址，key就是文件（头 +内容）的哈希值（采用sha-1的方式，40 位），value就是经过压缩后的文件内容。[2]
K
e
y
=
s
h
a
1
(
f
i
l
e
_
h
e
a
d
e
r
+
f
i
l
e
_
c
o
n
t
e
n
t
)
V
a
l
u
e
=
z
l
i
b
(
f
i
l
e
_
c
o
n
t
e
n
t
)
Key=sha1(file\_header+file\_content)\\ Value=zlib(file\_content)
Key=sha1(file_header+file_content)Value=zlib(file_content)
即Git使用Sha-1算法保证了内容的完整性。
数据安全
从集中式和分布式的特点来看：
SVN的数据保存在服务器中，一旦服务器出现故障那么将会面临数据的丢失。
Git理论上有无限个版本库，任意一个版本库就可以还原数据，所以不存在数据丢失的危险。
图表总结
Git特点总结
Git的官方介绍中总结了Git的几个特点：
-
Branching and Merging——分支和合并
得益于Git版本库的本地化，Git不再局限于版本控制。平滑的分支切换、独立的创建删除操作和极低的试错成本使得Git具备了作为分享和学习工具的潜质。
-
Small and Fast——精简而迅速
首先，Git本地化的操作使得其相较依赖网络的集中式系统具有巨大的优势；其次，Git是为在Linux内核上工作而构建的，这意味着它从一开始就必须有效地处理大型存储库；再者，Git是用C编写的，这也减少了其与高级语言通信的开销；最后，也是最关键的一点，从一开始，速度和性能就一直是Git的主要设计目标。（当然，这一定程度也导致了Git较高的学习门槛）
-
Distributed——分布式
多版本库、多分支是分布式的直观体现，但文档在此也提出了分布式并不意味着不集中。分布式的Git同样可以通过设置一个集成管理器或者通过管理员来集中更新和维护一个统一的版本库。
-
Data Assurance——数据保证
此处的数据保证与前文所说的内容完整性所指相同，即Git在底层原理中采用了Sha-1算法保证了内容的完整性。
-
Staging Area——暂存区
如图所示，Git在本地的版本库与远程仓库间有一个暂存区。一方面暂存区是适应Git本地化的工作方式，另一方面暂存区可以允许部分地提交修改而非每一次都提交所有修改（即使有些修改是你暂时不愿提交的）。
-
Free and Open Source——免费且开源
如果说要为一款功能强大又易于操作的软件加上一个前提，那么毫无疑问我希望是免费且开源，所幸Git就是这样一个工具。
Reference
[1]王真.版本控制工具在软件开发项目管理中的应用——以GIT为例[J].项目管理技术,2020,18(06):131-134.
[2]庞双玉.Git分布式版本控制实现机制探讨[J].信息系统工程,2018(10):53-54.
1673
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
