上次已经写过 Jenkins 与 Git 之间的一下关联，但是那篇文章阐之未尽，今天再来行文表一表 Jenkins 与 Git 分支之间的问题。

也是这中间有不少人一起探讨到关于项目分支的问题，彼时我对此没有深究，因此也是云里雾里，有人问起来，自己也是不敢确定性的告诉给人家这是什么。

这是最尴尬的事情，有些东西你以为你懂着，其实经不起别人问上一问，而显然，经不起问的，必然也就证明掌握的不够牢靠。因此，深入研究一番是自不待言的。

这也是下午做的事情。

• 1，在自己本地搭建了一个 gitlab 服务器，不仅仅为了这次测试，也为了以后各种倒腾之需。

• 2，顺道模拟开发学习了一波 Git 的使用。

• 3，验证以及总结 Jenkins 与 Git 分支之间的一些交互问题。

现在，直奔主题，不说其他。

首先说 Jenkins 与 Git 分支之间的交互，有两种（当然，可能有更多，只不过我暂时掌握这两种），一种是 Jenkins 用 Jenkins 自身的构建参数来实现，另一种是通过插件来实现。

之前发布的第四篇文章（Jenkins 实战应用–Jenkins 一个项目的构建 (opens new window)），因为主题是构建一个项目，分支这里也就一笔带过了，带过的连我自己也没有深入进行思考，导致不少人在配置成功之后仍旧对 Jenkins 是如何发布其他分支的问题抱有疑惑，今天，就来解开这个疑惑。

现在来介绍这两种交互方式。

1，通过构建参数中的字符参数来实现。

我们来看看上次 Jenkins 这里是如何配置的。

今天是为了详解分支的问题，因此不计较项目的构建问题，我就在自己搭建的测试 Gitlab 上随便创建两个分支并写一些简单的内容，以供测试验证今天的问题。

首先来看一下这种字符参数在构建的时候是什么样的：

发布的时候，如果是默认的 master 分支，那么我们直接点击开始构建，就会构建 master 分支的代码了。

如果此时非 master 分支，那么删除掉 Branch 中的 master，将要部署的分支填入点击构建就可以了。

那么这种选择分支的构建方式是怎么实现的呢？

先在参数化构建中添加字符参数：

然后注意在 Git 连接处填入调用分支的变量名。

很多人说填入 git 连接之后总是报错啊

解决办法参考Jenkins 连接 gitlab 报错怎么办？ (opens new window)

那么我们来看 Git 连接处的配置：

注意图中框起来的地方，就是上边添加字符参数时所填写的名称变量 Branch。注意前边的$符号不要少了。

此时我们来做一些简单构建来看看。

构建之前我们先来看下我准备的分支以及分支下的内容：

1，这是 master 分支。

2，这是 dev 分支。

3，这是 liqilong 分支。

那么我们先来构建一下 master 分支。

为了更清晰看到分支的变化，我们在项目的构建处添加两条命令：

现在去到项目中进行构建：

然后去看控制台的输出内容：

Started by user 李启龙
Building in workspace /root/.jenkins/workspace/test-branch
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url http://192.168.96.23/root/testa.git # timeout=10
Fetching upstream changes from http://192.168.96.23/root/testa.git
> git --version # timeout=10
using GIT_ASKPASS to set credentials
> git fetch --tags --progress http://192.168.96.23/root/testa.git +refs/heads/*:refs/remotes/origin/*
> git rev-parse origin/master^{commit} # timeout=10
Checking out Revision 2ba088747e4b0e830fef235e01c0881a62fc58b2 (origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 2ba088747e4b0e830fef235e01c0881a62fc58b2
Commit message: "更新 readme"
> git rev-list --no-walk 2ba088747e4b0e830fef235e01c0881a62fc58b2 # timeout=10
[test-branch] $ /bin/sh -xe /usr/local/tomcat/temp/jenkins4544984219385266947.sh
+ echo /root/.jenkins/workspace/test-branch
/root/.jenkins/workspace/test-branch
+ cat readme
this is master branch

构建master分支就可以看到这句话，而且构建出来的包就是master分支。
Finished: SUCCESS

此处把构建历史单摘出来，当然意味深远，上图中我们看到构建选择 master 分支，那么构建的内容就是 master 分支下的内容。

单摘出来，就详聊一下这个日志输出的意义吧：

提示

• 1，表示项目构建人事李启龙。
• 2，表示在此目录下进行的构建。
• 从第三行到第十五行都是对 git 的连接与操作，这里捡一些重要的来讲一下（其实是捡我知道的来讲下，不知道的也没法讲呀）。
• 4，从远程 Git 仓库读取更改。
• 10，表示本地构建的分支是 master 分支。
• 11，显示出本地构建的 commit id.
• 13，根据 commit id 切换到对应的分支。
• 14，本地构建的 commit message。
• 16，Jenkins 临时生成一个构建脚本进行构建。
• 17，是打印我刚才的第一条命令。
• 18，是第一条命令的结果输出。
• 19，打印第二条命令。
• 20~22，第二条命令结果输出。
• 23，构建结果，成功。

那么我们马上来看下构建其他分支的操作与结果。

看看结果：

此处可以看到构建了对应的分支，而且在 dev 分支下工作了。

不过且慢，现在猛然想起来，我们一开始提的问题好像是两次构建之间，第二次构建把第一次构建的代码怎么着了呢。

好，我想到现在去 Jenkins 服务器的$WORKSPACE 里边看个究竟。

直接 cd 到刚才的构建历史输出的目录。

接下来进入一小段点评节目：

[root@xdjenkins test-branch]$cd /root/.jenkins/workspace/test-branch
[root@xdjenkins test-branch]$ls
readme

笔记

评上：ok，果然只有 readme 一个人。

[root@xdjenkins test-branch]$cat readme
this is dev branch

如果选择构建的是dev分支，将会看到这里的内容。

笔记

评上：内容也是 dev 的东东，而关于刚刚构建的 master 的，已经消失不见。

[root@xdjenkins test-branch]$git branch
* (detached from cf27c4b)

笔记

评上：什么鬼！

[root@xdjenkins test-branch]$git branch -a
* (detached from cf27c4b)
  remotes/origin/dev
  remotes/origin/liqilong
  remotes/origin/master

笔记

评上：略知一二了。

[root@xdjenkins test-branch]$git log
commit cf27c4b0f1f8ef8c5849cec63bf93bd1d0328e98
Author: Administrator <admin@example.com>
Date:   Tue May 22 19:06:16 2018 +0800

    更新 readme

commit 7179bb71ae6601154648e2d979b1474e2467dd38
Author: eryajf <Linuxlql@163.com>
Date:   Tue May 22 16:47:35 2018 +0800

    添加文件

commit 4c15546cc08c146d63c4f3ada647b4f0068928fb
Author: eryajf <Linuxlql@163.com>
Date:   Tue May 22 16:45:31 2018 +0800

    测试提交

笔记

评上：搜嘎，commit id 对着嘞。

[root@xdjenkins test-branch]$git show cf27c4b0f1f8e
commit cf27c4b0f1f8ef8c5849cec63bf93bd1d0328e98
Author: Administrator <admin@example.com>
Date:   Tue May 22 19:06:16 2018 +0800

    更新 readme

diff --git a/readme b/readme
index 64fdb4f..5e4f328 100644
--- a/readme
+++ b/readme
@@ -1,3 +1,3 @@
 this is dev branch

-这次修改是为了验证新分支开发后提交。
+如果选择构建的是dev分支，将会看到这里的内容。

笔记

评上：行啦，知道你是什么情况啦。

那么现在可以纠正一下刚才的一个错误，刚才说第二次构建就是在 dev 分支下工作了，而经过上边这波操作之后发现，事实并非如此，Jenkins 是将 dev 分支上最新的那次commit id作为临时工作“分支”，从而保证代码的新鲜度。

哎呀，一下没收住，打破砂锅问到底的精神又冒出来了，可能有人觉得跑这么深没什么必要，但是因为有了这次没必要的深入，至少以后在遇到构建失败或者异常等问题时，知道在$WORKSPACE这里究竟曾发生过什么事儿。

提示

现在可以回答开头的问题了。Jenkins 第一次构建是将对应分支的代码全部拉过来进行构建，第二次构建如果还是第一次的分支，那么只会同步分支变动的代码进行构建，如果两次构建分支不同，那么工作的顺序与一开始我的猜想是一致的，确认到新的分支，删除掉旧分支上的东西，然后把新分支上的拉取过来。并且，我估计，这个过程中，一样的代码，不会删掉。

好了，问题找到答案了，现在去将第二种分支构建的方式完善了吧。

2，通过 Git Parameter 插件实现选择分支进行构建。

同样，先来看下这种方式的构建方式是怎样的：

可以看到方框中直接把我项目的分支罗列了出来。构建的时候直接选择分支，然后进行构建就 ok 了。

那么这种方式是如何实现的呢？

首先去安装插件：Git Parameter ，就不过多废话了。

接着看图学技能：

通过插件中的配置，来实现构建时分支的选择。

简单测试一下，看看其效果：

在构建中选择哪个没有构建过的分支：

然后看一些构建日志：

与第一种构建方式如出一辙。

尾巴！

笔记

或许我们掌握一种方式能够成功就足够了 甚至我们都不需要知道它是怎么成功的 或者我们掌握多种方法把一件事儿完成 在掌握一种方式之外的那种方式的过程中 就已经对这个环节，了如指掌以至于用起来得心应手！