版本控制
1：版本控制概念
版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地了记录下来。每一次文件的改变，文件的版本号都将增加。除了记录版本变更外，版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作业，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题，提高协同开发的效率。并行开发中最常见的不同版本软件的错误(Bug)修正问题也可以通过版本控制中分支与合并的方法有效地解决。
具体来说，在每一项开发任务中，都需要首先设定开发基线，确定各个配置项的开发初始版本，在开发过程中，开发人员基于开发基线的版本，开发出所需的目标版本。当发生需求变更时，通过对变更的评估，确定变更的影响范围，对被影响的配置项的版本进行修改，根据变更的性质使配置项的版本树继续延伸或产生新的分支，形成新的目标版本，而对于不受变更影响的配置项则不应发产生变动。同时，应能够将变更所产生的对版本的影响进行记录和跟踪。必要时还可以回退到以前的版本。例如当开发需求或需求变更被取消时，就需要有能力将版本回退到开发基线版本。在曾经出现过的季度升级包拆包和重新组包的过程中，其实就是将部分配置项的版本回退到开发基线，将对应不同需求的不同分支重新组合归并，形成新的升级包版本。
版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段。还需要定义、收集一些元数据来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。当然如果选用的工具支持，这些辅助数据将能直接统计出过程数据，从而方便软件过程改进活动的进行。对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被锁定的状态,如需要对它们进行变更，则应按照变更控制的流程来进行操作。
版本控制(Revision contro1)是一种在开发的过程中用于管理我们对文件、目录或工程等内容的修改历史，方便查看更改历史记录，备份以便恢复以前的版本的软件工程技术。简单来说就是用于管理多人协同开发项目的技术。
没有进行版本控制或者版本控制本身就缺乏正确的流程管理，在软件开发过程中将会引入很多问题,如软件代码的一致性、软件内容的冗余、软件过程的事物性、软件开发过程中的并发性、软件源代码的安全性，以及软件的整合等问题。无论是工作还是学习，或者是自己做笔记，都经历过这样一个阶段!我们就迫切需要一个版本控制工具。(多人开发就必须要使用版本控制)
2：版本控制的功能
（1）检入检出控制
软件开发人员对源文件的修改不能在软件配置管理库中进行，对源文件的修改依赖于基本的文件系统并在各自的工作空间下进行。为了方便软件开发，需要不同的软件开发人员组织各自的工作空间。一般说来，不同的工作空间由不同的目录表示，而对工作空间的访问，由文件系统提供的文件访问权限加以控制。访问控制需要管理各个人员存取或修改一个特定软件配置对象的权限。开发人员能够从库中取出对应项目的配置项进行修改，并检入到软件配置库中，对版本进行“升级”;配置管理人员可以确定多余配置项并删除。
同步控制的实质是版本的检入检出控制。检入就是把软件配置项从用户的工作环境存入到软件配置库的过程，检出就是把软件配置项从软件配置库中取出的过程。检人是检出的逆过程。同步控制可用来确保由不同的人并发执行的修改不会产生混乱。
（2）分支和合井
版本分支(以一个已有分支的特定版本为起点,但是独立发展的版本序列)的人工方法就是从主版本一称为主干上拷贝一份，并做上标记。在实行了版本控制后，版本的分支也是一份拷贝，这时的拷贝过程和标记动作由版本控制系统完成。版本合并(来自不同分支的两个版本合并为其中一个分支的新版本)有两种途径，一是将版本A的内容附加到版本B中;另一种是合并版本A和版本B的内容，形成新的版本C。
（3）历史记录
版本的历史记录有助于对软件配置项进行审核，有助于追踪问题的来源。历史记录包括版本号、版本修改时间、版本修改者、版本修改描述等最基本的内容，还可以有其他一些辅助性内容，比如版本的文件大小和读写属性。
3：版本控制的流程
（1）创建配置项。
项目成员依据《配置管理计划》，在配置库中创建属于其任务范围内的配置项。此时配置项的状态为“草稿”其版本号格式为 8.YZ。
（2）修改状态为“草稿”的配置项目。
项目成员使用配置管理软件的 Check in/check out 功能，可以自由修改处于“草稿”状态的配置项,版本号格式为0.YZ。
（3）技术评审或领导审批。
如果配置项是技术文档，则需要接受技术评审。如果配置项是“计划”这类文件，则需要项目经理(或上级领导)的审批。若配置项通过了技术评审或领导审批，则转向下一步·否则转回上一步。
（4）正式发布。
配置项通过技术评审或领导审批之后。则配置项的状态从“草稿”变为“正式发布”，版本号格式为
X.Y。
（5）变更。
修改处于“正式发布”状态的配置项，必须按照“变更控制流程”执行。
4：版本控制的优势
实现跨区域多人协同开发
追踪和记载一个或者多个文件的历史记录
组织和保护你的源代码和文档
统计工作量
并行开发、提高开发效率
跟踪记录整个软件的开发过程
减轻开发人员的负担，节省时间，同时降低人为错误
版本控制的分类
1：本地版本控制
许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单，但是特别容易犯错。 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。
为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。但是，它的最大的弊端就是无法让位于不同系统上的开发者协同工作。
2：集中化的版本控制
为了解决不同开发者之间的协同工作，集中化的版本控制系统(centralized version contro]Systems，简称 CVCS)应运而生。这类系统，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。
这种做法带来了许多好处，特别是相较于老式的本地 S 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限,并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
事分两面，有好有坏。 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据–包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。 本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
3：分布式版本控制
为了避免中央服务器的单点故障,于是分布式版本控制系统(Distributed Version Control system,
简称 DVCS)面世了。
在这类系统中,像 Git、Mercurial、Bazaar 以及 Darcs 等,客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来，包括完整的历史记录。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。
更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。这就是git 分布式版本系统的优势。
常见的版本控制系统介绍
1：Git
Git(读音为/git/)是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的
项目版本管理。也是Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
Git 的优势就是:每个人都拥有全部的代码，可以避免一些安全隐患。不会因为服务器损坏或者网络问题，造成不能工作的情况。
所有版本信息仓库全部同步到本地的每个用户，这样就可以在本地查看所有版本历史，可以离线在本地提交，只需在连网时 push 到相应的服务器或其他用户那里。由于每个用户那里保存的都是所有的版本数据，只要有一个用户的设备没有问题就可以恢复所有的数据，但这增加了本地存储空间的占用。
Git 是分布式版本控制系统，没有中央服务器，每个人的电脑就是一个完整的版本库，工作的时候不需要联网了，因为版本都在自己电脑上。协同的方法是这样的:比如说自己在电脑上改了文件 A，其他人也在电脑上改了文件 A，这时，你们两之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。Git 可以直接看到更新了哪些代码和文件!
2：GitHub
GitHub 是一个面向开源及私有软件项目的托管平台，因为只支持 Git 作为唯一的版本库格式进行托管，故名 GitHub。GitHub 可以提供给用户空间创建 Git 仓储,保存用户的一些数据文档或者代码等GitHub 作为开源代码库以及版本控制系统，目前拥有 140 多万开发者用户。随着越来越多的应用程序转移到了云上，GitHub 已经成为了管理软件开发以及发现已有代码的首选方法。GitHub 可以托管各种Git 库，并提供一个 Web 界面，但与其它像 SourceForge 或 Google code 这样的服务不同，GitHub的独特卖点在于从另外一个项目进行分支的简易性。
GitLab 是一个基于 Git 的项目管理软件,用于仓库管理系统的开源项目。使用 Git 作为代码管理工具，并在此基础上搭建起来 web 服务。Git、Gitlab、Github 都是基于 Git 的，可以说是 Git 的衍生品。
3：GitLab
Gitlab 是一款自由和免费的开源软件，因此不需要编写许可证或购买许可证。它允许开发者将源代码托管到自有服务器或者像 Gitlab.com 这样的云端服务器上。这个免费的模式非常适合中小型企业开发者，可以获得许多强大的功能，如代码分枝、分支合并、查看历史变更等
Gitlab 非常易于使用和管理。它提供了一个友好的 web 界面，可以让开发者在浏览器中完成 Git 的核心操作。它为用户提供了许多简单易用的功能，如 API、集成、安全，以及其他一些其他的托管服务功能。除此之外，Gitlab 管理界面也很直观，可以方便的管理用户权限和代码基础设施的其他方面。
4：其他版本控制系统
其他开放源码的版本控制工具还有有很多，如 Concurrent Versions system(csv)、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的工作原理
1：Git的核心概念
Git 是一个分布式版本控制系统，它的核心是 Git 对象、Git 树和提交(快照)历史链这三个概念。Git 原理的核心可以概括为以下几点:
（1）Git 对象
Git 中的所有数据都存储在 Git 对象中。每个 Git 对象都由一个 SHA-1 校验和作为唯一的标识符,可以是文件内容、目录结构或者版本历史等。
（2）Git 树
Git 树是由 Git 对象组成的一个目录结构，保存了文件夹、文件和子树的信息，每个树对象都包含一个或多个子对象的引用。
（3）提交历史链
每个提交对象都可以有一个或多个父对象，形成一个提交历史链。通过这个提交历史链，Git 可以跟踪每个文件的修改历史，也可以方便地进行版本回滚、分支合并等操作。
（4）Git 分支
分支是指向 Git 仓库中某一次提交的一个指针，也就是一个指向 Git 提交历史的引用。每个分支都包含了 Git 仓库中的一个提交对象，这个提交对象指向了你项目的一个特定状态。
（5）Git 工作区
工作区是文件的实际工作目录，是你在电脑上看到的目录。在执行“git add” 命令前，工作区的文件修改和添加不会被 Git 跟踪。
（6）Git 暂存区
暂存区是一个临时的存储区域，用于存储将要提交的文件和修改。在执行“git add”命令时，修改的文件会被保存到暂存区中。
（7）Git 远程仓库
远程仓库是指存储在远程服务器上的 Git 仓库，用于多人协作开发、备份和共享代码。Git 支持多种协议，如 HTTPS、SSH 等，可以通过、gitremote、命令管理远程仓库。
Git的强大之处在于它的分布式特性和提交历史链的设计,使得团队协作和代码管理更加方便和高效。
2：git的存储
Git 的工作流程可以简单概括为将工作目录(working directory)的修改提交到暂存区(stagingarea)，再将暂存区的修改提交到本地仓库(1ocal repository)，最后将本地仓库的修改推送到远程仓库(remote repository)。
在 Git 中，对象分为三种类型:blob、tree 和 commit。blob 对象表示文件内容;tree 对象表示文件夹或目录结构;commit 对象表示一个提交或快照，commit 对象包含作者、时间戳、提交信息等版本信息。每一次我们修改文件，Git 都会完整的保存一份这个文件的快照而非记录差异。每次提交到暂存区的时候,都会把需要暂存文件的副本放到仓库里面(为blob对象)并为每个blob对象生成一个sha-1,这一堆 blob 对象包括当前暂存的所有修改。
提交的时候，生成一个快照(一堆暂存的 blob 对象和没有变化的对象就形成了当前修改的一个快照,是一个 tree 对象)，并生成一个提交对象包含这个快照的指针，并包含一些提交信息。同时还有一个或者多个指针指向当前提交的前一次提交。
每次提交会生成一个校验和，这个校验和就唯一指定一个提交。所以一次提交就相当于给整个库打了一个不可变的快照。
git add 添加文件到暂存区，并且创建数据对象添加到 tree 对象中且记录到 git 数据库git commit 然后把以上的 tree 对象添加到 commit 对象中记录到 git 数据库中。
3：相关概念
(1)Git 的标签(Tag)管理
Git 支持标签管理，可以给代码库中的某个版本打上标签，方便以后查找和回滚到指定版本。
(2)Git 的远程仓库管理
Git 可以将本地仓库推送到远程仓库进行备份或共享。常用的远程仓库有 GitHub、GitLab、Bitbucket 等，Git 支持多种协议进行远程仓库之间的数据传输，如 HTTPS、SSH 等。
(3)Git的钩子(Hook)
Git 的钩子是一种脚本,可以在 Git 命令执行前或执行后自动触发,用于实现自定义的功能。Git 支持多种钩子，如提交钩子、合并钩子等。
(4)Git的子模块(Submodule)
Git的子模块是一种管理外部代码库的方式,可以将外部代码库嵌入到主代码库中,方便管理和维护。
(5)Git的工作流(Workflow)
Git 支持多种工作流，如集中式工作流、功能分支工作流、Gitflow 工作流等，可以根据项目需求选择不同的工作流进行代码管理和版本控制。
部署Git服务器
1：基础环境
一台git一台client，需要时间同步
两台都安装git
2：服务器端基本设置
初始化git仓库
在本案例中，我们要将该服务器初始化为远程仓库，提供给其他开发人员用来提交项目，在初始化的时候，需要加上–bare 的选项。
备注:
git init:建立一个标准的 git 仓库，它将我们所在的目录转换为一个 Git 本地仓库。
建立一个标准的 Git 仓库，这样的仓库初始化后，其项目目录为工作空间，其下的.git 目录是版本控制器。git init 命令执行后会在本地生成一个.git 的文件夹，用来追踪仓库的所有变更。
git init–bare:它将我们所在的目录指定为远程服务器仓库。这样的仓库初始化后，其项目目录下就是标准仓库.git 日录里的内容，没有工作空间。这个仓库只保存git 历史提交的版本信息，而不允许用户在上面进行各种 git 操作(如:push、commit 操作)。但是,你依旧可以使用 git show 命令查看提交内容。
3：客户端基本信息设置
设置密钥对，免输入密码
从git服务器中克隆版本仓库到本地
此时会在当前目录下生成一个空目录，这个步骤的目的是将服务器端的项目(空项目)克隆到本地，这样就在本地建立了一个代码库，开发者就可以基于此代码库进行程序开发。之后就可以将代码从本地提交到远程的代码库了。
配置用户信息
4：代码提交操作
编写代码
添加到暂存区
备注:
“git add.”命令可以将当前目录中的所有文件添加到暂存区。
添加到本地仓库
备注:
-m:m指的是 message，可以是一些备注信息
-a:用于先将所有工作区的变动文件，提交到暂存区，再运行git commit。用了-a参数,就不用执行“git add .”
注意:
git commit -m 只是 git add 之后文件放在在暂存区之后的提交，如果暂存区没有 add，是没有效果的。
git commit -am 是之前提交过到工作区的日志信息已经存在(git commit -m “日志信息”文件名)已经执行过，再执行同样的日志信息可以不用 add，一步到位
为当前版本库设置标签
master 分支是当前主分支的最新版本，上一步中为代码版本打过标签后没有再提交过新的代码，所以查看到的是相同的内容。
修改文件内容
查看工作状态
添加远程版本库
注意:
在克隆了一个远程仓库到本地的时候，已经在本地自动添加了名称为origin 的远程仓库，如果想设置其他的仓库名称，可以使用 git remote add 的命令进行添加。
备注:
如果要删除一个远程仓库，可以使用命令:
git remote remove gitserver
上传代码
为了验证文件是否推送到远程的 Git服务，可以换个目录(或主机)再次克隆一份版本仓库
备注:
指定标签下载对应的版本
不指定版本默认下载的最新的版本
git clone -b v1.1 root@192.168.207.137:/opt/mypro.git
git clone -b v1.2 root@192.168.207.137:/opt/mmypro.git
git clone -b master root@192.168.207.137:/opt/mypro.git
-b master 的参数可以省去，默认就是克隆master 分支的当前版本
部署GitLab服务器
1：基础环境
需要时间同步，另一台client可以继续使用
2：安装GitLab
3：修改配置文件
4：加载配置文件并启动
注意80端口不能被占用
备注:
重启:gitlab-ctl restart
关闭:gitlab-ctl stop
启动:gitlab-ctl start
状态:gitlab-ctl status
帮助:gitlab-ctl–help
5：访问
查看密码
6：修改密码
7：设置可以导入的类型
8：创建项目
客户机克隆空项目
创建本地代码
提交暂存区
从暂存区提交到本地仓库
分支命名
为客户端设置 GitLab 为远程仓库
将分支版本提交到远程仓库
-u:相当于记录了 push 到远端分支的默认值，这样当下次我们还想要继续 push 的这个远端分支的时候推送命令就可以简写成 git push 即可
-f:强制更新，需要 gitlab 权限允许。
设置权限允许强制更新
9：创建新用户
添加组
添加用户
备注:
access level:用户地访问级别。
Regular:普通用户，只能访问属于他自己的组和项目Admin:管理员，可以访问所有的组合项目
设置密码
将用户加入组
Gitlab 用户在组里面有5种不同权限:
Guest:可以创建 issue、发表评论，不能读写版本库。
Reporter:可以克隆代码，不能提交，QA、PM可以赋予这个权限
Developer:可以克隆代码、开发、提交、push，普通开发可以赋予这个权限。
Maintainer:可以创建项目、添加 tag、保护分支、添加项目成员、编辑项目，核心开发可以赋予这个权限。
0wner:可以设置项目访问权限:-Visibility Level、删除项目、迁移项目、管理组成员，开发组组长可以赋予这个权限。
10：在用户组中创建项目
以zhangsan身份登录
重新设置密码后添加项目
选择导入项目
添加仓库的url
此处，我们选择一个 gitee 上的开源项目 mall，其连接如下:
https://gitee.com/kgc-wjq/league.git
注意:
此处设置的访问级别为Private，在客户端进行克隆的时候，就需要输入 zhangsan 的账号密码进行身份认证后才能克隆下来。如果选择Public，在克隆的时候就不需要身份验证了。
验证结果
在客户机克隆