第07章 Gitlab+Jenkins+Maven 持续集成（CI）和持续交付（CD ）实践

第07章 Gitlab+Jenkins+Maven 持续集成（CI）和持续交付（CD ）实践

https://blog.csdn.net/qq_32261399/article/list/3?t=1

出现这个提示：there are no staged files

pre-receive hook declined
GitLab: You are not allowed to force push code to a protected branch on this project.

https://www.cnblogs.com/xxcanghai/p/5009926.html

通过上面我们看见，有挺多的文件不是我们写的，这些文件不需要进行版本控制。

如何进行排除掉这些文件呢？

https://blog.csdn.net/ruangong1203/article/details/73065410

7.1 实战相关基础知识

7.1.1 DevOps 相关知识

DevOps是“开发”和“运维”的缩写。DevOps是一组最佳实践强调(IT研发、运维、测试)在应用和服务生命周期中的协作和沟通，强调整个组织的合作以及交付和基础设施变更的自动化，从而实现持续集成、持续部署和持续交付。

DevOps平台四大模块

1.项目管理          (创建项目--->>项目需求)
2.运维平台          (监控--日志收集---等)
3.持续交付          (提交完代码--->自动打包--->构建)
4.代码托管          (gitlab---->代码提交)
————————————————————>>DevOps平台

针对DevOps开源项目

1.项目管理---(JIRA非开源但是用的人比较多)、(Redmine使用ruby写的)
2.代码托管---(SVN--usvn有web管理界面)、(GitLab)
3.持续交付---(主流Jenkins)、(GitLab gitlab-ci也可以做交付)
4.运维平台---(国内的开源运维平台可能就是腾讯蓝鲸)

7.1.1.1 CI/CD持续集成/持续部署

持续集成(Continuous integration)是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

持续部署（continuous deployment）是通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，毕竟快速运转的互联网公司人力成本会高于机器，投资机器优化开发流程化相对也提高了人的效率，让 engineering productivity 最大化。

持续交付（英语：Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

与DevOps的关系

持续交付与DevOps的含义很相似，所以经常被混淆。但是它们是不同的两个概念。DevOps的范围更广，它以文化变迁为中心，特别是软件交付过程所涉及的多个团队之间的合作（开发、运维、QA、管理部门等），并且将软件交付的过程自动化。另壹方面，持续交付是壹种自动化交付的手段，关注点在于将不同的过程集中起来，并且更快、更频繁地执行这些过程。因此，DevOps可以是持续交付的壹个产物，持续交付直接汇入DevOps；

与持续部署的关系

有时候，持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。

7.1.1.2 CI/CD 持续集成和持续交付

在互联网时代，对于每一个企业，公司，产品快速迭代的重要性不言而喻，针对敏捷开发以使用CICD来完成。但是持续集成和持续交付（CI/CD）其实并没有那么容易实现，开发和运维总是忙里忙外，最后还吃力不讨好，更不要说持续交付过程中保证应用平滑升级，避免服务宕机。 需求业务及BUG:可以通过测试提出的bug新需求业务来快速提交给开发来完成需求和bug修改。如 禅道，redmine等… 项目版本迭代控制:可以继承企业现有的版本控制工具，如 Github、GitLab、SVN、CVS 等主流工具…构建及测试:通过 Jenkins 实现自动构建和测试,还有商业软件BAMBOO来持续集成。这个收费的。免费就用Jenkins…
交付:以docker镜像形式进行交付，提交至镜像仓库；

7.1.1.3 CI/CD 持续集成和持续交付方案

制定了一套解决方案，此套方案 作为 PaaS 或者SaaS 都是棒棒的，结合着openstack 作为IaaS层 更适合，

整体的思路大概是这样的，后续会详细介绍。

客户或产品有新的需求变更，或者测试人员提出bug时，会在redmine服务上创建提交事件，开发人员得到通知，会对开发分支做修改，每个项目会有不同的分支。

分支中会包含一个名叫docker的目录，里面包含了将整个项目的build输出（对于java的web应用来说就是war文件），打包成docker image所需要的文件。

项目使用git来做源代码管理，Git服务器为私有的Gitlab。

开发人员提交代码并push到Gitlab，Gitlab触发Web Hook，通知Jenkins项目有新的变更。Jenkins收到通知，从Gitlab pull代码并自动启动编译构建。

如果构建成功调用docker的目录下脚本来生成docker image并push到私有docker仓库上。

通过chef，通知最终的部署节点，下载最新版image，删除正在运行的容器，以新image来启动容器，完成项目的更新。整个过程会在短短几分钟就能看到结果。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gslVUC2P-1599485668375)(…/%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5%E6%96%87%E7%AB%A0/assets/1531214210457.png)]

7.1.1.4 Jenkins 基础知识

Jenkins是一个可扩展的持续集成引擎。

主要用用途：

持续、自动的构建/测试软件项目。

监控一些定时执行的任务。、

特点：

易于安装，只要把jenkins.war部署到servlet容器

易于配置-所有配置都通过其提供的web界面实现。

集成RSS/E-mail通过RSS发布构建结果或当构件完成是通过e-mail通知。

生成JUnit/TestNG测试报告。

分布式构建支持Jenkins能够让多台计算机一起构建/测试。

文件识别：Jenkins能够跟踪那次构建生成哪些jar，那次构建使用哪个版本的jar

插入支持：支持扩展插件，可以开发适合自己团队的使用的工具。

Jenkins的目标是监控软件的开发流程，快速显示问题。所以能保证开发人员省事又省力提高开发效率。

7.1.1.5 版本控制器基础知识

现有的版本控制工具，如 Github、GitLab、SVN、CVS 等主流工具…

构建及测试:通过 Jenkins 实现自动构建和测试,还有商业软件BAMBOO来持续集成。这个收费的。免费就用Jenkins…

交付:以Docker镜像形式进行交付，提交至镜像仓库；

7.1.1.5.1 SVN服务器

Subversion是一个版本控制系统，相对于的RCS、CVS，采用了分支管理系统，它的设计目标就是取代CVS。互联网上免费的版本控制服务多基于Subversion。

Subversion的版本库可以通过网络访问，从而使用户可以在不同的电脑上进行操作。从某种程度上来说，允许用户在各自的空间里修改和管理同一组数据可以促进团队协作。因为修改不再是单线进行（单线进行也就是必须一个一个进行），开发进度会进展迅速。此外，由于所有的工作都已版本化，也就不必担心由于错误的更改而影响软件质量—如果出现不正确的更改，只要撤销那一次更改操作即可。某些版本控制系统本身也是软件配置管理系统（SCM），这种系统经过精巧的设计，专门用来管理源代码树，并且具备许多与软件开发有关的特性——比如对编程语言的支持或者提供程序构建工具。不过Subversion并不是这样的系统，它是一个通用系统，可以管理任何类型的文件集。

7.1.1.5.2 CVS服务器

CVS（Concurrent Versions System）版本控制系统是一种GNU软件包，主要用于在多人开发环境下源码的维护。Concurrent有并发的、协作的、一致的等含义。实际上CVS可以维护任意文档的开发和使用，例如共享文件的编辑修改，而不仅仅局限于程序设计。CVS维护的文件类型可以是文本类型也可以是二进制类型。CVS用Copy-Modify-Merge（拷贝、修改、合并）变化表支持对文件的同时访问和修改。它明确地将源文件的存储和用户的工作空间独立开来，并使其并行操作。CVS基于客户端/服务器的行为使其可容纳多个用户。这一特性使得CVS成为位于不同地点的人同时处理数据文件（特别是程序的源代码）时的首选。

所有重要的免费软件项目都使用CVS作为其程序员之间的中心点，以便能够综合各程序员的改进和更改。这些项目包括GNOME、KDE、THE GIMP和Wine等。

7.1.1.5.3 GIt/github

​ GIT （分布式版本控制系统）

Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。Git的读音为/gɪt/。

Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得BitKeeper 的许可证并不适合开放源码社区的工作，因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如 很多 Freedesktop 的项目迁移到了 Git 上。

gitHub是一个面向开源及私有软件项目的托管平台，因为只支持git 作为唯一的版本库格式进行托管，故名gitHub。

gitHub于2008年4月10日正式上线，除了git代码仓库托管及基本的 Web管理界面以外，还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱（报表）、代码片段分享（Gist）等功能。目前，其注册用户已经超过350万，托管版本数量也是非常之多，其中不乏知名开源项目 Ruby on Rails、jQuery、python 等。

7.1.2 敏捷开发概念

敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

7.1.3 git 基础知识

7.1.3.1 基本介绍

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

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

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

7.1.3.2 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哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。

7.1.3.3 Git 工作流程

一般工作流程如下：

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

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JyXeGiii-1599485668377)(assets/1532762457909.png)]

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

基本概念

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

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

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

图中左侧为工作区，右侧为版本库。在版本库中标记为 “index” 的区域是暂存区（stage, index），标记为 “master” 的是 master 分支所代表的目录树。

图中我们可以看出此时 “HEAD” 实际是指向 master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。

图中的 objects 标识的区域为 Git 的对象库，实际位于 “.git/objects” 目录下，里面包含了创建的各种对象及内容。

当对工作区修改（或新增）的文件执行 “git add” 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。

当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。

当执行 “git reset HEAD” 命令时，暂存区的目录树会被重写，被 master 分支指向的目录树所替换，但是工作区不受影响。

当执行 "git rm --cached " 命令时，会直接从暂存区删除文件，工作区则不做出改变。

当执行 “git checkout .” 或者 "git checkout – " 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区的改动。

当执行 “git checkout HEAD .” 或者 "git checkout HEAD " 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。

7.1.3.5 Git 创建仓库

介绍如何创建一个 Git 仓库。也可以使用一个已经存在的目录作为Git仓库。

1、git init

Git 使用 git init 命令来初始化一个 Git 仓库，Git 的很多命令都需要在 Git 的仓库中运行，所以 git init 是使用 Git 的第一个命令。

在执行完成 git init 命令后，Git 仓库会生成一个 .git 目录，该目录包含了资源的所有元数据，其他的项目目录保持不变（不像 SVN 会在每个子目录生成 .svn 目录，Git 只在仓库的根目录生成 .git 目录）。

2、使用方法

使用当前目录作为Git仓库，我们只需使它初始化。

git init

该命令执行完后会在当前目录生成一个 .git 目录。

使用我们指定目录作为Git仓库。

git init newrepo

初始化后，会在 newrepo 目录下会出现一个名为 .git 的目录，所有 Git 需要的数据和资源都存放在这个目录中。

如果当前目录下有几个文件想要纳入版本控制，需要先用 git add 命令告诉 Git 开始对这些文件进行跟踪，然后提交：

$ git add *.c
$ git add README
$ git commit -m '初始化项目版本'

以上命令将目录下以 .c 结尾及 README 文件提交到仓库中。

---

7.1.3.6 git clone

我们使用 git clone 从现有 Git 仓库中拷贝项目（类似 svn checkout）。

克隆仓库的命令格式为：

git clone 

如果我们需要克隆到指定的目录，可以使用以下命令格式：

git clone  

参数说明：

• **repo:**Git 仓库。
• **directory:**本地目录。

比如，要克隆 Ruby 语言的 Git 代码仓库 Grit，可以用下面的命令：

$ git clone git://github.com/schacon/grit.git

执行该命令后，会在当前目录下创建一个名为grit的目录，其中包含一个 .git 的目录，用于保存下载下来的所有版本记录。

$ git clone git://github.com/schacon/grit.git mygrit 

7.1.3.7 Git 基本操作

Git 的工作就是创建和保存你项目的快照及与之后的快照进行对比。本节将对有关创建与提交你的项目快照的命令作介绍。

1、获取与创建项目命令

1.1 git init

用 git init 在目录中创建新的 Git 仓库。 你可以在任何时候、任何目录中这么做，完全是本地化的。

在目录中执行 git init，就可以创建一个 Git 仓库了。比如我们创建 runoob 项目：

$ mkdir runoob
$ cd runoob/
$ git init
Initialized empty Git repository in /Users/tianqixin/www/runoob/.git/
# 在 /www/runoob/.git/ 目录初始化空 Git 仓库完毕。

现在你可以看到在你的项目中生成了 .git 这个子目录。 这就是你的 Git 仓库了，所有有关你的此项目的快照数据都存放在这里。

ls -a
.    ..    .git

1.2 git clone

使用 git clone 拷贝一个 Git 仓库到本地，让自己能够查看该项目，或者进行修改。

如果你需要与他人合作一个项目，或者想要复制一个项目，看看代码，你就可以克隆那个项目。 执行命令：

 git clone [url]

[url] 为你想要复制的项目，就可以了。

例如我们克隆 Github 上的项目：

$ git clone [email protected]:schacon/simplegit.git
Cloning into 'simplegit'...
remote: Counting objects: 13, done.
remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13
Receiving objects: 100% (13/13), done.
Resolving deltas: 100% (2/2), done.
Checking connectivity... done.

克隆完成后，在当前目录下会生成一个 simplegit 目录：

$ cd simplegit/
$ ls
README   Rakefile lib

上述操作将复制该项目的全部记录。

$ ls -a
.        ..       .git     README   Rakefile lib
$ cd .git
$ ls
HEAD        description info        packed-refs
branches    hooks       logs        refs
config      index       objects

默认情况下，Git 会按照你提供的 URL 所指示的项目的名称创建你的本地项目目录。 通常就是该 URL 最后一个 / 之后的项目名称。如果你想要一个不一样的名字， 你可以在该命令后加上你想要的名称。

---

2、基本快照

Git 的工作就是创建和保存你的项目的快照及与之后的快照进行对比。本章将对有关创建与提交你的项目的快照的命令作介绍。

2.1 git add

git add 命令可将该文件添加到缓存，如我们添加以下两个文件：

$ touch README
$ touch hello.php
$ ls
README        hello.php
$ git status -s
?? README
?? hello.php
$ 

git status 命令用于查看项目的当前状态。

接下来我们执行 git add 命令来添加文件：

$ git add README hello.php 

现在我们再执行 git status，就可以看到这两个文件已经加上去了。

$ git status -s
A  README
A  hello.php
$ 

新项目中，添加所有文件很普遍，我们可以使用 git add . 命令来添加当前项目的所有文件。

现在我们修改 README 文件：

$ vim README

在 README 添加以下内容：# Runoob Git 测试，然后保存退出。

再执行一下 git status：

$ git status -s
AM README
A  hello.php

“AM” 状态的意思是，这个文件在我们将它添加到缓存之后又有改动。改动后我们再执行 git add 命令将其添加到缓存中：

$ git add .
$ git status -s
A  README
A  hello.php

当你要将你的修改包含在即将提交的快照里的时候，需要执行 git add。

2.2 git status

git status 以查看在你上次提交之后是否有修改。

我演示该命令的时候加了 -s 参数，以获得简短的结果输出。如果没加该参数会详细输出内容：

$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached ..." to unstage)

    new file:   README
    new file:   hello.php

2.3 git diff

执行 git diff 来查看执行 git status 的结果的详细信息。

git diff 命令显示已写入缓存与已修改但尚未写入缓存的改动的区别。git diff 有两个主要的应用场景。

• 尚未缓存的改动：git diff
• 查看已缓存的改动： git diff --cached
• 查看已缓存的与未缓存的所有改动：git diff HEAD
• 显示摘要而非整个 diff：git diff --stat

在 hello.php 文件中输入以下内容：

$ git status -s
A  README
AM hello.php
$ git diff
diff --git a/hello.php b/hello.php
index e69de29..69b5711 100644
--- a/hello.php
+++ b/hello.php
@@ -0,0 +1,3 @@
+

git status 显示你上次提交更新后的更改或者写入缓存的改动， 而 git diff 一行一行地显示这些改动具体是啥。

接下来我们来查看下 git diff --cached 的执行效果：

$ git add hello.php 
$ git status -s
A  README
A  hello.php
$ git diff --cached
diff --git a/README b/README
new file mode 100644
index 0000000..8f87495
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+# Runoob Git 测试
diff --git a/hello.php b/hello.php
new file mode 100644
index 0000000..69b5711
--- /dev/null
+++ b/hello.php
@@ -0,0 +1,3 @@
+

2.4 git commit

使用 git add 命令将想要快照的内容写入缓存区， 而执行 git commit 将缓存区内容添加到仓库中。

Git 为你的每一个提交都记录你的名字与电子邮箱地址，所以第一步需要配置用户名和邮箱地址。

$ git config --global user.name 'runoob'
$ git config --global user.email [email protected]

接下来我们写入缓存，并提交对 hello.php 的所有改动。在首个例子中，我们使用 -m 选项以在命令行中提供提交注释。

$ git add hello.php
$ git status -s
A  README
A  hello.php
$ $ git commit -m '第一次版本提交'
[master (root-commit) d32cf1f] 第一次版本提交
 2 files changed, 4 insertions(+)
 create mode 100644 README
 create mode 100644 hello.php
 

现在我们已经记录了快照。如果我们再执行 git status:

$ git status
# On branch master
nothing to commit (working directory clean)

以上输出说明我们在最近一次提交之后，没有做任何改动，是一个"working directory clean：干净的工作目录"。

如果你没有设置 -m 选项，Git 会尝试为你打开一个编辑器以填写提交信息。 如果 Git 在你对它的配置中找不到相关信息，默认会打开 vim。屏幕会像这样：

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
# modified:   hello.php
#
~
~
".git/COMMIT_EDITMSG" 9L, 257C

如果你觉得 git add 提交缓存的流程太过繁琐，Git 也允许你用 -a 选项跳过这一步。命令格式如下：

git commit -a

我们先修改 hello.php 文件为以下内容：

再执行以下命令：

git commit -am '修改 hello.php 文件'
[master 71ee2cb] 修改 hello.php 文件
 1 file changed, 1 insertion(+)

2.5 git reset HEAD

git reset HEAD 命令用于取消已缓存的内容。

我们先改动文件 README 文件，内容如下：

# Runoob Git 测试
# 菜鸟教程 

hello.php 文件修改为：

现在两个文件修改后，都提交到了缓存区，我们现在要取消其中一个的缓存，操作如下：

$ git status -s
 M README
 M hello.php
$ git add .
$ git status -s
M  README
M  hello.pp
$ git reset HEAD hello.php 
Unstaged changes after reset:
M    hello.php
$ git status -s
M  README
 M hello.php

现在你执行 git commit，只会将 README 文件的改动提交，而 hello.php 是没有的。

$ git commit -m '修改'
[master f50cfda] 修改
 1 file changed, 1 insertion(+)
$ git status -s
 M hello.php

可以看到 hello.php 文件的修改并未提交。

这时我们可以使用以下命令将 hello.php 的修改提交：

$ git commit -am '修改 hello.php 文件'
[master 760f74d] 修改 hello.php 文件
 1 file changed, 1 insertion(+)
$ git status
On branch master
nothing to commit, working directory clean

简而言之，执行 git reset HEAD 以取消之前 git add 添加，但不希望包含在下一提交快照中的缓存。

2.6 git rm

如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 Changes not staged for commit 的提示。

要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除，然后提交。可以用以下命令完成此项工作

git rm 

如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f

git rm -f 

如果把文件从暂存区域移除，但仍然希望保留在当前工作目录中，换句话说，仅是从跟踪清单中删除，使用 --cached 选项即可

git rm --cached 

如我们删除 hello.php文件：

$ git rm hello.php 
rm 'hello.php'
$ ls
README

不从工作区中删除文件：

$ git rm --cached README 
rm 'README'
$ ls
README

可以递归删除，即如果后面跟的是一个目录做为参数，则会递归删除整个目录中的所有子目录和文件：

git rm –r * 

进入某个目录中，执行此语句，会删除该目录下的所有文件和子目录。

2.7 git mv

git mv 命令用于移动或重命名一个文件、目录、软连接。

我们先把刚移除的 README 添加回来：

$ git add README 

然后对其重名:

$ git mv README  README.md
$ ls
README.md

7.1.3.8 Git 快速入门

本站也提供来Git快速入门版本，你可以点击 Git简明指南 查看。

入门后建议通过本站详细学习 Git 教程。

Git 完整命令手册地址：http://git-scm.com/docs

PDF 版命令手册：github-git-cheat-sheet.pdf

参考资料：http://www.runoob.com/git/git-basic-operations.html

7.1.3.9 进阶操作

1、git 回滚提交

//reset将一个分支的末端指向另一个提交。这可以用来移除当前分支的一些提交, 让master分支向后回退了两个提交
git checkout master
git reset HEAD~2

//Revert撤销一个提交的同时会创建一个新的提交, 找出倒数第二个提交，然后创建一个新的提交来撤销这些更改，然后把这个提交加入项目中。
git revert HEAD~2 

2、恢复不小心删除的 git stash 文件

git fsck  //找到dangling的对象
git show id  //上面列出的每一条记录的最后一个字符串，按 enter 查看具体信息
git stash apply id

3、rebase 和 merge 区别

git pull --rebase origin master1

rebase 选项告诉 Git 把你的提交移到同步了中央仓库修改后的 master 分支的顶部。rebase 操作过程是把本地提交一次一个地迁移到更新了的中央仓库master分支之上。这意味着可能要解决在迁移某个提交时出现的合并冲突，而不是解决包含了所有提交的大型合并时所出现的冲突。这样的方式让你尽可能保持每个提交的聚焦和项目历史的整洁。反过来，简化了哪里引入Bug的分析，如果有必要，回滚修改也可以做到对项目影响最小。

git pull origin master1

如果没有 rebase， pull 操作仍然可以完成，但每次 pull 操作要同步中央仓库中别人修改时，提交历史会以一个多余的『合并提交』结尾。
合并玩冲突之后，git rebase --continue，Git 会继续一个一个地合并后面的提交，如其它的提交有冲突就重复这个过程。
如果你碰到了冲突，但发现搞不定，不要惊慌。只要执行下面这条命令，就可以回到你执行git pull –rebase命令前的样子：git rebase --abort

4、 初次运行 Git 前的配置

一般在新的系统上，我们都需要先配置下自己的 Git 工作环境。配置工作只需一次，以后升级时还会沿用现在的配置。当然，如果需要，你随时可以用相同的命令修改已有的配置。

Git 提供了一个叫做 git config 的工具（译注：实际是 git-config 命令，只不过可以通过 git 加一个名字来呼叫此命令。），专门用来配置或读取相应的工作环境变量。而正是由这些环境变量，决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方：

• /etc/gitconfig 文件：系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项，读写的就是这个文件。
• ~/.gitconfig 文件：用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项，读写的就是这个文件。
• 当前项目的 Git 目录中的配置文件（也就是工作目录中的 .git/config 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。

在 Windows 系统上，Git 会找寻用户主目录下的 .gitconfig 文件。主目录即 $HOME 变量指定的目录，一般都是 C:\Documents and Settings\$USER。此外，Git 还会尝试找寻 /etc/gitconfig 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。

5、用户信息

第一个要配置的是你个人的用户名称和电子邮件地址。这两条配置很重要，每次 Git 提交时都会引用这两条信息，说明是谁提交了更新，所以会随更新内容一起被永久纳入历史记录：

$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]

如果用了 --global 选项，那么更改的配置文件就是位于你用户主目录下的那个，以后你所有的项目都会默认使用这里配置的用户信息。如果要在某个特定的项目中使用其他名字或者电邮，只要去掉 --global 选项重新配置即可，新的设定保存在当前项目的 .git/config 文件里。

6、文本编辑器

接下来要设置的是默认使用的文本编辑器。Git 需要你输入一些额外消息的时候，会自动调用一个外部文本编辑器给你用。默认会使用操作系统指定的默认编辑器，一般可能会是 Vi 或者 Vim。如果你有其他偏好，比如 Emacs 的话，可以重新设置：

$ git config --global core.editor emacs

7、差异分析工具

还有一个比较常用的是，在解决合并冲突时使用哪种差异分析工具。比如要改用 vimdiff 的话：

$ git config --global merge.tool vimdiff

Git 可以理解 kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff，ecmerge，和 opendiff 等合并工具的输出信息。当然，你也可以指定使用自己开发的工具，具体怎么做可以参阅第七章。

8、查看配置信息

要检查已有的配置信息，可以使用 git config --list 命令：

$ git config --list
user.name=Scott Chacon
[email protected]
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

有时候会看到重复的变量名，那就说明它们来自不同的配置文件（比如 /etc/gitconfig 和 ~/.gitconfig），不过最终 Git 实际采用的是最后一个。

也可以直接查阅某个环境变量的设定，只要把特定的名字跟在后面即可，像这样：

$ git config user.name
Scott Chacon

7.1.3.10 FETCH_HEAD 与 commit-id 概念

FETCH_HEAD： 是一个版本链接，记录在本地的一个文件中，指向着目前已经从远程仓库取下来的分支的末端版本。

commit-id：在每次本地工作完成后，都会做一个git commit 操作来保存当前工作到本地的repo， 此时会产生一个commit-id，这是一个能唯一标识一个版本的序列号。 在使用git push后，这个序列号还会同步到远程仓库。

7.1.3.11 相关文章推荐

• 1、Git 五分钟教程
• 2、Git GUI使用方法
• 3、Github 简明教程
• 5、互联网组织的未来：剖析GitHub员工的任性之源

7.1.4 git常见问题

7.1.4.1 fatal: Not a git repository (or any of the parent directories): .git

1、检查项目是否初始化。初始化命令：git init

2、检查项目是否已以暂存。暂存命令：git add .

3、检查项目是否在本地仓库已提交。提交命令：git commit -m "项目初始化提交"。

7.1.4.2 error: failed to push some refs to 'git@XXX:XXX/origin.git

解决办法：

git push -f origin master
或
git pull

7.1.4.3 fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

1、 git remote –v查看远端地址或者查看配置 git config –list  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-d1ASTQP1-1599485668381)(…/%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5%E6%96%87%E7%AB%A0/assets/20180110204652730194.png)]

2、 git status

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yYPnKVRI-1599485668385)(…/%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5%E6%96%87%E7%AB%A0/assets/20180110204652735077.png)]

3、 git add .  git status  git commit -m “本次要提交的概要信息”  git push origin master把本地文件推送到远程仓库

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-K6fOS21J-1599485668387)(…/%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5%E6%96%87%E7%AB%A0/assets/20180110204652736054.png)]

4、git remote set-url origin [email protected]:namespace master（你的远端地址和命名空间）。

设置远端仓库地址  git push origin master出现以下情况：  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NzH0AQXJ-1599485668390)(…/%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5%E6%96%87%E7%AB%A0/assets/20180110204652738007.png)]

5、解决办法：删除远端当前仓库和当前key，然后重新生成key，ssh-keygen -t rsa -C [email protected] 连敲两次回车键。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-51T5dn71-1599485668393)(…/%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5%E6%96%87%E7%AB%A0/assets/20180110204652741913.png)]

6、会在本地C:\Users\你的用户名.ssh生成文件夹，里面有id_rsa和id_rsa.pub两个文件  然后复制id_rsa.pub文件里面的内容，到https://github.com/settings/keys新建一个，  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zGd8CsFX-1599485668395)(…/%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5%E6%96%87%E7%AB%A0/assets/20180110204652745820.png)]

7、添加远程地址

git remote add origin [email protected]:namespace  
git remote –v查看

8、设置用户名和邮箱地址

git config –global user.name "username"
git config –global user.email "[email protected]"

9、重新推送

git push origin master

7.1.4.4 Please enter a commit message to explain why this merge is necessary

解决办法：

1. （可选）按键盘字母 i 进入insert模式
2. （可选）修改最上面那行黄色合并信息
3. 按键盘左上角”Esc” （退出insert模式）
4. 输入”:wq”,按回车键即可（提交）

gitignore notworking：

git rm -r --cached .
git add .
git commit -m "fixed untracked files"

7.1.4.5 git Failed to connect to www.google.com port 80: Timed out

可能是因为设置了代理：

git config --global http.proxy          //查看代理
git config --global --unset http.proxy  //取消代理

7.1.4.6 HTTP Basic access denied on Git

git config --global --unset credential.helper
git clone '···'
login username，password

7.1.4.7 fatal: unable to get credential storage lock: File exists

把本地项目初始化之后上传到github上出现问题：fatal: unable to get credential storage lock: File exists

解决办法：是因为我上传用的git帐号和我把github建项目的帐号不一致导致的。把账号弄一致就可以了。

7.2 gitlab 版本管理实战

7.2.1 push 创建项目

7.2.1.1 通过WEB 界面创建项目

1、在仪表板中，单击绿色的“新建项目”按钮或使用导航栏右上角的加号图标。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zgHlWLW4-1599485668397)(assets/create_new_project_button.png)]

2、这将打开“新建项目”页面

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-N1h74bd1-1599485668399)(…/%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5%E6%96%87%E7%AB%A0/assets/1532503095349.png)]

3、选择是否要启动空白项目，或使用其中一个预定义的项目模板：这将自动启动存储库代码和CI。否则，如果您在不同的存储库中有项目，则可以通过单击“导入项目”选项卡将其导入，前提是已在GitLab实例中启用了该项目。如果没有，请询问管理员。

4、提供以下信息：

• 在“项目名称”字段中输入项目的名称。您不能使用特殊字符，但可以使用空格，连字符，下划线甚至表情符号。
• 通过项目描述（可选）字段，您可以输入项目仪表板的描述，这将有助于其他人了解您的项目的内容。虽然不是必需的，但最好填写这个。
• 更改“可见性级别”会修改项目对用户的查看和访问权限。
• 选择带有README选项的Initialize存储库会创建一个README，以便初始化Git存储库，具有默认分支并可以克隆。
• 单击创建项目。 完成项目创建，项目创建完后直接跳转到了项目管理与设置页面。

7.2.1.2 通过命令创建项目

当你在本地创建一个新的repo时，不是去GitLab手动创建一个新项目然后推送repo，你可以直接将它推送到GitLab来创建新项目，所有这些都不需要离开你的终端。如果您有权访问该命名空间，我们将在该GitLab命名空间下自动创建一个新项目，默认情况下其可见性设置为Private（您可以稍后在项目的设置中更改它）。

这可以通过使用SSH或HTTP来完成：

## Git push using SSH
git push --set-upstream [email protected]:namespace/cicd-demo-project.git master

## Git push using HTTP
git push --set-upstream https://gitlab.example.com/namespace/cicd-demo-project.git master

推送成功完成后，远程消息将指示设置远程的命令和新项目的URL：

remote:
remote: The private project konyli/cicd-demo-project was successfully created.
remote:
remote: To configure the remote, run:
remote:   git remote add origin http://node2.ringyin.com/konyli/cicd-demo-projec
t.git
remote:
remote: To view the project, visit:
remote:   http://node2.ringyin.com/konyli/cicd-demo-project
remote:

我这里提交的是一个 java 的 Spirng-Boot项目，这个项目稍后会在持续集成中用到。

7.2.2 clone 项目

7.2.2.1 交互界面 clone 项目

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JFrrUDHL-1599485668401)(assets/1532781356884.png)]

使用git和http/https协议进行 clone。

7.2.2.2 命令行 clone 项目

打开 git bash 命令行交互窗口。

1、命令行使用 http 协议

$ git clone http://node2.ringyin.com/konyli/cicd-demo-project.git
Cloning into 'cicd-demo-project'...
Username for 'http://node2.ringyin.com': konyli
Password for 'http://[email protected]':
remote: Counting objects: 68, done.
remote: Compressing objects: 100% (50/50), done.
remote: Total 68 (delta 6), reused 0 (delta 0)
Unpacking objects: 100% (68/68), done.

2、命令行使用 git（ssh）协议

$ git clone [email protected]:konyli/cicd-demo-project.git
Cloning into 'cicd-demo-project'...
Enter passphrase for key '/c/Users/Administrator/.ssh/id_rsa':  #输入口令密码
remote: Counting objects: 68, done.
remote: Compressing objects: 100% (50/50), done.
remote: Total 68 (delta 6), reused 0 (delta 0)
Receiving objects: 100% (68/68), 122.29 KiB | 0 bytes/s, done.
Resolving deltas: 100% (6/6), done.

7.2.3 pull 项目

从另一个存储库或本地分支获取并合并。本地与服务器端同步。但不处理冲突，有冲突也会拉取下来，需要用户自己处理冲突。在远程仓库模拟添加一个 Dockerfile 文件，打开 git bash，本地仓库从远程仓库拉取更新。

$ git pull -v --progress "origin"
Enter passphrase for key '/c/Users/Administrator/.ssh/id_rsa':    #输入口令密码
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From node2.ringyin.com:konyli/cicd-demo-project
   7e7bce1..48fd88f  master     -> origin/master
Updating 7e7bce1..48fd88f
Fast-forward
 Dockerfile | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 Dockerfile

7.2.4 fetch 项目

从另一个存储库下载对象和引用。在远程仓库模拟添加一个 .gitlab-ci.ym 文件，打开 git bash。

git fetch

这将更新git remote 中所有的远程仓库所包含分支的最新commit-id, 将其记录到.git/FETCH_HEAD文件中
git fetch更新远程仓库的方式如下：

#在本地新建一个temp分支，并将远程origin仓库的master分支代码下载到本地temp分支
git fetch origin master:tmp 

#来比较本地代码与刚刚从远程下载下来的代码的区别
git diff tmp 

#合并temp分支到本地的master分支
git merge tmp

#如果不想保留temp分支 可以用这步删除12345678
git branch -d temp

（1）如果直接使用git fetch，则步骤如下：

• 创建并更新本地远程分支。即创建并更新origin/xxx 分支，拉取代码到origin/xxx分支上。
• 在FETCH_HEAD中设定当前分支-origin/当前分支对应，如直接到时候git merge就可以将origin/abc合并到abc分支上。

（2）git fetch origin
​ 只是手动指定了要fetch的remote。在不指定分支时通常默认为master
（3）git fetch origin dev
​ 指定远程remote和FETCH_HEAD，并且只拉取该分支的提交。

查看本地仓库与远程仓库的不同，并将不同输出到 log，如下：

$ git log -p master origin/master
commit d71d14d5ab336c2572e89b389ee5bf36bbe63250
Author: konyli 
Date:   Mon Jul 30 20:01:29 2018 +0800

    增加新文件

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml ##这个是本地仓库与远程仓库的区别
new file mode 100644
index 0000000..d2a229e
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,52 @@
+# This file is a template, and might need editing before it works on your proje
+# Official language image. Look for the different tagged releases at:
+# https://hub.docker.com/r/library/python/tags/
+image: python:latest
+
+# Change pip's cache directory to be inside the project directory since we can
+# only cache local items.
+variables:
+  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache"
+
+# Pip's cache doesn't store the python packages
+# https://pip.pypa.io/en/stable/reference/pip_install/#caching

将本地仓库和远程仓库两个仓库进行合并：

$ git merge origin/master
Updating 48fd88f..d71d14d
Fast-forward
 .gitlab-ci.yml | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 
 1 file changed, 52 insertions(+)
 create mode 100644 .gitlab-ci.yml

我们看到远程仓库上的文件已合并更新到本地仓库了。

7.2.5 pull 与 fetch 以及 push 的区别

首先，基于本地的FETCH_HEAD记录，比对本地的FETCH_HEAD记录与远程仓库的版本号（参考7.1.3.10概念描述），然后git fetch 获得当前指向的远程分支的后续版本的数据，然后再利用git merge将其与本地的当前分支合并。所以可以认为git pull是git fetch和git merge两个步骤的结合。 git pull的用法如下：

git pull <远程主机名> <远程分支名>:<本地分支名>
//取回远程主机某个分支的更新，再与本地的指定分支合并。12

因此，与git pull相比git fetch相当于是从远程获取最新版本到本地，但不会自动merge。如果需要有选择的合并git fetch是更好的选择。效果相同时git pull将更为快捷。

git pull 的运行过程：

基于本地的FETCH_HEAD记录，比对本地的FETCH_HEAD记录与远程仓库的版本号。

git fetch 的运行过程：

获得当前指向的远程分支的后续版本的数据，再利用git merge将其与本地的当前分支合并。

需要注意的是: fetch和push不同, fetch会自动获取远程`新加入’的分支.

7.2.6 commit 项目

7.2.6.1 交互界面 commit 项目

7.2.6.2 命令行 commit 项目

我们试着在项目目录下把 README.MD 文件删除，打开 git bash 测试提交。

$ git commit -a -m "test git commit" # -a：先要添加到暂存区，再commit本地仓库，-m：是提交注释
[master 7e7bce1] test git commit
 1 file changed, 1 deletion(-)
 delete mode 100644 README.md

7.2.6.3 ignore 忽略 commit 文件和文件夹

我们可以通过修改.gitignore配置文件，把要忽略 ignore 过滤 commit 的文件或文件夹增加到该配置文件中。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Bz8EI60B-1599485668403)(assets/697835-20151214150548677-1031444477.png)]

7.2.6.3 push到远程仓库

$ git push -f origin master
Enter passphrase for key '/c/Users/Administrator/.ssh/id_rsa':   #输入口令密码
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 221 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
To [email protected]:konyli/cicd-demo-project.git
   27f5239..7e7bce1  master -> master

注意:

为避免提交的文件在远程仓库产生乱码，文件统一编码格式为：utf-8。

尤其是文本文件和内含有中文的文件，强制统一编码格式。

7.2.7 设置 git 提交免输入账号和密码

在使用git时，如果用的是HTTPS或http的方式，则每次提交，都会让输入用户名和密码，久而久之，就会感觉非常麻烦，那么该如何解决呢？git官方参考文档：7.14 Git 工具 - 凭证存储

7.2.7.1 方式一：使用SSH，添加ssh key。

参考前一章节生成 sshd-keygen 说明。

7.2.7.2 方式二：在全局中存储用户的账号密码

在%HOME%目录中，一般为C:\users\Administrator，也可以是你自己创建的系统用户名目录，反正都在C:\users***中。创建.git-credentials文件。

Windows中创建以.开头的文件的方法：

1：新建test.txt记事本，然后另存为.git-credentials

2：使用git bash

touch .git-credentials1

创建完成后，打开编辑文件，在该文件中输入：

vi .git-credentials1
https://username:[email protected]
注：username对应你的用户名，password对应你的密码
ps：当用户名为邮箱时，需要把用户名的@转义为%40

然后再进入git bash中

git config --global credential.helper store1

store为永久存储，当然也可以设置临时的

git config –global credential.helper cache1

默认为15分钟，如果想设置保存时间的话，可以输入：

git config credential.helper ‘cache –timeout=3600’1

这样就设置了一个小时的有效时间。

执行完后查看%HOME%目录下的.gitconfig文件，会多了一项：

[credential]helper=store

重新开启git bash会发现git push时不用再输入用户名和密码

7.2.7.3 方式三：单独对某个项目免账号

如果还未添加远程地址，可以输入一下命令：

git remote add origin https://username:[email protected]/namespace/cicd-demo.git 1

如果已添加远程地址

最为简单的方式就是，直接在.git/config文件中进行修改，按如上格式，添加用户名和密码

[core]
	repositoryformatversion = 0
	filemode = false
	bare = false
	logallrefupdates = true
	symlinks = false
	ignorecase = true
	hideDotFiles = dotGitOnly
[remote "origin"]
	url = http:/username:[email protected]/konyli/cicd-demo-project.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master

7.2.8 项目分支和标签

7.2.8.1 查看分支

1、查看本地分支

 git branch

2、查看远程分支

git branch -a

注：其中，remotes开头的代表是远程分支。

7.2.8.1 创建项目分支

1、创建本地分支

git branch 1.0.x

2、切换分支

git checkout 1.0.x

注：1.0.x 是分支名，名字你ikey随便取，只要不违反git取名规则即可。

3.创建远程分支

git push origin :1.0.x

7.2.8.2 clone 项目分支

使用Git colone 指定分支命令为：git clone -b 分支名仓库地址。

比如要 clone 分支名称为1.0.x的代码，使用命令：

git clone -b 1.0.x https://git.oschina.net/oschina/xxx.git

命令解释：

-b：表示要从分支下载

1.0.x：分支的名称

git仓库地址：https://git.oschina.net/oschina/xxx.git

从远程分支上下代码：

$ git clone -b 1.0.x https://git.oschina.net/oschina/xxx.git

clone远程仓库到制定目录：

git clone https://git.oschina.net/oschina/xxx.git "指定目录"

7.2.8.3 push 项目分支

先做本地提交，再 push 到远程仓库，第一次创建的分支，无法pull，只能 push。

$ git push origin 1.0.x:1.0.x

从远程 pull

git pull origin 1.0.x:1.0.x

在本地1.0.x分支上修改了代码后，需要提交到远程，这时就需要关联远程的某个远程分支。

注：如果不写远程分支名称，则默认和本地分支同名，这时命令为：$ git push origin 1.0.x

7.2.8.4 删除项目分支

1、删除本地分支

git branch -d v1.0.x

删除分支发生错误：error: Cannot delete the branch ‘v1.0.x’ which you are currently on.

错误原因：是因为你在当前分支下，所以不能删除。

错误处理：要删除该分支，先要退出该分支，使用命令切换退出到其他分支，再删除分支

git checkout 1.0.x
git branch -d v1.0.x

2、删除远程分支

 $ git push origin --delete 1.0.x

7.2.8.3 创建项目标签

7.2.8.4 clone 项目标签

7.2.9 项目代码库回滚

git代码库回滚: 指的是将代码库某分支退回到以前的某个commit id

7.2.9.1本地代码库回滚

#回滚到commit-id，将commit-id之后提交的commit都去除
git reset --hard commit-id

#将最近3次的提交回滚
git reset --hard HEAD~3

7.2.9.2 远程代码库回滚

这个是重点要说的内容，过程比本地回滚要复杂
应用场景：自动部署系统发布后发现问题，需要回滚到某一个commit，再重新发布
原理：先将本地分支退回到某个commit，删除远程分支，再重新push本地分支
操作步骤：

git checkout 1.0.x
git pull
#备份一下这个分支当前的情况
git branch 1.0.x_backup 
#把the_branch本地回滚到the_commit_id
git reset --hard the_commit_id 
#删除远程 the_branch
git push origin :1.0.x
#用回滚后的本地分支重新建立远程分支
git push origin 1.0.x 
#如果前面都成功了，删除这个备份分支
7、git push origin :1.0.x_backup

如果使用了gerrit做远程代码中心库和code review平台，需要确保操作git的用户具备分支的push权限，并且选择了 Force Push选项（在push权限设置里有这个选项）

另外，gerrit中心库是个bare库，将HEAD默认指向了master，因此master分支是不能进行删除操作的，最好不要选择删除master分支的策略，换用其他分支。

如果一定要这样做，可以考虑到gerrit服务器上修改HEAD指针。。。不建议这样搞。

一般部署的是master分支，应该重master分支切分支修改，然后 往master上合并，再发版 。

7.3 git 在 IDE 集成环境中的实践

7.3.1 配置 IDE 集成环境

​ 这里以 IDE Eclipse 环境为例，说明 git 的配置，打开 Eclipse，点击 window，点击 preferences，调查下面窗口：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Xur51gyX-1599485668407)(assets/1532937365818.png)]

选择生成的ssh 密钥 key的位置，具体如何生成参考上一章的说明。

配置 git，点击 team，点击 git 和 Configuration，配置用户名和 email，如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tnViruwI-1599485668409)(assets/1532938857860.png)]

打开选择.gitconfig文件，也可以修改下面的配置。

7.3.2 创建并共享项目

在 eclips 中创建一个项目，项目创建完之后，点击右键 Team ——》点击 share project 进入下面界面：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FeXuRefa-1599485668411)(assets/1533006493794.png)]

配置 Configure Git Repository，选择复选框 Use or create repository in parent folder of project 作为本地仓库。完成项目共享，到这一步，该项目已纳入 git 仓库本地化管理。简单来说就是做了 git init 命令做的事情。

7.3.3 commit 到本地仓库

选中项目点击右键——》点击 Team ——》点击 Commit，出现如下界面：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PoMrH2D1-1599485668413)(assets/1533006955070.png)]

填写提交注释，描述为什么提交。选择要提交的文件。点击提交，完成项目真正的本地化仓库的管理。

7.4.4 项目远程仓库提交

7.4.4.1 远程仓库创建一个空项目

登录 Gitlab 远程仓库，在你的远程仓库中创建一个与本地仓库相同项目名称的空仓库。

7.4.4.2 本地项目 push 到远程仓库

选中项目点击右键——》选中 Team ——》选择 Remote ——》点击 Push，出现下面界面：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Q5hEwYv0-1599485668415)(assets/1533008218777.png)]

• 单击Next并在第一个连接上接受 Gitlab 主机密钥。
• 输入你的SSH密钥的密码，然后点击OK。
• 在下一个向导页面上，单击“添加所有分支规范”，将本地分支名称1:1映射到目标存储库中的相同分支名称。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jZ271dxM-1599485668416)(assets/1533008618101.png)]

• 单击Next。“push 确认”对话框将显示将被推送到目标存储库的更改的预览。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AWKme7MT-1599485668418)(assets/1533008740549.png)]

• 单击“Finish”确认要 push 这些更改。

• 下一个对话框报告 push 操作的结果。

• 在浏览器访问你的 Gitlab 远程仓库，可以查看新项目下 push 是否成功。

7.3.4 Push 错误处理

1、Push 出现以下提示处理。

pre-receive hook declined
GitLab: You are not allowed to force push code to a protected branch on this project.

说明远程仓库项目是受保护的，在 Gitlab 中进入该项目，点击设置——》仓库——》

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5rYr4RiQ-1599485668421)(assets/1533009876954.png)]

点击展开修改设置，点击解除保护。重新 Push 一下。

2、Push 出现以下错误处理。

master [rejected - non-fast-forward]，这个问题有两种处理方法。

1）处理方法一

具体处理步骤如下：

（1）打开 Git Repositories，在 Working Directory 中确保可以看到要提交的工程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AdAnh34e-1599485668423)(assets/1533011154473.png)]

（2）在 Remotes 中可以看到远端分支，右键点击分支——》点击 Configure Fetch，打开下面界面。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HIvSGkrE-1599485668425)(assets/1533010960663.png)]

确认 URI 和 Ref mappings 都是正确的，点击 Save and Fetch，之后可以看到 Fetch Results 分支在一起，点击OK 。此时在 Branches 中应该可以看到 Remote Tracking 存在远端分支 。

（3）右键 Branches 中的 Local 中的 master，选择 Merge 。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NKcrzUfT-1599485668428)(assets/1533018287048.png)]

点击 Merge…进入第4步。

（4）选择 Remote Tracking 中的 origin/master，点击 Merge 。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AzTD9gKc-1599485668431)(assets/1533010894216.png)]

（5）完成合并后，重新提交代码。

2）处理方法二

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rHGLzvGl-1599485668433)(assets/1533019237574.png)]

在 push 的时候选中 Force Update 强制更新复选框。这个可能存在一定的风险，在多人开发的时候，当别人在现有分支提交了代码，而你没有及时更新的话，由可能会覆盖别人的成果。建议使用第1种方式处理，先做合并同步，做 push 提交更新。

7.4 Maven 安装与配置

7.4.1 下载 Maven

官网下载地址：http://maven.apache.org/download.cgi

选择 v3.5.4 版本

#新建目录
[root@node1 ~]# mkdir /opt/maven
[root@node1 ~]# cd /opt/maven
[root@node1 maven]# wget http://mirrors.tuna.tsinghua.edu.cn/apache/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gz

7.4.2 安装 Maven

[root@node1 maven]# tar -xzvf apache-maven-3.5.4-bin.tar.gz 

7.4.3 配置Maven环境变量

#打开系统配置文件
[root@node1 apache-maven-3.5.4]# vi /etc/profile
export M2_HOME=/opt/maven/apache-maven-3.5.4
export PATH=$PATH:$M2_HOME/bin

#使环境变量配置生效
[root@node1 apache-maven-3.5.4]# source /etc/profile

7.4.4 验证 Maven 安装

#验证Maven是否安装成功
[root@node1 apache-maven-3.5.4]# mvn -v
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T02:33:14+08:00)
Maven home: /opt/maven/apache-maven-3.5.4
Java version: 1.8.0_172, vendor: Oracle Corporation, runtime: /opt/java/jdk1.8.0_172/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.10.0-693.el7.x86_64", arch: "amd64", family: "unix"

7.5 gitlab 与 Jenkins 集成自动化 CI 构建实践

注意：

注意：在GitLab 8.3中，不赞成使用GitLab Hook插件的Jenkins集成，而使用GitLab插件。已弃用的集成已在项目服务设置中重命名为Jenkins CI（已弃用）。我们可能会在将来的版本中删除它，并建议使用本文档中描述的新“Jenkins CI”项目服务。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wr6MySfN-1599485668435)(assets/1533200790217.png)]

7.5.1 概述

Jenkins是一个很棒的持续集成工具，类似于我们内置的GitLab CI。 当您将代码推送到存储库或创建合并请求时，GitLab的Jenkins集成允许您触发Jenkins构建。此外，它还显示合并请求窗口小部件和项目主页上的管道状态。

集成官方文档参考地址：https://docs.gitlab.com/ee/integration/jenkins.html

7.5.2 用例

• 假设您是GitLab的新手，并希望继续使用Jenkins，直到您准备使用GitLab CI / CD构建项目为止。您在GitLab和Jenkins之间设置了集成，然后稍后迁移到GitLab CI。当您组织自己和团队加入GitLab时，您可以使用Jenkins运行管道，但在GitLab中查看项目存储库中的结果。
• 您的团队使用Jenkins插件（ Jenkins Plugins ）进行其他操作，因此，您选择继续使用Jenkins构建您的应用程序。直接在GitLab中显示管道的结果。

7.5.3 要求

• Jenkins GitLab Plugin
• Jenkins Git Plugin
• 从GitLab存储库获取Jenkins的Git克隆访问权限
• GitLab API访问报告构建状态

7.5.4 配置GitLab用户

创建用户或选择Jenkins将用于通过GitLab API进行交互的现有用户。

此用户需要是全局管理员或添加为每个组/项目的成员。报告构建状态需要开发人员权限。这是因为成功的构建状态可以在使用“管道成功时合并”功能时触发合并。

GitLab插件的某些功能可能需要其他权限。例如，如果构建成功，则可以选择接受合并请求。使用此功能需要开发人员，主人或所有者级别的权限。

从用户账号——》设置 ——》访问令牌——》创建个人访问令牌，创建完后复制私有API令牌。稍后配置Jenkins服务器时需要该令牌。

7.5.5 配置 Jenkins 服务器

安装Jenkins GitLab插件（Jenkins GitLab Plugin ）和Jenkins Git（ Jenkins Git Plugin ）插件。 转到Manage Jenkins - > Configure System（系统管理）- >系统设置，并向下滚动到’GitLab’部分。在“GitLab主机URL”字段中输入GitLab服务器URL，然后将先前复制的API令牌粘贴到“API令牌”字段中。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-etgMl4W2-1599485668436)(…/%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5%E6%96%87%E7%AB%A0/assets/jenkins_gitlab_plugin_config.png)]

7.5.6 配置Jenkins项目

按照使用它与作业标题下的GitLab插件文档。您无需在“GitLab配置（> = 8.0）”下完成说明。请务必按照“GitLab配置（> = 8.1）”中的说明选中“使用GitLab CI功能”复选框。

创建一个新Jenkins项目构建任务或选择一个现有项目。然后对该项目构建任务进行配置，配置如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-efsPmqnN-1599485668439)(assets/1533203031113.png)]

重点看构建触发器的配置，其他配置项可参考 7.6 节以及第6章jenkins的安装与配置内容介绍。配置完后点击保存，开始进入配置Gitlab项目。

7.5.7 配置GitLab项目

创建一个新的GitLab项目或选择一个现有项目。然后，进入项目——》设置——》Integrations Settings（本地化或汉化后的名字是“导入所有仓库”）。 选择是否希望GitLab在推送，合并请求创建，标记推送或这些的任意组合上触发构建。我们建议取消选中“合并请求事件”，除非您有一个特定的用例，需要在创建合并请求时重新构建提交。

选择“推送事件”后，GitLab将在每次推送时构建最新提交，并且构建状态将显示在合并请求中。 输入Jenkins URL和项目名称。项目名称应该是URL友好的，其中空格用下划线替换。为安全起见，请在查看Jenkins项目时从浏览器的URL栏复制项目名称。 （可选）如果Jenkins服务器需要身份验证，请输入用户名和密码。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mzxm0Gfm-1599485668442)(assets/1533203620426.png)]

配置完成后，点击增加Web 钩子。在下面有一个Web 钩子 (1)列表，可以对刚才的配置进行push测试，增加完和测试效果如下。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Hds8upVq-1599485668444)(assets/1533204024647.png)]

看下 jenkins 的项目构建任务是否被触发了，进入 jenkins 查看如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Zm4GWsk7-1599485668446)(assets/1533204499229.png)]

可以向仓库提交代码做一次测试。

gitlab与jenkins集成，随着gitlab的版本不断更新升级，官方配置文档却没有及时更新，还是老版本的配置说明，搞了我很多时间也绕了一些弯路，严格按照官方文档。

这可能与gitlab官方想推自己内置的Runner实现的CI&CD应该也是有关系的，下面会有一节做这方面的介绍。

7.5.8 插件功能概述

GitLab不包含列出提交的数据库表。始终直接从存储库中读取提交。因此，无法在GitLab中保留提交的构建状态。通过从集成CI工具请求构建信息可以克服这一问题。 CI工具负责为提交和合并请求创建和存储构建状态。

7.5.9 实现类似集成所需的步骤

注意：所有步骤都是使用合并请求页面上的AJAX请求实现的。

1. 要在合并请求中显示构建状态，您必须在GitLab中创建项目服务。

2. 您的项目服务将使用提交的SHA1对CI工具的URL执行（JSON）查询。

3. 项目服务根据项目服务设置和CI工具的知识构建此URL和有效负载。

4. 解析响应以在GitLab中给出响应（成功/失败/挂起）。

7.6 Jenkins 持续集成构建任务实践

7.6.1 实践目标

实现只要开发提交代码到gitlab，jenkins就会自动检测到并且自动进行构建（合并、打包），构建完成之后将打好的包（war、jar包都可以）通过jenkins的插件传到maven私服仓库、docker镜像仓库、tomcat的webapps目录下，然后重启tomcat，实现自动打包部署。

7.6.2 持续集成结构图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8D4Y5AFI-1599485668449)(assets/1532503058921.png)]

7.6.3 创建一个 Jenkins 新任务

管理员账号登录 jenkins，点击创建一个新任务，进入页面如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-A5hEI8H6-1599485668452)(assets/1533114059107.png)]

取一个任务名称，选择项目任务构建类型。点击确定，进入项目任务配置页面。

7.6.4 配置项目构建任务

7.6.4.1 使用http/https协议配置构建任务源码管理

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-a6HyBPPE-1599485668454)(assets/1533123627465.png)]

点击保存，完成构建任务配置。

7.6.4.2 使用 ssh/git 协议配置构建任务源码管理

1、生成访问Gitlab的ssh秘钥

从gitlab以SSH方式拉取或提交代码需要用到这个SSH 秘钥，哪台机器需要从gitlab上拉取代码，就在哪台机器上生成一次SHH Key，因此，在jenkins服务器上，以及你的开发PC上，都需要生成SSH密钥。

在jenkins机器上生成ssh key：

[root@node1 ~]# ssh-keygen -t rsa -C "[email protected]" -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
/root/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.  
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:ebAfWQVyum8EnuqLlCiPcoKRPlAsz/+TG6n/keOQEBk [email protected]
The key's randomart image is:
+---[RSA 4096]----+
|    E     . o..  |
|     o     + .   |
| .  o   . o .    |
|. o  .   = *     |
| *  .   S B .    |
|+ o  o + = +     |
|+.... B.= . o    |
|+o.+.oo* o .     |
| +o oo=+=.       |
+----[SHA256]-----+

其它的具体生成ssh-keygen密钥的方式请参考第6章Gitlab的安装与配置的6.5节内容。

ssh key说明：

## 这个是私钥，在jinkens构建任务重的源码管理需要配置使用的。
Your identification has been saved in /root/.ssh/id_rsa.  
## 这个是公钥，这个是要配置到gitlab的用户设置里面的
Your public key has been saved in /root/.ssh/id_rsa.pub.

## 通过查看命令拷贝出来
vi /root/.ssh/id_rsa
vi /root/.ssh/id_rsa.pub

2、配置构建任务的源码管理

选择“源码管理”，选择“Git”,然后去GitLab中复制项目地址，粘贴到“Repository URL”,然后点击“credentials”后面的“Add”按钮，配置 Credentials 。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-50fW0dfX-1599485668456)(assets/1533208903201.png)]

上面一堆红色很恐怖？地址拷贝过去jenkins就发送ajax请求到gitlab服务器上去验证了，验证不通过所产生的错误提示。等配置正确Credentials了就会消失了，好下一步配置解决它。

3、配置 Credentials

在弹出页面里面：

• Kind 选择 SSH Username with private key
• Username 填 root
• PrivateKey 选择 From a file on jenkins master ，然后将服务器的 私钥的存放路径（私钥、私钥、私钥，再说三遍） 粘贴进去
• passphrase 填创建SSH秘钥时的设置的密码，未设置可不填
• ID 和 描述你随意填

具体配置界面如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RvY9578a-1599485668459)(assets/1533209589027.png)]

点击添加完成Credentials资格的配置，回到源码管理配置页面，看看一大串红色一会儿是不是消失了。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ubvemVUL-1599485668467)(assets/1533209940920.png)]

不错确实消失了吧！（^~）。其他的配置参考http/https协议的一样配置处理即可。

点击保存，进入主页面，可以启动项目任务构建了。

7.6.5 启动项目任务构建

点击立即构建，开始启动项目任务构建，在左边点击查看控制台输出，可以查看任务构建进度，如下图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-M8tbXfWL-1599485668469)(assets/1533121685126.png)]

单元测试构建完了

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CqTNM2ec-1599485668472)(assets/1533121841741.png)]

最后任务构建成功，用时18分钟31秒

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MzZUluZZ-1599485668474)(assets/1533122019594.png)]

7.6.6 配置构建触发器

除了上面通过gitlab集成jenkins由gitlab推送触发构建的方式，还有其他几种配置构建触发器的配置方式。

配置Job的构建触发器，选择“构建触发器”，勾选“Pull SCM”，这个选项会每隔一段时间检查一下GitLab仓库中代码是否有更新，有的话就执行构建操作。日程表如何设置，在这个输入框下面有说明。

• Build after other projects are built 当另一个构建任务完成之后触发
• Build periodically 周期性的触发
• Build when a change is pushed to GitLab. GitLab CI Service URL:http://xxx.com/cicd.git. 当代码有更新的时候触发，通过GitLab CI
• GitHub hook trigger for GITScm polling 通过Github钩子触发
• Poll SCM 定期检查代码有无更新，有更新时触发

具体使用哪种构建触发器可以根据情况选择。

还有依赖构建。就是当前构建要依赖前面的构建成功，才能构建它自己。

如果选择“Poll SCM”，然后在日程表里填上cron表达式，例如"H/5 * * * *"，表示每5分钟检查一次，有代码变更就构建项目。这里我们不选Poll SCM，而是用Gitub插件来做到实时构建。

7.6.7 配置构建后操作

1） PublishJavadoc：设置构建时产生JavaDoc时的文件目录；

2） Archivethe artifacts:设置构建后哪些文件需要进行归档处理；

3） E-mailNotification：邮件提醒。可以向多个人发送邮件，通过“；”进行分割

4） StatusMonitor：构建状态监控；

/var/lib/jenkins/workspace

7.6.7.1 publish over ssh 插件配置

实现 Jenkins 远程部署

该插件主要是通过SSH连接其他Linux机器，远程传输文件及执行Shell命令。

特性：

1、SCP—通过SSH发送文件
2、在远程服务器执行shell命令
3、Passwords/passphrases在配置文件及UI界面是加密显示的
4、SSH可在项目编译前或编译后执行，与是否编译成功无关
以下是使用该插件的相关步骤：

第一步：配置Linux系统的SSH服务免密码登录

可参考Jenkins创建slave节点—-Linux平台的第一部分

第二步：在系统管理–>系统设置中添加SSH Server

• 公共配置
  Passphrase：密码（key的密码。如果有设置）
  Path to key：key文件（私钥）的路径
  Key：将私钥复制到这个框中
  Disable exec：禁止运行命令
  注意：一般来说，我们会采用同每一个SSH Server单独配置的方式，因此公共配置部分一般不进行设置

• 私有配置
  SSH Server Name：标识的名字，可随便取
  HostName：需要连接ssh的主机名或IP地址
  Username：SSH连接所使用的用户名
  Remote Directory：用SSH连接后的远程根目录，这个目录是必须存在的，Jenkins不会自动创建目录。Jenkins会将文件远程复制到该目录。(注意：SSH连接的用户需要有权限才可以创建、删除、移动文件及文件夹)
  Use password authentication, or use a different key：使用密码认证或密钥认证

• 私有配置的高级
  Port：SSH连接端口号（默认为22）
  Timeout (ms)：连接超时的时间，单位以毫秒计算
  Disable exec：禁止exec执行命令
  Test Configuration：测试配置是否成功

7.6.7.2 SSH插件配置

搭建jenkins实现自动化部署

https://blog.csdn.net/achuo/article/details/51086599

jenkins构建并远程发布后执行shell脚本

https://blog.csdn.net/u012599988/article/details/44041339

jenkins构建后邮件发送

https://blog.csdn.net/songjiaping/article/details/51496977

gitlab Runner 构建任务

官方：https://docs.gitlab.com/runner/

6.6.1 简介

GitLab Runner是用于运行作业并将结果发送回GitLab的开源项目。它与GitLab CI结合使用，GitLab CI是GitLab中协调工作的开源连续集成服务。

6.6.2 Requirements

GitLab Runner是用Go编写的，可以作为一个二进制文件运行，不需要任何语言特定的要求。它被设计为在GNU / Linux，macOS和Windows操作系统上运行。只要您可以编译一个Go二进制文件，其他操作系统就可能会工作。

6.6.3 Features

6.6.3.1 Allows to run

• multiple jobs concurrently(多个工作同时进行)
• use multiple tokens with multiple server (even per-project)( 使用多个令牌与多个服务器（甚至每个项目）)
• limit number of concurrent jobs per-token(限制每个令牌的并发作业数)

6.6.3.2 Jobs can be run

• locally(本地)
• using Docker containers(使用Docker容器)
• using Docker containers and executing job over SSH(使用Docker容器并通过SSH执行作业)
• using Docker containers with autoscaling on different clouds and virtualization hypervisors(使用Docker容器在不同的云和虚拟化管理程序上进行自动缩放)
• connecting to remote SSH server(连接到远程SSH服务器)

6.6.4 安装

#安装gitlab-ci-multi-runner源
[root@gitlab ~]#curl -Lhttps://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh| sudo bash

#安装
[root@gitlab ~]#yum installgitlab-ci-multi-runner

6.6.5 gitlab-runner使用

必须是在8版本以上才能使用这个集成功能，文档：https://docs.gitlab.com/runner/commands/README.html

语法：gitlab-runner

[root@gitlab ~]# gitlab-runner --help
USAGE:
   gitlab-runner[global options] command command options

COMMANDS
名称	作用
exec	显示runner配置文件
list
run	运行多个runner服务
register	注册一个新的runner
install	安装服务
uninstall	卸载服务
start	启动一个服务
stop	停止一个服务
restart	重启
status	一个服务状态
run-single	运行单独的一个runner
unregister	注销特定的runner
verify	验证所有注册的runner

artifacts-downloader downloadand extract build artifacts (internal)

artifacts-uploader create andupload build artifacts (internal)

cache-archiver create and uploadcache artifacts (internal)

cache-extractor download andextract cache artifacts (internal)

例子：

#list
[root@gitlab ~]# gitlab-runner list
Listing configured runners                         ConfigFile=/etc/gitlab-runner/config.toml

#debug
[root@gitlab ~]# gitlab-runner --debug  list
Runtime platform                                    arch=amd64 os=linuxrevision=0118d89 version=9.1.0
Listing configured runners                         ConfigFile=/etc/gitlab-runner/config.toml
gitlab-ci-multi-runner

[root@gitlab gitlab]# gitlab-ci-multi-runnerregister --help

6.6.6 Runner类型

GitLab-Runner可以分类两种类型：

Shared Runner（共享型）：

这种Runner（工人）是所有工程都能够用的。只有系统管理员能够创建Shared Runner。

Specific Runner（指定型）：

这种Runner（工人）只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

6.6.7 注册runner

1，copy 注册授权码

2，register

安装好gitlab-ci-multi-runner这个软件之后，我们就可以用它向GitLab-CI注册Runner了。

向GitLab-CI注册一个Runner需要两样东西：GitLab-CI的url和注册token。

其中，token是为了确定你这个Runner是所有工程都能够使用的Shared Runner还是具体某一个工程才能使用的Specific Runner

#查看register帮助
[root@gitlab gitlab]# gitlab-ci-multi-runnerregister --help

#注册Shared Runner

在注册Runner的时候，需要填入Token，GitLab根据不同的Token确定这个Runner是被设置为Shared Runner还是Specific Runner

[root@gitlab gitlab]# gitlab-ci-multi-runnerregister
Running in system-mode.      
Please enter the gitlab-ci coordinator URL(e.g. https://gitlab.com/):
http://192.168.201.148/ci#输入ci
Please enter the gitlab-ci token for thisrunner:
2RBdZavdy6UsZvbyCcMF#注册授权码
Please enter the gitlab-ci description for thisrunner:

[gitlab.server.com]: test_runner #描述
Please enter the gitlab-ci tags for this runner(comma separated):
hello_tom #写个标签，可以多个，用逗号隔开
Whether to run untagged builds [true/false]:
[false]: #输入回车   
Whether to lock Runner to current project[true/false]:
[false]: #输入回车
Registering runner... succeeded                     runner=2RBdZavd
Please enter the executor: virtualbox, docker-ssh+machine,kubernetes, parallels, shell, ssh, docker+machine, docker, docker-ssh:
shell #输入选择通讯方式
Runner registered successfully. Feel free tostart it, but if it's running already the config should be automaticallyreloaded!

#查看服务是否运行
[root@gitlab gitlab]# ps -ef|grep runner
root      7998      1  0 13:09 ?        00:00:02/usr/bin/gitlab-ci-multi-runner run --working-directory /home/gitlab-runner --config/etc/gitlab-runner/config.toml --service gitlab-runner --syslog --usergitlab-runner

注意：

*如果不运行gitlab-ci-multi-runner register命令，直接在配置文件里面添加Runner的配置信息可以吗

当然不行。因为gitlab-ci-multi-runner register的作用除了把Runner的信息保存到配置文件以外，还有一个很重要的作用，那就是向GitLab-CI发出请求，在GitLab-CI中登记这个Runner的信息并且获取后续通信所需要的token。**

3，查看register

# 登陆

http://my_url/admin/runners

#查看gitlab-runner配置文件
[root@gitlab ~]# cat/etc/gitlab-runner/config.toml
concurrent = 1
check_interval = 0
[[runners]]
  name ="test_ci"
  url ="http://192.168.201.148/ci"
  token ="c6f62fe5a2b4ec072f5cc2fb096c02"
 executor = "shell"
 [runners.cache]

4，运行runner

​ 要让一个Runner运行起来，–url、–token和–executor选项是必要的.

[root@gitlab gitlab]# gitlab-ci-multi-runnerrun-single --help
[root@gitlab ~]# gitlab-ci-multi-runner install--user=gitlab-runner --working-directory=/home/gitlab-runner

[root@gitlab ~]# gitlab-ci-multi-runner status
gitlab-runner: Service is running!

[root@gitlab test]# gitlab-ci-multi-runner list
Listing configured runners                          ConfigFile=/etc/gitlab-runner/config.toml
popop                                              Executor=shell Token=8bfcd3b988ae348111b5500a355273URL=http://192.168.201.149/ci

5，yaml

https://docs.gitlab.com/ee/ci/yaml/README.html

从7.12版本开始，GitLab CI使用YAML 文件(.gitlab-ci.yml)来配置project’s builds

.gitlab-ci.yml 使用YAML语法， 需要格外注意缩进格式，要用空格来缩进，不能用tabs来缩进。

gitlab runner 实战

6.7.1 http客户端测试

6.7.1.1 创建测试目录

[root@client ~]# mkdir test2
[root@client ~]# cd test2

6.7.1.2 clone服务器上仓库

[root@cleint test2]# git clone http://gitlab.server.com/root/test.git
Cloning into 'test'...
warning: You appear to have cloned an emptyrepository.
Checking connectivity... done.

或者

[root@cleint test2]# git clone http://gitlab.server.com/root/test.git
Username for 'http://git.server.com':root
Password for 'http://[email protected]':adminroot
Counting objects: 3, done.
Writing objects: 100% (3/3), 216 bytes | 0bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To http://git.server.com/root/go.git
 * [newbranch]      master -> master
Branch master set up to track remote branchmaster from origin.

[root@git test2]# ls
test

6.7.1.3 配置用户

[root@cleint test2]# git config --globaluser.name "Administrator"
[root@client test2]# git config --globaluser.email "[email protected]"
[root@client test2]# cd test/

6.7.1.4 创建文件

[root@client test]# touch README.md
[root@client test]# vi README.md
[root@client test]# git add README.md
[root@client test]# git commit -m "addREADME"
[master (root-commit) 874889b] add README
 1 filechanged, 1 insertion(+)
 createmode 100644 README.md

6.7.1.5 push

[root@client test]# git push -u origin master
Username for 'http://git.server.com': root
Password for 'http://[email protected]': adminroot
Counting objects: 3, done.
Writing objects: 100% (3/3), 223 bytes | 0bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To http://git.server.com/root/test.git
 * [newbranch]      master -> master
Branch master set up to track remote branchmaster from origin.

从web上查看test仓库下是否上传了README.md这个文件

查看是否成功

上传成功

6.7.2 ssh客户端测试

6.7.2.1 生成公钥

[root@node6 .ssh]# ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key(/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in/root/.ssh/id_rsa.
Your public key has been saved in/root/.ssh/id_rsa.pub.
The key fingerprint is:
d9:0d:43:2b:17:cc:3b:01:fa:c9:cb:2c:6e:b7:27:6droot@node6
The key's randomart image is:
+--[ RSA 2048]----+

|       .+o      |

|       ..+o     |

|      .. =o     |

|       o*o+     |

|       S ...    |

|       o.       |

|      .+.       |

|    ...o E      |

|    ....=       |

+-----------------+

[root@node6 .ssh]#
[root@node6 .ssh]# ls
id_rsa id_rsa.pub

[root@node6 .ssh]# cat id_rsa.pub
ssh-rsaAAAAB3NzaC1yc2EAAAABIwAAAQEAoOLsYhPPlHPOnGh6SoVDPlVn2o8rfO55J60Gz7E0EDB0ugKgTu4VGOE8vVta7HH5exNAjw2UqHIliYcmVvrj5eFbvXLdLYGypiMfuP4H7dVwGXfxSzeG17aIbZma0fpB2bTQr3tN+nVA7tokVSmO+jC61/H6Qj9G1TEiedq0wtTuSQ8pza5hyeWRO9oi0W7ccZkYg7lSQ3Eo2n2/RJbmQHWdIcoBO8c64h5vq/gB1s7ZjHKUjSFvGTyHu7uYE6yD2PXylavLfq2FHUc4syV8yAvyW2ehgIcc+xDWMFC85SNuPvTOt0YNzG628gWB2lm+D8CPhZBUbz2IUkFN0jEdyQ==root@node6

#添加域名（如果是真实的域名，这步不需要做）
[root@node6 .ssh]# vi /etc/hosts
192.168.201.131 git.server.com

#添加到gitlab上

6.7.2.2 测试ssh是否可用

[root@node6 .ssh]# ssh -T [email protected]
The authenticity of host 'git.server.com(192.168.201.134)' can't be established.
RSA key fingerprint is45:1f:76:55:cb:72:fe:65:22:75:10:eb:d5:2e:35:d5.
Are you sure you want to continue connecting(yes/no)?yes
Warning: Permanently added'git.server.com,192.168.201.134' (RSA) to the list of known hosts.
Welcome to GitLab, Administrator!
证明成功

6.7.2.3 克隆数据

[root@node6 .ssh]# git clone [email protected]:root/test.git
Initialized empty Git repository in/root/.ssh/test/.git/
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), 223 bytes, done

6.7.3 Gitlab-runner

在创建register之前**，需要拿到token和ci地址**

1，找到你要register的项目地址

2，进入到这个项目

3，点击设置

4，点击pipline，查看token和ci

6.7.3.1 register

[root@gitlab test]# gitlab-ci-multi-runnerregister

6.7.3.2 查看register

# 登陆
http://my_url/admin/runners

#查看gitlab-runner配置文件
[root@gitlab ~]# cat/etc/gitlab-runner/config.toml
concurrent = 1
check_interval = 0
[[runners]]
  name ="test_ci"
  url ="http://192.168.201.148/ci"
  token ="c6f62fe5a2b4ec072f5cc2fb096c02"
 executor = "shell"
 [runners.cache]

6.7.3.3 配置pipline

1，打开runner

2，编辑runner

6.7.3.4 clone仓库

[root@gitlab test]# git clone http://[email protected]/root/test.git
[root@gitlab test]#cd test

6.7.3.5 创建gitlab-ci.yml文件

[root@gitlab test]# cat .gitlab-ci.yml
stages:
  - test
job1:
  stage:test
  script:
    -echo "I am job1"
- echo "I am intest stage"

6.7.3.6上传到gitlab仓库中

[root@gitlab test]# git add .gitlab-ci.yml
[root@gitlab test]# git commit -m"kskksksk"
[master 9376c70] kskksksk
 1 filechanged, 1 insertion(+), 1 deletion(-)
 
[root@gitlab test]# git push origin master
Password for 'http://[email protected]':
Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 363 bytes | 0bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To http://[email protected]/root/test.git
  df0b7b4..9376c70  master ->master

6.7.3.7 查看效果

点击passwd

小结

1）Gitlab上进行代码托管 在gitlab上创建的项目设置成Private，普通用户对这个项目就只有pull权限，不能直接进行push，Git自带code review功能。 强制Review ：在 Gitlab 上创建的项目，指定相关用户只有Reporter权限，这样用户没有权限使用git push功能，只能git review到Gerrit 系统上，Jenkins在监听Gerrit上的项目事件会触发构建任务来测试代码， Jenkins 把测试结果通过 ssh gerrit 给这个项目打上 Verified （信息校验）成功或失败标记，成功通知其它人员 Review（代码审核） 。 Gitlab保护Master 分支：在 Gitlab 上创建的项目可以把 Master 分支保护起来，普通用户可以自己创建分支并提交代码到自己的分支上，没有权限直接提交到Master分支，用户最后提交申请把自己的分支 Merge 到 Master ，管理员收到 Merge 请求后， Review 后选择是否合并。 可以将gitlab和gerrit部署在两台机器上，这样gitlab既可以托管gerrit代码，也可以作为gerrit的备份。 因为gitlab和gerrit做了同步，gerrit上的代码会同步到gitlab上。 这样即使gerrit部署机出现故障，它里面的代码也不会丢失，可以去gitlab上拿。

2）Gerrit审核代码 Gerrit是一款被Android开源项目广泛采用的code review(代码审核)系统。普通用户将gitlab里的项目clone到本地，修改代码后，虽不能直接push到代码中心 ，但是可以通过git review提交到gerrit上进行审核。gerrit相关审核员看到review信息后，判断是否通过，通过即commit提交。然后，gerrit代码会和gitlab完成同步。 grrit的精髓在于不允许直接将本地修改同步到远程仓库。客户机必须先push到远程仓库的refs/for/*分支上，等待审核。 gerrit上也可以对比代码审核提交前后的内容状态。

3）jenkins代码发布 当用户git review后，代码通过jenkins自动测试（verified）、人工review 后，代码只是merge到了Gerrit的项目中，并没有merge到 Gitlab的项目中，所以需要当 Gerrit 项目仓库有变化时自动同步到Gitlab的项目仓库中。Gerrit 自带一个 Replication 功能，同时我们在安装 Gerrit 时候默认安装了这个 Plugin，通过添加replication.config 给 Gerrit即可（下文有介绍）

4）GitLab 是当前应用非常广泛的 Git Hosting 工具，Jenkins 是非常牛逼的持续集成工具。尽管 GitLab 有内建的 GitLab CI，但它远没有 Jenkins 那么强大好用。Jenkins 和 GitLab 在两者的结合上，都提供了非常方便的工具。在我们向 GitLab push 代码，或执行其它一些操作时，GitLab 可以将这些时间通知给 Jenkins，trigger Jenkins 工程的构建自动执行。

要实现在向 GitLab push 代码时，自动 trigger Jenkins 工程执行构建动作，需要在 GitLab 和 Jenkins 的多个地方做配置：(1)、在 Jenkins 中安装插件；(2)、配置 GitLab 用户；(3)、配置 Jenkins 服务器；(4)、配置 Jenkins 工程；(5)、配置 GitLab 工程。

问题说明：

Jenkins里直接执行shell脚本，会出现中文乱码的问题。但是单独执行shell脚本又是没问题。这个怎么办呢？

解决办法：

在shell脚本开始的时候加上命令:

export LANG="en_US.UTF-8"

问题原因：

此问题是因此执行定时任务时没有去获取系统的环境变量，导致了中文乱码。

. Git自带code review功能

• 强制 Review**：在** Gitlab 上创建的项目，指定相关用户只有 Reporter 权限，这样用户没有权限使用 git push 功能，只能 git review 到 Gerrit **系统上，**Jenkins 在监听 Gerrit 上的项目事件会触发构建任务来测试代码，Jenkins 把测试结果通过 ssh gerrit 个这个项目打上 Verified 成功或失败标记，成功通知其它人员 Review。
  est]# git push origin master
  Password for ‘http://[email protected]’:
  Counting objects: 5, done.
  Compressing objects: 100% (3/3), done.
  Writing objects: 100% (3/3), 363 bytes | 0bytes/s, done.
  Total 3 (delta 1), reused 0 (delta 0)
  To http://[email protected]/root/test.git
  df0b7b4…9376c70 master ->master

#### 6.7.3.7 查看效果

点击passwd



## 小结

1）Gitlab上进行代码托管 在gitlab上创建的项目设置成Private，普通用户对这个项目就只有pull权限，不能直接进行push，Git自带code review功能。 强制Review ：在 Gitlab 上创建的项目，指定相关用户只有Reporter权限，这样用户没有权限使用git push功能，只能git review到Gerrit 系统上，Jenkins在监听Gerrit上的项目事件会触发构建任务来测试代码， Jenkins 把测试结果通过 ssh gerrit 给这个项目打上 Verified （信息校验）成功或失败标记，成功通知其它人员 Review（代码审核） 。 Gitlab保护Master 分支：在 Gitlab 上创建的项目可以把 Master  分支保护起来，普通用户可以自己创建分支并提交代码到自己的分支上，没有权限直接提交到Master分支，用户最后提交申请把自己的分支 Merge 到 Master ，管理员收到 Merge 请求后， Review 后选择是否合并。 可以将gitlab和gerrit部署在两台机器上，这样gitlab既可以托管gerrit代码，也可以作为gerrit的备份。 因为gitlab和gerrit做了同步，gerrit上的代码会同步到gitlab上。 这样即使gerrit部署机出现故障，它里面的代码也不会丢失，可以去gitlab上拿。

 2）Gerrit审核代码 Gerrit是一款被Android开源项目广泛采用的code review(代码审核)系统。普通用户将gitlab里的项目clone到本地，修改代码后，虽不能直接push到代码中心 ，但是可以通过git  review提交到gerrit上进行审核。gerrit相关审核员看到review信息后，判断是否通过，通过即commit提交。然后，gerrit代码会和gitlab完成同步。 grrit的精髓在于不允许直接将本地修改同步到远程仓库。客户机必须先push到远程仓库的refs/for/*分支上，等待审核。 gerrit上也可以对比代码审核提交前后的内容状态。

 3）jenkins代码发布 当用户git review后，代码通过jenkins自动测试（verified）、人工review  后，代码只是merge到了Gerrit的项目中，并没有merge到 Gitlab的项目中，所以需要当 Gerrit  项目仓库有变化时自动同步到Gitlab的项目仓库中。Gerrit 自带一个 Replication 功能，同时我们在安装 Gerrit  时候默认安装了这个 Plugin，通过添加replication.config 给 Gerrit即可（下文有介绍） 



4）GitLab 是当前应用非常广泛的 Git Hosting 工具，[Jenkins](https://jenkins.io/) 是非常牛逼的持续集成工具。尽管 GitLab 有内建的 [GitLab CI](https://docs.gitlab.com/ee/ci/README.html)，但它远没有   Jenkins 那么强大好用。Jenkins 和 GitLab 在两者的结合上，都提供了非常方便的工具。在我们向 GitLab push  代码，或执行其它一些操作时，GitLab 可以将这些时间通知给 Jenkins，trigger Jenkins 工程的构建自动执行。

要实现在向 GitLab push 代码时，自动 trigger Jenkins 工程执行构建动作，需要在 GitLab 和  Jenkins 的多个地方做配置：(1)、在 Jenkins 中安装插件；(2)、配置 GitLab 用户；(3)、配置 Jenkins  服务器；(4)、配置 Jenkins 工程；(5)、配置 GitLab 工程。





## 问题说明：

Jenkins里直接执行shell脚本，会出现中文乱码的问题。但是单独执行shell脚本又是没问题。这个怎么办呢？

## 解决办法：

在shell脚本开始的时候加上命令:

export LANG=“en_US.UTF-8”

 

## 问题原因： 

此问题是因此执行定时任务时没有去获取系统的环境变量，导致了中文乱码。



### . Git自带code review功能

- **强制** **Review****：在** **Gitlab** **上创建的项目，指定相关用户只有** **Reporter** **权限，这样用户没有权限使用** **git push** **功能，只能** **git review** **到** **Gerrit** **系统上，****Jenkins** **在监听** **Gerrit** **上的项目事件会触发构建任务来测试代码，****Jenkins** **把测试结果通过** **ssh gerrit** **个这个项目打上** **Verified** **成功或失败标记，成功通知其它人员** **Review****。**
- **Ø**  **Gitlab** **保护** **Master** **分支：在** **Gitlab** **上创建的项目可以把** **Master** **分支保护起来，普通用户可以自己创建分支并提交代码到自己的分支上，没有权限直接提交到** **Master** **分支，用户最后提交申请把自己的分支** **Merge** **到** **Master****，管理员收到** **Merge** **请求后，****Review** **后选择是否合并。**