版本控制概述（Git入门）

Posted 2022-10-20

简介

版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地了记录下来。每一次文件的改变，文件的版本号都将增加。除了记录版本变更外，版本控制的另一个重要功能是并行开发。

[软件开发]往往是多人协同作业，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题，提高协同开发的效率。并行开发中最常见的不同版本软件的错误(Bug)修正问题也可以通过版本控制中分支与合并的方法有效地解决。

具体来说，在每一项开发任务中，都需要首先设定开发基线，确定各个配置项的开发初始版本，在开发过程中，开发人员基于开发基线的版本，开发出所需的目标版本。当发生需求变更时，通过对变更的评估，确定变更的影响范围，对被影响的配置项的版本进行修改，根据变更的性质使配置项的版本树继续延伸或产生新的分支，形成新的目标版本，而对于不受变更影响的配置项则不应发产生变动。同时，应能够将变更所产生的对版本的影响进行记录和跟踪。必要时还可以回退到以前的版本。例如当开发需求或需求变更被取消时，就需要有能力将版本回退到开发基线版本。在曾经出现过的季度升级包拆包和重新组包的过程中，其实就是将部分配置项的版本回退到开发基线，将对应不同需求的不同分支重新组合归并，形成新的升级包版本。

版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段。还需要定义、收集一些元数据来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。当然如果选用的工具支持，这些辅助数据将能直接统计出过程数据，从而方便软件过程改进活动的进行。对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行操作。

版本操作及相关的工具

版本控制包括：检入检出控制、分支和合并、历史记录。

1．检入检出控制

软件开发人员对源文件的修改不能在软件配置管理库中进行，对源文件的修改依赖于基本的文件系统并在各自的工作空间下进行。为了方便软件开发，需要不同的软件开发人员组织各自的工作空间。一般说来，不同的工作空间由不同的目录表示，而对工作空间的访问，由文件系统提供的文件访问权限加以控制。

访问控制需要管理各个人员存取或修改一个特定软件配置对象的权限。开发人员能够从库中取出对应项目的配置项进行修改，并检入到软件配置库中，对版本进行“升级”；配置管理人员可以确定多余配置项并删除。

同步控制的实质是版本的检入检出控制。检入就是把软件配置项从用户的工作环境存入到软件配置库的过程，检出就是把软件配置项从软件配置库中取出的过程。检人是检出的逆过程。同步控制可用来确保由不同的人并发执行的修改不会产生混乱。

2．分支和合并

版本分支(以一个已有分支的特定版本为起点，但是独立发展的版本序列)的人工方法就是从主版本——称为主干上拷贝一份，并做上标记。在实行了版本控制后，版本的分支也是一份拷贝，这时的拷贝过程和标记动作由版本控制系统完成。版本合并(来自不同分支的两个版本合并为其中一个分支的新版本)有两种途径，一是将版本A的内容附加到版本B中；另一种是合并版本A和版本B的内容，形成新的版本C。

3．历史记录

版本的历史记录有助于对软件配置项进行审核，有助于追踪问题的来源。历史记录包括版本号、版本修改时间、版本修改者、版本修改描述等最基本的内容，还可以有其他一些辅助性内容，比如版本的文件大小和读写属性。

版本控制基本流程如下：

(1)创建配置项。

项目成员依据《配置管理计划》，在配置库中创建属于其任务范围内的配置项。此时配置项的状态为“草稿”，其版本号格式为0.YZ。

(2)修改状态为“草稿”的配置项目。

项目成员使用配置管理软件的Check in/check out功能，可以自由修改处于“草稿”状态的配置项，版本号格式为0.YZ。

(3)技术评审或领导审批。

如果配置项是技术文档，则需要接受技术评审。如果配置项是“计划”这类文件，则需要项目经理(或上级领导)的审批。若配置项通过了技术评审或领导审批，则转向下一步·否则转回上一步。

(4)正式发布。

配置项通过技术评审或领导审批之后。则配置项的状态从“草稿”变为“正式发布”，版本号格式为X.Y。

(5)变更。

修改处于“正式发布”状态的配置项，必须按照“变更控制流程”执行。

开放源码的版本控制工具有很多，如Concurrent Versions System( CVS)、Subversion( SVN)、Vesta、Revision Control System( RCS)、Source Code Control System( SCCS)等。比较常用的两个工具是CVS和SVN。CVS是Dick Grune在1984年～1985年基于RCS开发的一个客户一服务器架构的版本控制软件，长久以来一直是免费版本控制软件的主要选择。SVN的一个重要开发目标是修正CVS中广为人知的缺点，提供一个新的版本控制软件。对于中小规模团队，SVN是一个比较好的开源版本控制工具，SVN常用客户端工具为TortoiseSVN。

git简介

Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。

Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。

Git 与 SVN 区别

Git 不仅仅是个版本控制系统，它也是个内容管理系统(CMS)，工作管理系统等。

如果你是一个具有使用 SVN 背景的人，你需要做一定的思想转换，来适应 Git 提供的一些概念和特征。

Git 与 SVN 区别点：

• 1、Git 是分布式的，SVN 不是：这是 Git 和其它非分布式的版本控制系统，例如 SVN，CVS 等，最核心的区别。
• **2、Git 把内容按元数据方式存储，而 SVN 是按文件：**所有的资源控制系统都是把文件的元信息隐藏在一个类似 .svn、.cvs 等的文件夹里。
• **3、Git 分支和 SVN 的分支不同：**分支在 SVN 中一点都不特别，其实它就是版本库中的另外一个目录。
• **4、Git 没有一个全局的版本号，而 SVN 有：**目前为止这是跟 SVN 相比 Git 缺少的最大的一个特征。
• **5、Git 的内容完整性要优于 SVN：**Git 的内容存储使用的是 SHA-1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。

Git工作流程

一般工作流程如下：

• 克隆 Git 资源作为工作目录。
• 在克隆的资源上添加或修改文件。
• 如果其他人修改了，你可以更新资源。
• 在提交前查看修改。
• 提交修改。
• 在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。

下图展示了 Git 的工作流程：

Git 工作区、暂存区和版本库

我们先来理解下 Git 工作区、暂存区和版本库概念：

• **工作区：**就是你在电脑里能看到的目录。
• **暂存区：**英文叫 stage 或 index。一般存放在 .git 目录下的 index 文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
• **版本库：**工作区有一个隐藏目录 .git，这个不算工作区，而是 Git 的版本库。

下面这个图展示了工作区、版本库中的暂存区和版本库之间的关系：