7，Jenkins实战应用--Jenkins与GitHub的交互探微

*系列汇总*

这是一个系列文章，大大小小到今天惊然发现竟然已经累计二十篇了，也就不得不做一个小汇总。回想当初写第一篇文章的时候，就已经决心事无巨细，一应认真的走下来，回头遮望，看着皇皇这么多文章，一股强烈的成就感就此油然而生，于是便有了这些汇总整理。在这个过程当中，好像也帮助过不少的人，这是让我尤其开心的事情，同时也结识了一些志同道合的朋友，再没有比这更让人觉得愉悦的事情啦！也希望以后写出更多类似的系列文章。

文章汇总地址如右：Jenkins入门教程。

如果相中哪个，点击进去便是。希望正在读这段话的你能够在这个小系列中获得自信以及喜悦！

Jenkins拉取从Git仓库拉取代码进行部署操作。现有两种方法，今天分别记录两种方法，并对其中一些问题进行讲解。

1， 直接通过其附带的Git插件来拉取代码。

配置如下图：

通过在源码管理当中直接设置Git仓库的代码链接，然后下边添加相对应的已注册用户账号密码，如此就可以拉取到本地workspace里了。然后就能够针对代码进行操作了。

那么这种方式构建的项目，分支切换更加灵活，一般情况下构建记录当中所显现的代码变动记录也会非常大，在真正构建之前都是代码变动的记录。

看到方框里边就是汇总显示变动传输的情况。

2， 不通过Git插件对代码进行操作。

这种方式更适合于单一分支发布的情况，一般线上正是环境都是只发master分支，比较适合使用这种方式。

操作流程大概是这样，首先在Jenkins所在服务器上对要工作的项目进行手动clone，然后就可以在Jenkins这里直接对代码进行操作部署。

直接在构建的地方对代码进行操作

这里隐去的是通过脚本对代码进行操作的一些事情。

那么通过这种方式来进行部署，其代码变化，则看起来会更加直观便捷：

解释：

• 首先是分支已经在master。

• 然后显示从Git库链接拉取更新。

• 下边就是一些详细更新内容的展示。

  两种方式都是可以进行正常构建部署的。第一种更适合于测试环境中使用，分支变动更加灵活，第二种更适合于正式环境，只针对单一分支进行部署更新。

  而两种方式还有一个小区别，第一种构建方式，所有的代码变动更新都可以通过项目的变更记录里边看到，但是第二种方式去到变更记录里边，则全部是没有变动。有这个区别，就不会在开发来找你问我代码有没有发上去，而你在确认是否有发上去时–被动。