Git 是一个分布式版本控制工具

最新推荐文章于 2024-09-16 20:54:05 发布

陈三哥

最新推荐文章于 2024-09-16 20:54:05 发布

阅读量4.7k

点赞数

分类专栏： Git 文章标签： git 版本控制工具分布式

本文链接：https://blog.csdn.net/brokge/article/details/52081848

版权

Git 专栏收录该内容

6 篇文章 1 订阅

订阅专栏

Git 是一个分布式版本控制工具

前言：

Git常用命令：速查手册

Git — The stupid content tracker（傻瓜内容跟踪器），Linus 是这样给我们介绍 Git 的。

Git 是用于 Linux 内核开发的版本控制工具。与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持，使源代码的发布和交流极其方便。 Git 的速度很快，这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪（merge tracing）能力。

实际上内核开发团队决定开始开发和使用 Git 来作为内核开发的版本控制系统的时候，世界开源社群的反对声音不少，最大的理由是 Git 太艰涩难懂，从 Git 的内部工作机制来说，的确是这样。但是随着开发的深入，Git 的正常使用都由一些友好的脚本命令来执行，使 Git 变得非常好用，即使是用来管理我们自己的开发项目，Git 都是一个友好，有力的工具。现在，越来越多的著名项目采用 Git 来管理项目开发，例如：wine, U-boot 等。

作为开源自由原教旨主义项目，Git 没有对版本库的浏览和修改做任何的权限限制，通过其他工具也可以达到有限的权限控制，比如：gitosis、CodeBeamer MR。原本 Git的使用范围只适用于 Linux / Unix 平台，但逐步并成熟了在 Windows 平台下的使用，主要归功于Cygwin与msysgit环境与TortoiseGit这样易用的 GUI 工具。其实 Git 的源代码中已经加入了对 Cygwin 与 MinGW 编译环境的支持并被逐步完善，对于 Windows 使用者是个福音。

一、为什么选择Git

对于流行的软件版本开源管理软件，元老级的CVS、后来新秀的SVN，今天我在CHIP.CN Dowload中看到了一篇文章：《2008年度最佳开源软件大奖》（http://download.chip.eu/cn/standardbeitrag_cn_3640079.html）。其中提到了GIT版本管理系统。

我很奇怪，为什么 SVN 没有入围并获奖呢？当初，我在从 CVS 转移到 SVN 时就曾经就 SVN 的一系列优势进行过一些粗浅的学习。SVN 在版本库的管理上较 CVS 有明显的优势。那么与 SVN 相比，Git的优势又在哪里呢？

经过强大的Google，我从网上找到了这些内容：

From 《Git入门教程》：（http://hi.baidu.com/eehuang/blog/item/37af8d54242d6351564e00b5.html）

傻瓜都会的初始化，git init, git commit -a, 就完了。对于随便写两行代码就要放到代码管理工具里的人来说，再合适不过。也可以拿git做备份系统，或者同步两台机器的文档，都很方便。
绝大部分操作在本地完成，不用和集中的代码管理服务器交互，终于可以随时随地大胆地check in代码了。只有最终完成的版本才需要向一个中心的集中的代码管理服务器提交。
每次提交都会对所有代码创建一个唯一的commit id。不像CVS那样都是对单个文件分别进行版本的更改。所以你可以一次性将某次提交前的所有代码check出来，而不用考虑到底提交过那些文件。（其实SVN也可以做到这点）
branch管理容易多了，无论是建立新的branch，还是在branch之间切换都一条命令完成，不需要建立多余的目录。
branch之间merge时，不仅代码会merge在一起，check in历史也会保留，这点非常重要。

1、更方便的 Merge

分布式管理必然导致大量的 Branch 和 Merge 操作。因此分布式版本控制系统都特别注意这方面。在传统的 CVS 里面制作 Branch 和 Merge 简直就是噩梦，Subversion 作为一个用于替代 CVS 的系统，专门改进了 Branch 操作。然而似乎人们没有注意到，Branch 是轻松了，可是 Merge 呢？如果不能很方便地 Merge 回来，做 Branch 仍然是噩梦。事实上，我就经历过在开发团队里面由于队友操作不对而在 Merge 的时候把我的许多代码都覆盖掉了。当时正是使用的 subversion 。虽然源代码仍然在历史里面，但是要去一个一个地找出被覆盖掉的文件并恢复过来确实是一件很难忘的事情。

2、更方便的管理

传统的版本控制系统使用中央仓库，一些仓库相关的管理就只能在仓库上进行。赋予开发团队每一个人中央仓库的管理权限是非常不好的。但是有时候确实会比较不方便的地方。

3、更健壮的系统

分布式系统一般情况下总是比单服务端的系统要健壮，因为当服务端一旦挂掉了整个系统就不能运行了。然而分布式系统通常不会因为一两个节点而受到影响。

4、对网络的依赖性更低

虽然现在网络非常普及，但是并不是随时随地都有高速网络，甚至有时候根本没有网络可以访问。低速的网络会让人心情烦躁，有时候就呆呆地盯着屏幕上的 commit 进度，什么事情也干不了。而没有网络连接更是致命的：你无法 commit ！这表示你进行任何改动以前都必须小心翼翼，否则你可能再也找不会你曾经写的一些代码了。

5、更少的“仓库污染”

有时候你要做一个模块，它不是太大，所以没有必要为它新建一个 branch ，但是它又不是那么小，不可能一次提交就做好。于是便会提交一些不完整的代码到仓库，有时候会导致整个程序无法运行，严重影响团队里其他人的开发。大多数人在这种情况下的解决办法都是写完之后再提交。但是作为习惯了版本控制的人来说，进行不计后果的大幅修改是经常的事情，到后来突然发现自己先前的代码没有提交，就后悔莫及了。如果是分布式系统的话就不会存在这样的问题，因为本地仓库的修改不会影响到别人的仓库。当你完成并测试以后，就可以在邮件列表里面说：我已经把这个模块做好了。然后感兴趣的人就可以从你这里 pull 你的成果了。

虽然网上各种对Git的誉美之词决不止于此，但是在Git的主站上，还是尽可能客观的对Git和Subversion进行了一番比较。（GitSvnComparsion：http://git.or.cz/gitwiki/GitSvnComparsion）。另外，Subversion目前通过SVK也已经提供了一定程度上的源代码库分布式的管理能力。能够实现源代码的离线提交等功能。

二、Git与CVS 的区别

分支更快、更容易。
支持离线工作；本地提交可以稍后提交到服务器上。
Git 提交都是原子的，且是整个项目范围的，而不像 CVS 中一样是对每个文件的。
Git 中的每个工作树都包含一个具有完整项目历史的仓库。
没有哪一个 Git 仓库会天生比其他仓库更重要。

Git 不仅仅是个版本控制系统，它也是个内容管理系统(CMS)、工作管理系统等。如果你是一个具有使用SVN背景的人，你需要做一定的思想转换，来适应GIT提供的一些概念和特征。所以，这篇文章的主要目的就是通过介绍GIT能做什么、它和SVN在深层次上究竟有什么不同来帮助你认识它。那好，这就开始吧…

GIT是分布式的，SVN不是

这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。如果你能理解这个概念，那么你就已经上手一半了。需要做一点声明，GIT并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如Bitkeeper, Mercurial等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。

GIT 跟SVN一样有自己的集中式版本库或服务器。但GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。

同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。GitHub.com就是一个这样的优秀案例。

有些谣言传出来说subversion将来的版本也会基于分布式模式。但至少目前还看不出来。
GIT把内容按元数据方式存储，而SVN是按文件

所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它们差距很大。因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。
GIT分支和SVN的分支不同

分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn propget svn:mergeinfo，来确认代码是否被合并。感谢Ben同学指出这个特征。所以，经常会发生有些分支被遗漏的情况。

然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。
GIT没有一个全局的版本号，而SVN有

目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道，SVN的版本号实际是任何一个相应时间的源代码快照。我认为它是从CVS进化到SVN的最大的一个突破。因为GIT和SVN从概念上就不同，我不知道GIT里是什么特征与之对应。如果你有任何的线索，请在评论里奉献出来与大家共享。

更新：有些读者指出，我们可以使用GIT的SHA-1来唯一的标识一个代码快照。这个并不能完全的代替SVN里容易阅读的数字版本号。但，用途应该是相同的。
GIT的内容完整性要优于SVN

GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。这里有一个很好的关于GIT内容完整性的讨论 –http://stackoverflow.com/questions/964331/git-file-integrity

GIT和SVN之间只有这五处不同吗？当然不是。我想这5个只是“最基本的”和“最吸引人”的，我只想到这5点。如果你发现有比这5点更有趣的，请共享出来，欢迎。

三、常用版本控制工具比较-GIT、CVS、SVN

首先介绍几个版本控制软件相互比较的重要依据，更详细的比较请参考文中链接：

版本库模型（Repository model）: 描述了多个源码版本库副本间的关系，有客户端/服务器和分布式两种模式。在客户端/服务器模式下，每一用户通过客户端访问位于服务器的主版本库，每一客户机只需保存它所关注的文件副本，对当前工作副本（working copy）的更改只有在提交到服务器之后，其它用户才能看到对应文件的修改。而在分布式模式下，这些源码版本库副本间是对等的实体，用户的机器出了保存他们的工作副本外，还拥有本地版本库的历史信息。
并发模式（Concurrency model）: 描述了当同时对同一工作副本/文件进行更改或编辑时，如何管理这种冲突以避免产生无意义的数据，有排它锁和合并模式。在排它锁模式下，只有发出请求并获得当前文件排它锁的用户才能对对该文件进行更改。而在合并模式下，用户可以随意编辑或更改文件，但可能随时会被通知存在冲突（两个或多个用户同时编辑同一文件），于是版本控制工具或用户需要合并更改以解决这种冲突。因此，几乎所有的分布式版本控制软件采用合并方式解决并发冲突。
历史模式（History model）：描述了如何在版本库中存贮文件的更改信息，有快照和改变集两种模式。在快照模式下，版本库会分别存储更改发生前后的工作副本；而在改变集模式下，版本库除了保存更改发生前的工作副本外，只保存更改发生后的改变信息。
变更范围（Scope of change）：描述了版本编号是针对单个文件还是整个目录树。
网络协议（Network protocols）：描述了多个版本库间进行同步时采用的网络协议。
原子提交性（Atomic commit）：描述了在提交更改时，能否保证所有更改要么全部提交或合并，要么不会发生任何改变。
部分克隆（Partial checkout/clone）：是否支持只拷贝版本库中特定的子目录。