介绍

1.1 版本控制
1.2 历史
1.3 根底
1.4 装置
1.5 配置

1.1 版本控制

1.1.1 概述:

版本控制是指对软件开发过程中各种程序代码、配置文件及阐明文档等文件变更的治理,是软件配置管理的核心思想之一。

1.1.2 简述:

版本控制最次要的性能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠诚地了记录下来。每一次文件的扭转,文件的版本号都将减少。除了记录版本变更外,版本控制的另一个重要性能是并行开发。软件开发往往是多人协同作业,版本控制能够无效地解决版本的同步以及不同开发者之间的开发通信问题,进步协同开发的效率。并行开发中最常见的不同版本软件的谬误(Bug)修改问题也能够通过版本控制中分支与合并的办法无效地解决。

1.1.3 控制系统进化问题以及解决形式:

本地式版本控制系统:

在一台服务器依据目录的工夫进行备份。

益处:

简略

害处:

一旦操作出错,所有的文件将全副失落。

问题:

不能让在不同零碎中的开发者协同工作。

集中式版本控制系统

将所有的文件放在一台服务器上进行治理。

益处:

能够看到我的项目中其他人的工作进度。管理员能够把握开发者的权限。

害处:

服务器宕机,所有人对文件都不能操作,如果服务器产生故障,容易造成数据的失落。

问题:

外围服务器宕机,所有工作人员不能进行文件的操作。

分布式版本控制系统:

分布式版本控制系统有:Git,Mercurial,Bazaar 以及 Darcs 等,客户端并不是提取最新版本的文件快照,而是把代码仓库残缺的镜像下来。这样,任何一处协同工作用的服务器产生故障,预先都能够用任何一个镜像进去本地仓库进行复原。因为每一次的提取操作,都是一次对代码的残缺备份。

1.2 历史

版本最后公布日期最新订正版本最新订正版本公布日期
0.992005-07-110.99.9n2015-12-15
1.02005-12-211.0.132006-01-27
1.12006-01-081.1.62006-01-30
1.22006-02-121.2.62006-04-08
1.32006-04-181.3.32006-05-16
1.42006-06-101.4.4.52008-07-16
1.52007-02-141.5.6.62008-12-17
1.62008-08-171.6.6.32010-12-15
1.72010-02-131.7.12.42012-10-17
1.82012-10-211.8.5.62014-12-17
1.92014-02-141.9.52014-12-17
2.02014-05-282.0.52014-12-17
2.12014-08-162.1.42014-12-17
2.22014-11-262.2.32015-09-04
2.32015-02-052.3.102015-09-29
2.42015-04-302.4.122017-05-05
2.52015-07-272.5.62017-05-05
2.62015-09-282.6.72017-05-05
2.72015-10-042.7.62017-07-30
2.82016-03-282.8.62017-07-30
2.92016-06-132.9.52017-07-30
2.102016-09-022.10.52017-09-22
2.112016-11-292.11.42017-09-22
2.122017-02-242.12.52017-09-22
2.132017-05-102.13.72018-05-22
2.142017-08-042.14.52018-09-27
2.152017-10-302.15.32018-09-27
2.162018-01-172.16.52018-09-27
2.172018-04-022.17.22018-09-27
2.182018-06-212.18.12018-09-27
2.192018-09-102.19.22018-11-21
2.202018-12-092.20.12018-12-15
2.212019-02-242.21.02019-02-24
2.222019-06-072.22.02019-06-07
2.232019-08-162.23.12019-12-07
2.242019-11-042.24.12019-12-07
2.252020-01-132.25.12020-02-17

1.3 根底

1.3.1 间接记录快照,并非差别比拟

Git 和其余控制系统相比,Git 只关怀文件数据的整体是否产生了变动,而大多数其余零碎则关怀文件的内容的具体差别。

  • 图 1.3 other

Git 不保留这些前后变动的差别数据。Git 更像是把变动的文件作快照后,记录在一个微型文件零碎中。每次提交更新时,他会纵览一遍所有文件的指纹信息并对文件作一个快照,而后保留一个指向快照的索引。为了进步性能,如果文件没有变动,Git不会保留,而是对上次保留到快照做一个链接。

  • 图 1.4 other

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

Git 大多数的操作都是在本地进行,不必联网。如果是用cvcs(集中式管理系统),基本上所有的操作都是须要联网的,因为 Git 在本地磁盘上就保留了所有以后我的项目的历史更新记录,所以解决起来速度比拟快。

1.3.3 时刻放弃数据完整性

在保留到 Git 之前,所有的数据都要进行内容的校验和计算,并将后果作为数据的惟一标识和索引。不可能在你批改了文件或者目录之后,Git 无所不知,这个个性作为 Git 的设计哲学,建设在整体架构的最底层。所以如果文件在传输变得不残缺或者磁盘损坏导致文件数据缺失, Git 可能立刻觉察。通过sha1算法进行目录和文件的加密,所以在 Git 中常常看到 24b9da6552252987aa493b52f8696cd6d3b00373 数据。

1.3.4 多数据操作仅增加数据

常见的 Git 操作仅仅把数据增加到数据库中,因为任何一种不可逆操作,比方删除数据,都会使回退或者重现历史版本变得困难重重。在 Git 中一旦提交快照齐全不须要放心数据失落。

1.3.5 文件的状态转化

Untracked

  • 未跟踪, 此文件在文件夹中, 但并没有退出到git库, 不参加版本控制. 通过git add 状态变为Staged。

Unmodify

  • 文件曾经入库, 未修改, 即版本库中的文件快照内容与文件夹中完全一致. 这种类型的文件有两种去处, 如果它被批改, 而变为Modified. 如果应用git rm移出版本库, 则成为Untracked文件。

Modified

  • 文件已批改, 仅仅是批改, 并没有进行其余的操作. 这个文件也有两个去处, 通过git add可进入暂存staged状态, 应用git checkout 则抛弃批改过, 返回到unmodify状态, 这个git checkout即从库中取出文件, 笼罩以后批改。

Staged

  • 暂存状态. 执行git commit则将批改同步到库中, 这时库中的文件和本地文件又变为统一, 文件为Unmodify状态. 执行git reset HEAD filename勾销暂存, 文件状态为Modified。

1.4 装置

1.4.1 源码装置

        # 装置依赖        $ yum install curl-devel expat-devel gettext-devel \    openssl-devel zlib-devel        $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \        libz-dev libssl-dev        # 获取最新的源码        http://git-scm.com/download        # 编译装置        $ tar -zxf git-1.7.2.2.tar.gz        $ cd git-1.7.2.2        $ make prefix=/usr/local all        $ sudo make prefix=/usr/local install        # 下载我的项目        git clone <url>

1.4.2 linux装置

        $ yum install git-core        $ apt-get install git

1.4.3 mac装置

        # 笨蛋形式装置        http://code.google.com/p/git-osx-installer

1.5 配置

1.5.1 初始化配置信息

        # 全局增加用户名和邮箱        $ git config --global user.name "用户名"        $ git config --global user.email "邮箱"        # 依据我的项目增加        $ git config  user.name "用户名"        $ git config  user.email "邮箱"        # 查看配置信息        $ git config  --list