关于版本控制

版本控制(VCS)是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。

本地版本控制系统

大多都是采用某种简单的数据库来记录文件的历次更新差异。其中最流行的一种叫做 RCS,现今许多计算机系统上都还看得到它的踪影。 甚至在流行的 Mac OS X 系统上安装了开发者工具包之后,也可以使用 rcs 命令。 它的工作原理是在硬盘上保存补丁集(补丁是指文件修订前后的变化);通过应用所有的补丁,可以重新计算出各个版本的文件内容。

  • 优点:简单。
  • 缺点:容易犯错。 有时候会混淆所在的工作目录,一不小心会写错文件或者覆盖意想外的文件。

集中化版本控制系统

集中化的版本控制系统(Centralized Version Control Systems,CVCS)可让在不同系统上的开发者协同工作。这类系统,诸如 CVS、Subversion 以及Perforce 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。

  • 优点:每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限,并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
  • 缺点:中央服务器的单点故障。 如果宕机一小时,那么在这一小时内,谁都无法提交更新,也就无法协同工作。 如果中心数据库所在的磁盘发生损坏,又没有做恰当备份,毫无疑问你将丢失所有数据——包括项目的整个变更历史,只剩下人们在各自机器上保留的单独快照。 本地版本控制系统也存在类似问题,只要整个项目的历史记录被保存在单一位置,就有丢失所有历史更新记录的风险。

分布式版本控制系统

分布式版本控制系统(Distributed Version Control System, DVCS)在这类系统中,像Git、Mercurial、Bazaar 以及 Darcs 等,客户端并不只提取最新版本的文件快照,而是把码仓库完整地镜像下来。 这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份。

  • 优点:这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此,你就可以在同一个项目中,分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程,比如层次模型式的工作流,而这在以前的集中式系统中是无法实现的。

Git基础

直接记录快照,而非差异比较

Git和其它版本控制系统(包括 Subversion 和近似工具)的主要差别在于Git对待数据的方法。Git是把数据看作是对小型文件系统的一组快照。每次你提交更新,或在Git中保存项目状态时,它主要对当时的全部文件制作一个快照并保存这个快照的索引。 为了高效,如果文件没有修改,Git 不再重新存储该文件,而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 快照流。

近乎所有操作都是本地执行

在Git中的绝大多数操作都只需要访问本地文件和资源,一般不需要来自网络上其它计算机的信息。

Git保证完整性

Git中所有数据在存储前都计算校验和,然后以校验和来引用。这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层,是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件,Git 就能发现。

Git用以计算校验和的机制叫做SHA-1散列(hash,哈希)。这是一个由40个十六进制字符(0-9 和 a-f)组成字符串,基于 Git 中文件的内容或目录结构计算出来。 SHA-1 哈希看起来是这样:

<p     24b9da6552252987aa493b52f8696cd6d3b00373

Git中使用这种哈希值的情况很多,你将经常看到这种哈希值。实际上,Git数据库中保存的信息都是以文件内容的哈希值来索引,而不是文件名。

Git一般只添加数据

执行的Git操作,几乎只往Git数据库中增加数据。很难让Git执行任何不可逆操作,或者让它以任何方式清除数据。

三种状态

Git有三种状态,你的文件可能处于其中之一:已提交(committed)、已修改(modified)和已暂存(staged)。 已提交表示数据已经安全的保存在本地数据库中。 已修改表示修改了文件,但还没保存到数据库中。 已暂存表示对一个已修改文件的当前版本做了标记,使之包含在下次提交的快照中。

由此引入Git项目的三个工作区域的概念:Git仓库、工作目录以及暂存区域。

  1. Git仓库目录是Git用来保存项目的元数据和对象数据库的地方。 这是Git中最重要的部分,从其它计算机克隆仓库时,拷贝的就是这里的数据。
  2. 工作目录是对项目的某个版本独立提取出来的内容。 这些从Git仓库的压缩数据库中提取出来的文件,放在磁盘上供你使用或修改。
  3. 存区域是一个文件,保存了下次将提交的文件列表信息,一般在Git仓库目录中。有时候也被称作‘索引’,不过一般说法还是叫暂存区域。

基本的Git工作流程如下:

  • 在工作目录中修改文件。
  • 暂存文件,将文件的快照放入暂存区域。
  • 提交更新,找到暂存区域的文件,将快照永久性存储到 Git 仓库目录。

如果Git目录中保存着的特定版本文件,就属于已提交状态。如果作了修改并已放入暂存区域,就属于已暂存状态。如果自上次取出后,作了修改但还没有放到暂存区域,就是已修改状态。

安装Git

Debian/Ubuntu

    
$ sudo apt-get install git
$ sudo add-apt-repository ppa:git-core/ppa
$ sudo apt update
$ sudo apt install git

从源代码安装

  • 需要安装 Git 依赖的库:curl、zlib、openssl、expat,还有libiconv。
    
$ sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \libz-dev libssl-dev
  • 添加更多格式的文档(如 doc, html, info),安装以下的依赖包
    
$ sudo apt-get install asciidoc xmlto docbook2x

当你安装好所有的必要依赖,你可以继续从几个地方来取得最新发布版本的 tar 包。 你可以从 Kernel.org 网站获取,网址为 https://www.kernel.org/pub/software/scm/git,或从 GitHub 网站上的镜像来获得,网址为https://github.com/git/git/releases。接着,编译并安装:

    
$ tar -zxf git-2.0.0.tar.gz
$ cd git-2.0.0
$ make configure
$ ./configure --prefix=/usr
$ make all doc info
$ sudo make install install-doc install-html install-info

Git升级

    
$ git clone git://git.kernel.org/pub/scm/git/git.git

初次运行Git前配置

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。 这些变量存储在三个不同的位置:

  1. /etc/gitconfig 文件: 包含系统上每一个用户及他们仓库的通用配置。如果使用带有 --system 选项的git config 时,它会从此文件读写配置变量。
  2. ~/.gitconfig 或 ~/.config/git/config 文件:只针对当前用户。可以传递 --global 选项让Git读写此文件。
  3. 当前使用仓库的 Git 目录中的 config 文件(就是 .git/config):针对该仓库每一个级别覆盖上一级别的配置,所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。

在 Windows 系统中,Git 会查找 $HOME 目录下(一般情况下是 C:\Users\$USER)的 .gitconfig 文件。Git 同样也会寻找 /etc/gitconfig 文件,但只限于 MSys 的根目录下,即安装 Git 时所选的目标位置。

用户信息

设置你的用户名称与邮件地址。因为每一个 Git 的提交都会使用这些信息,并且它会写入到你的每一次提交中,不可更改。

    
$ git config --global user.name "xxx"
$ git config --global user.email xxx

若使用 --global 选项,那么该命令只需要运行一次,因为之后无论你在该系统上做任何事情, Git 都会使用那些信息。 当你想针对特定项目使用不同的用户名称与邮件地址时,可以在那个项目目录下运行没有 --global 选项的命令来配置。

文本编辑器

未配置文本编辑器,Git 会使用操作系统默认的文本编辑器,通常是 Vim。想安装不同文本编辑器。

    
$ git config --global core.editor 文本编辑器名

检查配置信息

检查所有的Git配置

    
$ git config --list

检查Git某一项配置

    
$ git config key_name

获取帮助

    
$ git help <verb>
$ git <verb> --help
$ man git-<verb>
$ git help config
05-11 17:12