Github公有仓库

应用场景
本地工作区将代码通过git add上传到本地暂存区，然后提交到本地Git仓库，在推送到Git分布式版本管理仓库。
开发人员：
修改完代码上传到Git远程本地仓库，git的大型仓库（gitlab）也叫私有仓库，带有web界面的仓库叫gitlab，git本身有个简易仓库，Jenkins原来是从SVN拉取代码，现在是从gitlab拉取代码，拉取代码的过程，叫做持续集成，持续构建（CI）持续部署，持续交换（CD），那么maven是CI，Jenkins也是CI，项目发布是CD的顺至如果加一个第三方代码质量管理，就有一个软件集群在Jenkins上，就可以自动检测代码的完整性。
测试人员
然后交给测试人员进行集成开发测试，然后单元测试，有一个压力测试软件（jemeter），无论是黑盒还是白盒，或者一些测试软件，测试成功以后就发布，只有发布的时候叫CD，单元测试在部署的时候也有可能是CD的过程，别的都叫持续集成测试，持续集成构建。

其实这个过程就是gitlab代替了SVN

java的打包过程
java是一种容器运行的，它本身直接把一个java开发的源代码是直接运行不了的，它需要很多支持包，依赖包一起打包，叫.war或.jar

war：java是后端语言，前端语言加上后端语言，加上web页面在一起打个包叫war
jar：没有网页端的代码就叫jar（可以这么理解，只有学了开发的时候你才会理解）

maven：可以看成yum仓库，没有maven的话，你的依赖包只能一个一个下载，有了maven它会自动下载依赖包，maven自动打成一个包，交给Jenkins，maven专门打包的，这个只是java需要的，php是不需要的，maven里面有一个配置文件，通过配置文件（pom.xml）打包，这个配置文件不是运维写的，开发人员在上传代码的时候，同时写好一个pom.xml，一起上传到gitlab仓库，maven会读取开发上传pom.xml,是maven需要打包的配置文件，然后maven可以打包了

Git介绍

Git在Wikipedia上的定义:它是一个免费的、分布式的版本控制工具，与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持（wingeddevil注：这得分是用什么样的服务端，使用http协议或者git协议等不太一样。并且在push和pull的时候和服务器端还是有交互的。），使源代码的发布和交流极其方便。 Git 的速度很快，这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪（merge tracing）能力。

分布式版本控制介绍

本地版本控制

本地的文件上传到本地仓库里，本地帮我记录版本

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少：有时候会混淆所在的工作目录，一旦弄错文件丢了数据就没法撤销恢复。

集中化的版本控制

多个客户端可以集中朝着一个版本仓库提交，以及下载代码，一但集中化版本仓库宕了，每个开发就没法弄了。

接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ）应运而生。这类系统，诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法

分布式版本控制

它是集成了远程仓库和本地仓库的结合体，本地的文件A和B把文件里面的代码记录在本地仓库，然后本地仓库记录推到远程仓库。（先推本地，在到远程），就算没有远程仓库，俩个开发的本地仓库也可以互相推送（相当于A文件的远程仓库就是B文件的远程仓库）。

于是分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）面世了。在这类系统中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份

左边Git
主干代码（master），一但是主版本更新了，所有用户都更新了，为了不影响主版本，在开发功能开启分支，也就是说master复制一份，然后在分支代码，一但功能没问题然后在合并主代码，如果覆盖的时候文件有冲突的时候，会有提示的，然后人工介入。

右边SVN

中间是主干，复制主干一份，完全复制，然后在开发下去，到合并的时候，分支里面的代码合并到主版本里，也就说是覆盖的，多分支覆盖会出问题的，新分支的在覆盖到原来的会冲突的。

开发测试环境

您Jenkins拉取的什么代码
拉取的是测试分支代码
一般有三分
测试分支（test），分支dev，master分支

线上环境

也有一个Jenkins
拉取的是master分支代码

公有仓库

可以注册GitHub账号

Git的安装
Windows客户端的地址： https://git-scm.com/downloads

部署git客户端

#安装环境查看
[root@localhost ~]# cat /etc/redhat-release 
CentOS Linux release 7.5.1804 (Core) 
[root@localhost ~]# uname -r
3.10.0-862.el7.x86_64
#安装git客户端
[root@localhost ~]# which git
/usr/bin/git
[root@localhost ~]# git --version
git version 1.8.3.1
#Git全局配置
[root@localhost ~]# git config --global user.name "zxw"		#配置git使用用户
[root@localhost ~]# git config --global user.email "2420813702@qq.com"   #配置git使用邮箱
[root@localhost ~]# git config --global color.ui true  #语法有颜色 高亮
[root@localhost ~]# git config --global --list  #语法高亮
user.name=zxw
user.email=2420813702@qq.com			
color.ui=true
注意
如果没有提前设置Git的全局配置，那么在第一次进行代码提交的时候，会要求输入使用者的邮箱和姓名

#源码安装git-2.9.5.tar.gz
[root@localhost ~]# yum -y install curl-devel expat-devel gettext-devel openssl-devel zlib-devel
[root@localhost ~]# yum -y install gcc perl-ExtUtils-MakeMaker
[root@localhost git-2.9.5]# tar xf git-2.9.5.tar.gz -C /usr/src/
[root@localhost git-2.9.5]# cd /usr/src/git-2.9.5/
[root@localhost git-2.9.5]# ./configure --prefix=/usr/local/git
[root@localhost git-2.9.5]# make && make install
[root@localhost bin]# ln -sf  /usr/local/git/bin/* /usr/bin/
[root@localhost ~]# which git
/usr/bin/git
#源码编译需要链接git的命令库
[root@localhost ~]# ln -s /usr/libexec/git-core/* /usr/bin/
[root@localhost ~]# git --version
git version 2.9.5
至此，利用源码包安装linux操作系统的git客户端就安装好了。

Git的命令入门

• 工作区
  你建立的本地git项目目录（代码放在了工作区）
• 暂存区 （add）
  将工作区里的变更部分（与上一版本不同的部分）暂时存储起来的地方 （git add）
• 本地仓库
  在本地创建的git版本仓库，用于提交工作区的变更。 （git commit）
• 远程仓库
  githab，gitlab或者队友机器上所建立的一个仓库 （git push）

git帮助文档

当前配置文件中文生效
[root@localhost ~]# export LANG=zh_CN.UTF8     
[root@localhost ~]# git
usage: git [--version] [--help] [-C <path>] [-c name=value]
           [--exec-path[=<path>