标签：rest gradle minimal add 指针 paper 特征 命令行 异步执行
随时随地将代码合并，这种方法叫做持续集成。
开发写代码的演变：
Continuous integration （CI）
持续集成是一种软件开发实践，
即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。
每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。
许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。
根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续集成的好处主要有两个:
1、快速发现错误
每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易
2、防止分支大幅偏离主干
如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。
它的核心措施是，代码集成到主干之前，必须通过自动化测试。
只要有一个测试用例失败，就不能集成。
Continuous delivery（CD）
持续交付在持续集成的基础上，
将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。
比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。
如果代码没有问题，可以继续手动部署到生产环境中。
频繁的讲软件的新版本，交付给质量团队或者用户，以供评审。
如果评审通过，代码就进入生产阶段。
持续交付可以看做是，持续继承的下一步
它强调的是，不管软件怎么更新，软件是可以随时随地可以交付的。
Continuous deployment（CD）
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
持续部署的目标是，代码在任何时候都是可以部署的，可以进入生产阶段。
持续部署的前提是，能自动完成测试、构建、部署等步骤
根据持续集成的设计，代码从提交到生产，整个过程有以下几步。
流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次（commit）
代码仓库对commit操作配置好了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试
通过第一轮测试，代码就可以合并进主干，就算可以交付了。
交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。
常用的构建工具如下。jeknins、Travis、codeship等。
构建完成，就要进行第二轮的测试。
如果第一轮已经涵盖了所有测试内容，可以省略第二轮，当然，这时的构建步骤也要移到第一轮测试前面。
第二轮是全面测试，单元测试和集成测试都会跑，有条件的额haul，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。
通过了第二轮测试，当前代码就是一个可以直接部署的版本（artifact）。将这个版本的所有文件打包（tar filename.tar *）存档，发到生产服务器。
生产服务器将打包文件，解包成本地文件，再将运行路径的符号链接（symlink）指向这个目录，然后重新启动应用，这方面的部署工作有Ansible，Chef，Puppet等。
一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。
开发的考核标准是：实现了多少功能，写了多少代码。
运维的考核标准是：系统有多稳定。
所以，在现实中.....他们之间有巨大的鸿沟
DevOps 一词的来自于 Development 和 Operations 的组合，突出重视软件开发人员和运维人员的沟通合作，
通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
目前对 DevOps 有太多的说法和定义，不过它们都有一个共同的思想：
“解决开发者与运维者之间曾经不可逾越的鸿沟，增强开发者与运维者之间的沟通和交流”。
而我个人认为， DevOps 可以用一个公式表达：
文化观念的改变 + 自动化工具 = 不断适应快速变化的市场
强调：
DevOps 是一个框架，
是一种方法论，
并不是一套工具，他包括一系列的基本原则和实践。
其核心价值在于以下两点：
更快速地交付, 响应市场的变化。
更多地关注业务的改进与提升。
1、产品迭代
在现实工作中，往往都是用户不知道自己想要什么，
但是当我们设计完一个产品后，他告诉我们他们不需要什么，
这样我们的产品需要反复的迭代，而且过程可能是曲折的，
那我们有什么好的办法快速的交付价值，灵活的响应变化呢？
答案就是 DevOps。因为 DevOps 是面向业务目标，助力业务成功的最佳实践。
2、技术革新
现在的IT 技术架构随着系统的复杂化不断的革新，从最期的所有服务在一个系统中，
发展到现在的微服务架构、从纯手动操作到全自动流程、从单台物理机到云平台，
技术永远在更新，永远在学习
落实DevOps的指导思想
高效的协作和沟通、
自动化流程和工具、
迅速敏捷的开发、
持续交付和部署
不断学习和创新。
我们来看一张来自devops经典著作《success with enterprise dev-ops-whitepaper》的介绍图
敏捷管理：一支训练有素的敏捷开发团队是成功实施 DevOps 的关键。
持续交付部署：实现应用程序的自动化构建、部署、测试和发布。通过技术工具，把传统的手工操作转变为自动化流程，这不仅有利于提高产品开发、运维部署的效率，还将减少人为因素引起的失误和事故，提早发现问题并及时地解决问题，这样也保证了产品的质量。下图展示了 DevOps 自动化的流程：
IT 服务管理：可持续的、高可用的 IT 服务是保障业务正常的关键要素，它与业务是一个整体。IT 服务管理（ITSM），它是传统的“IT 管理”转向为“IT 服务”为主的一种模式，前者可能更关注具体服务器管理、网络管理和系统软件安装部署等工作；而后者更关注流程的规范化、标准化，明确定义各个流程的目标和范围、成本和效益、运营步骤、关键成功因素和绩效指标、有关人员的责权利，以及各个流程之间的关系等，比如建立线上事故解决流程、服务配置管理流程等。
精益管理：建立一个流水线式的 IT 服务链，打通开发与运维的鸿沟，实现开发运维一体化的敏捷模式。精益生产主要来源于丰田生产方式 (TPS)的生产哲学，它以降低浪费、提升整体客户价值而闻名，它主要利用优化自动化流程来提高生产率、降低浪费。所以精益生产的精髓是即时制（JIT）和自动化（Jidoka）。精益管理贯穿于整个 DevOps 阶段，它鼓励主动发现问题，不断的优化流程，从而达到持续交付、快速反馈、降低风险和保障质量的目的。
按照业务功能划分团队，建立沟通群组，设置产品负责人（一个策划人员）、Scrum Master
（我们一般选择测试人员担任，测试驱动开发模式）和开发者团队（前端工程师、后端工程
师、测试各一名），形成如下的组织结构和系统架构：
提交：工程师将代码在本地测试后，提交到版本控制系统，如 Git 代码仓库中。
构建：持续整合系统（如 Jenkins CI），在检测到版本控制系统更新时，便自动从 Git代码仓库里拉取最新的代码，进行编译、构建。
单元测试：Jenkins 完成编译构建后，会自动执行指定的单元测试代码。
部署到测试环境：在完成单元测试后，Jenkins 可以将应用程序部署到与生产环境相近的测试环境中进行测试。
预生产环境测试：在预生产测试环境里，可以进行一些最后的自动化测试，例如使用Appium 自动化测试工具进行测试，以及与实际情况类似的一些测试可由开发人员或客户人员手动进行测试。
部署到生产环境：通过所有测试后，便可以使用灰度更新将最新的版本部署到实际生产环境里。
人手紧缺
跨部门协作，前期沟通培训成本高
前期投入工作量大见效少
Trello
Teambition
Worktile
Tower
confluence
禅道
Jira
Bugzila
其中 confluence 和禅道主要是产品的需求、定义、依赖和推广等的全面管理工具；而
Jira 和 Bugzilla 是产品的质量管理和监控能力，包括测试用例、缺陷跟踪和质量监控等。
目前我们使用 Jira 和禅道较多。
Git
Gitlab
Github
Git 是一个开源的分布式版本控制系统；Gitlab 和 Github 是用于仓库管理系统的开源
项目，它们使用 Git 作为代码管理工具，并在此基础上搭建起来的 web 服务。我们主要使用
的是 Git 和 Gitlab
Gradle
Maven
SBT
ANT
VMware
VirtualBox
Vagrant
Docker
Jenkins
Hudson
Travis CI
CircleCI
Jenkins 是一个开源软件项目，是基于 Java 开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能，它的前身为Hudson。
Travis CI 是目前新兴的开源持续集成构建项目，它与 jenkins 很明显的区别在于采用yaml 格式，简洁清新独树一帜。
CircleCI 是一个为 web 应用开发者提供服务的持续集成平台，主要为开发团队提供测试，持续集成，以及代码部署等服务
Appium
Appium 是一个移动端的自动化框架，可用于测试原生应用，移动网页应用和混合型应用，且是跨平台的。可用于 IOS 和 Android 以及 firefox 的操作系统。
Selenium
Selenium 测试直接在浏览器中运行，就像真实用户所做的一样。Selenium 测试可以在Windows、Linux 和 Macintosh 上的 Internet Explorer、Mozilla 和 Firefox 中运行。
Mock 测试
Mock 测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。这个虚拟的对象就是 Mock 对象，Mock 对象就是真实对象在调试期间的代替品。
Java 中的 Mock 框架常用的有 EasyMock 和 Mockito 等。
消费者驱动契约测试
契约测试是一种针对外部服务的接口进行的测试，它能够验证服务是否满足消费方期待的契约。当一些消费方通过接口使用某个组件的提供的行为时，它们之间就产生了契约。
这个契约包含了对输入和输出的数据结构的期望，性能以及并发性。而 PACT 是目前比较流的消费者驱动契约测试框架。
Ansible
Puppet
Chef
SaltStack
Zabbix
Zabbix 是一个基于 WEB 界面的提供分布式系统监视以及网络监视功能的企业级开源解决方案。
ELK Stack 日志分析系统
ELK Stack 是开源日志处理平台解决方案，背后的商业公司是 Elastic。它由日志采集解析工具 Logstash、基于 Lucene 的全文搜索引擎 Elasticsearch、分析可视化平台Kibana 三部分组成。
云监控（如 Amazon CloudWatch）
Amazon CloudWatch 是一项针对 AWS 云资源和在 AWS 上运行的应用程序进行监控的服务。您可以使用 Amazon CloudWatch 收集和跟踪各项指标、收集和监控日志文件、设置警报以及自动应对 AWS 资源的更改。
学习开源软件，建议直接学习官方文档，因为跟新的太快了。你能在网上找到的，不一定正确。
#1 什么是版本控制 版本控制（Revision control）是一种在开发的过程中用于管理我们对文件、目录或工 程等内容的修改历史，方便查看更改历史记录，备份以便恢复以前的版本的软件工程技术。 #1.1 版本控制的目的 实现跨区域多人协同开发 追踪和记载一个或者多个文件的历史记录 组织和保护你的源代码和文档 统计工作量 并行开发、提高开发效率 跟踪记录整个软件的开发过程 减轻开发人员的负担，节省时间，同时降低人为错误 简单说就是用于管理多人协同开发项目的技术。 没有进行版本控制或者版本控制本身缺乏正确的流程管理，在软件开发过程中将会引入 很多问题，如软件代码的一致性、软件内容的冗余、软件过程的事物性、软件开发过程中的 并发性、软件源代码的安全性，以及软件的整合等问题。 #1.2 版本控制可以做什么？ 自动生成备份 知道改动的地方 随时回滚 #2 常见的版本控制器 主流的版本控制器有如下这些： Git SVN（Subversion） - 集中式的额版本控制系统 CVS（Concurrent Versions System） VSS（Micorosoft Visual SourceSafe） TFS（Team Foundation Server） Visual Studio Online 版本控制产品非常的多（Perforce、Rational ClearCase、RCS（GNU Revision Control System）、Serena Dimention、SVK、BitKeeper、Monotone、Bazaar、Mercurial、SourceGear Vault），现在影响力大且使用广泛的是 Git 与 SVN #3 版本控制分类 #3.1 本地版本控制 记录文件每次的更新，可以对每个版本做一个快照，或是记录补丁文件，适合个人用， 如 RCS。 #3.2 集中版本控制 所有的版本数据都保存在服务器上，协同开发者从服务器上同步更新或上传自己的修改 所有的版本数据都存在服务器上，用户的本地只有自己以前所同步的版本，如果不连网 的话，用户就看不到历史版本，也无法切换版本验证问题，或在不同分支工作。而且，所有 数据都保存在单一的服务器上，有很大的风险这个服务器会损坏，这样就会丢失所有的数据， 当然可以定期备份。代表产品：SVN、CVS、VSS #3.3分布式版本控制 所有版本信息仓库全部同步到本地的每个用户，这样就可以在本地查看所有版本历史， 可以离线在本地提交，只需在连网时 push 到相应的服务器或其他用户那里。由于每个用户 那里保存的都是所有的版本数据，只要有一个用户的设备没有问题就可以恢复所有的数据， 但这增加了本地存储空间的占用。
Git的简介和历史
#1 Git 简介 Git 是一个开源的分布式版本控制系统，用于敏捷 高效地处理任何或小或大的项目。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本 控制软件。 Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式， 不必服务器端软件支持 #2 Git 的诞生 很多人都知道，Linus 在 1991 年创建了开源的 Linux，从此，Linux 系统不断发展，已 经成为最大的服务器系统软件了。 Linus 虽然创建了 Linux，但 Linux 的壮大是靠全世界热心的志愿者参与的，这么多人 在世界各地为 Linux 编写代码，那 Linux 的代码是如何管理的呢？ 事实是，在 2002 年以前，世界各地的志愿者把源代码文件通过 diff 的方式发给 Linus， 然后由 Linus 本人通过手工方式合并代码！ 你也许会想，为什么 Linus 不把 Linux 代码放到版本控制系统里呢？不是有 CVS、SVN 这些免费的版本控制系统吗？因为 Linus 坚定地反对 CVS 和 SVN，这些集中式的版本控制系 统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比 CVS、SVN 好 用，但那是付费的，和 Linux 的开源精神不符。 不过，到了 2002 年，Linux 系统已经发展了十年了，代码库之大让 Linus 很难继续通 过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是 Linus 选择了一个商 业的版本控制系统 BitKeeper，BitKeeper 的东家 BitMover 公司出于人道主义精神，授权 Linux 社区免费使用这个版本控制系统。 安定团结的大好局面在 2005 年就被打破了，原因是 Linux 社区牛人聚集，不免沾染了 一些梁山好汉的江湖习气。开发 Samba 的 Andrew 试图破解 BitKeeper 的协议（这么干的其 实也不只他一个），被 BitMover 公司发现了（监控工作做得不错！），于是 BitMover 公司怒 了，要收回 Linux 社区的免费使用权。 Linus 可以向 BitMover 公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。 实际情况是这样的： Linus 花了两周时间自己用 C 写了一个分布式版本控制系统，这就是 Git！一个月之内， Linux 系统的源码已经由 Git 管理了！牛是怎么定义的呢？大家可以体会一下。 Git 迅速成为最流行的分布式版本控制系统，尤其是 2008 年，GitHub 网站上线了，它 为开源项目免费提供 Git 存储，无数开源项目开始迁移至 GitHub，包括 jQuery，PHP，Ruby 等等。 历史就是这么偶然，如果不是当年 BitMover 公司威胁 Linux 社区，可能现在我们就没 有免费而超级好用的 Git 了。 #3 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 哈希算法。这能确保 代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。
1、实验环境要求 操作系统：CentOS-7-x86_64 配置：2VCPU+2048(最好 4096)+50G 软件包：MInimal Install 关闭 iptables 和 SELINUX 注：1、建议初学者保持实验环境和本课程一致，包括但不局限于 IP 地址，主机名，网 卡名称等，可以为你节约很多因为环境问题的排错时间。2、做好虚拟机的快照，比如可以 根据本课程的不同章节，创建不同的快照，便于保留实验环境和在实验过程中进行环境的回 滚。 10.0.0.11 ci-node1 10.0.0.12 ci-node2 10.0.0.13 ci-node3 2、安装系统 3、系统初始化 1、设置主机名解析： [root@node1 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.0.0.11 ci‐node1 10.0.0.12 ci‐node2 10.0.0.13 ci‐node2 2、安装 EPEL 仓库和常用命令 [root@node1 ~]# rpm ‐ivh http://mirrors.aliyun.com/epel/epel‐release‐latest‐7.noarch.rpm [root@node1 ~]# yum install ‐y net‐tools vim lrzsz tree screen lsof wget ntpdate 3、关闭 NetworkManager 和防火墙 [root@node1 ~]# systemctl disable firewalld [root@node1 ~]# systemctl stop NetworkManager 4、关闭 SELinux [root@node1 ~]# vim /etc/sysconfig/selinux SELINUX=disabled #修改为 disabled 5、设置时间： [root@node1 ~]# crontab ‐l */5 * * * * /usr/sbin/ntpdate time1.aliyun.com 6、更改时区 ln ‐sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
4、其他要求
1、系统安装完成后做初始化快照
2、下载百度网盘文件。
链接：https://pan.baidu.com/s/16m5BVuhBSgtw1-_XTaJdmw 密码：pct9
3、使用提供的安装手册自行测试安装 Git、Gitlab、Jenkins。
4、注册 GitHub 帐户
默认在CentOS下，我们可以通过yum的方式来安装Git [root@node1 ~]# yum install git –y [root@node1 ~]# git version git version 1.8.3.1 使用yum安装的Git的版本是1.8，版本较低，我们还可以通过源码编译的方式来安装Git的最新版本。 首先需要安装依赖的库： [root@node1 ~]# yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc perl-ExtUtils-MakeMaker -y 下载最新的源码包 [root@node1 src]# cd /usr/local/src/ [root@node1 src]# wget https://www.kernel.org/pub/software/scm/git/git-2.9.5.tar.gz [root@node1 src]# ll total 5792 -rw-r--r-- 1 root root 5928730 Aug 11 01:57 git-2.9.5.tar.gz 解压安装： [root@node1 src]# tar xf git-2.9.5.tar.gz [root@node1 src]# cd git-2.9.5 [root@node1 git-2.9.5]# make prefix=/usr/local/git all [root@node1 git-2.9.5]# make prefix=/usr/local/git install [root@node1 git-2.9.5]# rm -rf /usr/bin/git [root@node1 git-2.9.5]# ln -s /usr/local/git/bin/git /usr/bin/git [root@node1 git-2.9.5]# git --version git version 2.9.5 至此，我们已经完成了Git的编译安装，现在Git可以安装在windows、MAC操作系统上，具体请参考： https://git-scm.com/book/zh/v2/%E8%B5%B7%E6%AD%A5-%E5%AE%89%E8%A3%85-Git
Git分布式版本控制系统最佳实践 - 老男孩教育博客 http://blog.oldboyedu.com/git/ 系统环境 CentOS7.4 防火墙和selinux关闭 安装Git yum -y install git Git全局配置 git config --global user.name "zy" #配置git使用用户 git config --global user.email "zhangyao@oldboyedu.com" #配置git使用邮箱 git config --global color.ui true #语法高亮 git config --list # 查看全局配置
Git的配置文件
Git 的配置从上到下分三层 system/global/local,使用三个不同参数进行设置，每个层次的配置存储在不同的位置， 1）./etc/gitconfig 文件：包含了适用于系统所有用户和所有库的值。
如果你传递参数选项’--system’ 给 git config，它将明确的读和写这个文件。 2）.~/.gitconfig 文件 ：具体到你的用户。你可以通过传递--global 选项使 Git 读或写这个特定的文件。 3）.位于 git 目录的 config 文件 (也就是 .git/config) ：无论你当前在用的库是什么，特定指向该单一的库。
每个级别重写前一个级别的值。因此，在.git/config 中的值覆盖了在/etc/gitconfig 中的同一个值
[root@ci-node1 ~]# git config
usage: git config [options]
Config file location
--global use global config file 全局配置
--system use system config file 系统配置
--local use repository config file 仓库配置
mkdir git_data cd git_data/ # 初始化 git init # 查看工作区状态 git status
touch README git status git add README git status git commit -m ‘first commit‘ #→git commit提交暂存文件至版本库
添加新文件 git add * 添加到暂存区域 git commit 提交git仓库 -m 后面接上注释信息，内容关于本次提交的说明，方便自己或他人查看修改或删除原有文件 常规方法 git add * git commit 简便方法 git commit -a -m "注释信息" -a 表示直接提交 Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
没有添加到暂存区的数据直接rm删除即可。 已经添加到暂存区数据： git rm --cached database #→将文件从git暂存区域的追踪列表移除(并不会删除当前工作目录内的数据文件) git rm -f database #→将文件数据从git暂存区和工作目录一起删除
没有添加到暂存区的数据直接mv/rename改名即可。
已经添加到暂存区数据：
git mv README NOTICE
git log #→查看提交历史记录 git log -2 #→查看最近几条记录 git log -p -1 #→-p显示每次提交的内容差异,例如仅查看最近一次差异 git log --stat -2 #→--stat简要显示数据增改行数，这样能够看到提交中修改过的内容，对文件添加或移动的行数，并在最后列出所有增减行的概要信息 git log --pretty=oneline #→--pretty根据不同的格式展示提交的历史信息 git log --pretty=fuller -2 #→以更详细的模式输出提交的历史记录 git log --pretty=fomat:"%h %cn" #→查看当前所有提交记录的简短SHA-1哈希字串与提交者的姓名，其他格式见备注。
%s 提交说明。
%cd 提交日期。
%an 作者的名字。
%cn 提交者的姓名。
%ce 提交者的电子邮件。
%H 提交对象的完整SHA-1哈希字串。
%h 提交对象的简短SHA-1哈希字串。
%T 树对象的完整SHA-1哈希字串。
%t 树对象的简短SHA-1哈希字串。
%P 父对象的完整SHA-1哈希字串。
%p 父对象的简短SHA-1哈希字串。
%ad 作者的修订时间。
Git服务程序中有一个叫做HEAD的版本指针，当用户申请还原数据时，
其实就是将HEAD指针指向到某个特定的提交版本，但是因为Git是分布式版本控制系统，
为了避免历史记录冲突，故使用了SHA-1计算出十六进制的哈希字串来区分每个提交版本，
另外默认的HEAD版本指针会指向到最近的一次提交版本记录，而上一个提交版本会叫HEAD^，
上上一个版本则会叫做HEAD^^，当然一般会用HEAD~5来表示往上数第五个提交版本。 git reset --hard HEAD^ #→还原历史提交版本上一次 git reset --hard 3de15d4 #→找到历史还原点的SHA-1值后，就可以还原(值不写全,系统会自动匹配)
什么是未来数据？就是你还原到历史数据了，但是你后悔了，想撤销更改，但是git log已经找不到这个版本了。 git reflog #→查看未来历史更新点
前面回滚使用的是一串字符串，又长又难记。 git tag v1.0 #→当前提交内容打一个标签(方便快速回滚)，每次提交都可以打个tag。 git tag #→查看当前所有的标签 git show v1.0 #→查看当前1.0版本的详细信息 git tag v1.2 -m "version 1.2 release is test" #→创建带有说明的标签,-a指定标签名字，-m指定说明文字 git tag -d v1.0 #→我们为同一个提交版本设置了两次标签,删除之前的v1.0 [root@centos7 git_data]# git reset --hard 0bdf2e7 HEAD is now at 0bdf2e7 modified README file [root@centos7 git_data]# git reset --hard V1.0
git diff可以对比当前文件与仓库已保存文件的区别，知道了对README作了什么修改后，
再把它提交到仓库就放?多了。
git diff README
在实际的项目开发中，尽量保证master分支稳定，仅用于发布新版本，平时不要随便直接修改里面的数据文件。
那在哪干活呢？干活都在dev分支上。每个人从dev分支创建自己个人分支，开发完合并到dev分支，
最后dev分支合并到master分支。
所以团队的合作分支看起来会像下图那样。
git branch linux #→创建分支 git checkout linux #→切换分支 git branch #→查看当前分支情况,当前分支前有*号 测试在linux分支修改文件并提交到git仓库，最后切换回master分支，你会发现什么呢？
想把linux的工作成果合并到master分支上 先切换到master分支 git merge linux #→合并Linux分支至master 查看合并的文件 git branch -d linux #→确认合并完成后，可以放心地删除Linux分支。
同时修改master和linux分支同一个文件并提交，最后merge。
查看合并结果
如何解决？
这种情况下Git就没法再为我们自动的快速合并了，它只能告诉我们readme文件的内容有冲突，
需要手工处理冲突的内容后才能继续合并。
#Git用< <<<<<<，=======，>>>>>>>分割开了各个分支冲突的内容，
我们需要手工的删除这些符号，并将内容修改
前面讲的都是linux客户端，在讲讲windows客户端使用，安装Git-2.10.0-64-bit。
windows的git，本质是windows上的linux系统
TortoiseGit-2.2.0.0-64bit 给git加外壳，svn客户端的git版本
前面我们已经知道Git人人都是中心，那他们怎么交互数据呢？
1、使用GitHub或者码云等公共代码仓库
2、使用GitLab私有仓库
GitLab 是一个用于仓库管理系统的开源项目。使用Git作为代码管理工具，并在此基础上搭建起来的web服务。可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用。
代码仓库作为公司珍贵的财产，一定要单独部署在单独的服务器上，防止端口服务冲突。
常用的网站：
国内源镜像清华源：https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/
安装环境：
# 实验中使用过的，因为这样快~~~好操作，下面还列举了其他方法，没有使用，因为安装这个软件真慢
安装文档https://about.gitlab.com/downloads/#centos7
下载了rpm的包，这个版本很稳定
[root@ci-node1 ~]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-10.2.2-ce.0.el7.x86_64.rpm
安装依赖包
[root@ci-node1 tools]# yum install -y curl policycoreutils-python openssh-server
rpm安装
[root@ci-node1 tools]# rpm -ivh gitlab-ce-10.2.2-ce.0.el7.x86_64.rpm
配置文件
vim /etc/gitlab/gitlab.rb
修改extemal_url=“http://10.0.0.11”,透过访问这个地址来访问
#############这是什么鬼，忘记这个吧yum localinstall gitlab-ce-9.1.4-ce.0.el7.x86_64.rpm
只要修改了/etc/gitlab/gitlab.rb，就要执行gitlab-ctl reconfigure gitlab-ctl reconfigure #→初始化，就执行一次，
看状态/停止/启动/重启 gitlab-ctl status/stop/start/restart 通过浏览器访问页面10.0.0.11，设置初始密码，其他操作类似GitHUB。
如果出现502的错误，可能是服务器的内存太小，请至少设置2G内存，生产环境中至少4G 账户：root 密码自己设置为123456789
或者查看官方文档https://about.gitlab.com/install/#centos-7
1. 安装和配置必要的依赖关系Install and configure the necessary dependencies 如果你安装postfix发送邮件，请选择”网站设置”中。而不是使用后缀也可以用邮件或 配置自定义SMTP服务器。如果你想使用的进出口，请 配置为SMTP服务器。 在CentOS7，下面的命令将在系统防火墙打开HTTP和SSH访问。 yum install curl openssh-server postfix systemctl enable sshd postfix systemctl start sshd postfix firewall-cmd –permanent –add-service=http systemctl reload firewalld 2. 添加gitlab包服务器安装包Add the GitLab package server and install the package curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash yum install gitlab-ce 3. 配置并启动gitlab Configure and start GitLab gitlab-ctl reconfigure gitlab-ctl status gitlab-ctl stop gitlab-ctl start 4. 浏览到主机名和登录Browse to the hostname and login Username: root Password: 5iveL!fe
GitLab 由主要由以下13 个服务构成，他们共同承担了 Gitlab 的运作需要 Nginx：静态 web 服务器。 gitlab-shell：用于处理 Git 命令和修改 authorized keys 列表。 gitlab-workhorse: 轻量级的反向代理服务器。 logrotate：日志文件管理工具。 postgresql：数据库。 redis：缓存数据库。 sidekiq：用于在后台执行队列任务（异步执行）。 unicorn：An HTTP server for Rack applications，GitLab Rails 应用是托管在这个 服务器上面的。 我们可以使用 gitlab-ctl status 命令来查看各服务的状态 [root@ci-node1 src]# gitlab-ctl status run: gitaly: (pid 17752) 652s; run: log: (pid 8831) 5484s run: gitlab-monitor: (pid 17768) 651s; run: log: (pid 9000) 5458s run: gitlab-workhorse: (pid 17771) 651s; run: log: (pid 8898) 5478s run: logrotate: (pid 17815) 650s; run: log: (pid 8930) 5471s run: nginx: (pid 17821) 650s; run: log: (pid 8906) 5477s run: node-exporter: (pid 17828) 649s; run: log: (pid 8978) 5465s run: postgres-exporter: (pid 17833) 649s; run: log: (pid 9107) 5440s run: postgresql: (pid 17841) 649s; run: log: (pid 8649) 5533s run: prometheus: (pid 17850) 648s; run: log: (pid 9071) 5446s run: redis: (pid 17858) 648s; run: log: (pid 8589) 5545s run: redis-exporter: (pid 17865) 647s; run: log: (pid 9050) 5452s run: sidekiq: (pid 17871) 646s; run: log: (pid 8811) 5490s run: unicorn: (pid 17895) 645s; run: log: (pid 8772) 5496s
静态的访问
GitLab Shell 有两个作用：为 GitLab 处理 Git 命令、修改 authorized keys 列表。
通过 SSH 访问 GitLab Server 时，GitLab Shell 会： 限制执行预定义好的 Git 命令（git push, git pull, git annex） 调用 GitLab Rails API 检查权限 执行 pre-receive 钩子（在 GitLab 企业版中叫做 Git 钩子） 执行你请求的动作 处理 GitLab 的 post-receive 动作 处理自定义的 post-receive 动作 当通过 http(s)访问 GitLab Server 时，
工作流程取决于你是从 Git 仓库拉取(pull)代码还是向 git 仓库推送(push)代码。 如果你是从 Git 仓库拉取(pull)代码，GitLab Rails 应用会全权负责处理用户鉴权和执行 Git 命令的工作； 如果你是向 Git 仓库推送(push)代码，GitLab Rails 应用既不会进行用户鉴权也不会执行 Git 命令，
它会把以下工作交由 GitLab Shell 进行处理： 调用 GitLab Rails API 检查权限 执行 pre-receive 钩子（在 GitLab 企业版中叫做 Git 钩子） 执行你请求的动作 处理 GitLab 的 post-receive 动作 处理自定义的 post-receive 动作
GitLab Workhorse 是一个敏捷的反向代理。它会处理一些大的 HTTP 请求，比如文件上 传、文件下载、Git push/pull 和 Git 包下载。其它请求会反向代理到 GitLab Rails 应用， 即反向代理给后端的 unicorn。
gitlab-ctl status:查看gitlab组件状态 gitlab-ctl start:启动全部服务 gitlab-ctl restart:重启全部服务 后面可以跟指定服务，只对，对应的服务有效 gitlab-ctl stop：停止全部服务 后面可以跟指定服务，只对，对应的服务有效 gitlab-ctl reconfigure:使配置文件生效（一般修改完主配置文件/etc/gitlab/gitlab.rb，需要执行此命令） gitlab-ctl show-config ：验证配置文件 gitlab-ctl uninstall:删除gitlab（保留数据） gitlab-ctl cleanse:删除所有数据，从新开始 gitlab-ctl tail <service name>查看服务的日志
/var/opt/gitlab/git-data/repositories：库默认存储目录 /opt/gitlab： 应用代码和相应的依赖程序 /var/opt/gitlab：gitlab-ctl reconfigure命令编译后的应用数据和配置文件，不需要人为修改配置 /etc/gitlab： 配置文件目录 gitlab.rb /var/log/gitlab：此目录下存放了gitlab各个组件产生的日志 /var/opt/gitlab/backups/：备份文件生成的目录
扳手---Settings---Sign-up Restrictions
applications自定义界面和导航栏
GitLab是通过组（group）的概念来管理仓库（project）和用户（user），通过创建组，在组下再创建仓库，再将用户加入到组，从而实现用户与仓库的权限管理。
创建组的时候，path和name保持一致，
创建dev用户
在页面上设置用户类型
在实际使用过程中，我们通常会保持 master 分支稳定，用于生产环境的版本发布，只
有授权的用户才可以向 master 合并代码。要实现此功能，我们需要将 master 设置为保护分
支，并授权什么用户可以向 master 用户推送代码。
1、使用 root 用户点击 git_test 仓库页面左下角的 Settings
2、进入设置页面，选择设置菜单栏下面的 Repository 选项，
3、进入 repository 设置页面，
4、展开 Protected Branches
置完成后，在仓库分支页面，可看到 master 分支后面出现一个绿色的 protected 标记。
此时我们再尝试在 ci-node2 上推送 master 分支到 GitLab，
我们发现此时我们已经不能在 ci-node2 上向 GitLab 上推送 master 分支，因为我们
ci-node2 绑定的是 dev 用户，dev 用户属于 developer 角色，master 分支不允许 developer
角色向其推送内容。
需要合并的时候，在仓库页面提出申请
生成key------ ssh-keygen #生成密钥命令----- cat /root/.ssh/id_rsa.pub 查看公钥
Linux上复制公钥------绑定到GitLab的root上------点击root用户-----找到左边栏SSH------复制------保存
将本地仓库推送到GitLab ------git remote add gitlab url
对 gitlab 进行备份将会创建一个包含所有库和附件的归档文件。
对备份的恢复只能恢复到与备份时的 gitlab 相同的版本。
将 gitlab 迁移到另一台服务器上的最佳方法就是通过备份和还原。
gitlab 提供了一个简单的命令行来备份整个 gitlab，并且能灵活的满足需求
。
备份文件将保存在配置文件中定义的 backup_path 中 ，文件名为TIMESTAMP_gitlab_backup.tar
TIMESTAMP 为备份时的时间戳
TIMESTAMP 的 格 式为 ： EPOCH_YYYY_MM_DD_Gitlab-version 默认的备份文件目录为：/var/opt/gitlab/backups，如果自定义备份目录需要赋予目录 git 权限
具体操作如下： 配置文件中加入 gitlab_rails[‘backup_path‘] = ‘/data/backup/gitlab‘ gitlab_rails[‘backup_keep_time‘] = 604800 #备份保留的时间（以秒为单位，这个是七天默认值）， 在命令行执行如下命令，如果软件自动生成了目录，在看一下权限是否正确，有的话，就不用执行下面的两行 [root@ci-node1 git_test] # mkdir /data/backup/gitlab -p [root@ci-node1 git_test] # chown -R git.git /data/backup/gitlab [root@ci-node1 git_test] # gitlab-ctl reconfigure
在命令执行：gitlab-rake gitlab:backup:create 生成一次备份。 [root@ci-node1 git_test]# gitlab-rake gitlab:backup:create Dumping database ... Dumping PostgreSQL database gitlabhq_production ... [DONE] done Dumping repositories ... * oldboy/git_test ... [DONE] * oldboy/git_test.wiki ... [SKIPPED] done Dumping uploads ... done...
...
通过在定时任务里添加： 0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1 我们来实现定时备份，由于代码是一个企业非常重要的资产，所以我们要重视 GitLab 的备份工作。至少做到每天备份一次，平时要注意检查备份的完整性。 环境变量 CRON=1 的作用是如果没有任何错误发生时， 抑制备份脚本的所有进度输出
GitLab 的恢复只能还原到与备份文件相同的 gitlab 版本的系统中，
恢复时，停止连接到数据库的进程（也就是停止数据写入服务），但是保持 GitLab 是运行的。
[root@ci-node1 git_test]# gitlab-ctl stop unicorn ok: down: unicorn: 0s, normally up [root@ci-node1 git_test]# gitlab-ctl stop sideki [root@ci-node1 git_test]# gitlab-ctl status run: gitaly: (pid 46031) 25295s; run: log: (pid 8831) 68406s run: gitlab-monitor: (pid 46042) 25294s; run: log: (pid 9000) 68380s run: gitlab-workhorse: (pid 46051) 25294s; run: log: (pid 8898) 68400s run: logrotate: (pid 26776) 93s; run: log: (pid 8930) 68393s run: nginx: (pid 46068) 25293s; run: log: (pid 8906) 68399s run: node-exporter: (pid 46074) 25292s; run: log: (pid 8978) 68387s run: postgres-exporter: (pid 46079) 25292s; run: log: (pid 9107) 68362s run: postgresql: (pid 46126) 25291s; run: log: (pid 8649) 68455s run: prometheus: (pid 46134) 25291s; run: log: (pid 9071) 68368s run: redis: (pid 46142) 25291s; run: log: (pid 8589) 68467s run: redis-exporter: (pid 46146) 25290s; run: log: (pid 9050) 68374s run: sidekiq: (pid 25878) 524s; run: log: (pid 8811) 68412s down: unicorn: 33s, normally up; run: log: (pid 8772) 68418s 接下来执行 gitlab 恢复操作：将备份的数字部分粘贴到BACKUP=后面 [root@ci-node1 git_test]# gitlab-rake gitlab:backup:restore
BACKUP=1533288168_2018_08_03_10.2.2 整个恢复执行过程中，我们可以看到基本是在删除表，创建表。
完成后，重启服务。
首先，下载新版本的 RPM 包，可以通过官网或者清华镜像站获取。 其次关闭部分 gitlab 服务 gitlab-ctl stop unicorn gitlab-ctl stop sidekiq gitlab-ctl stop nginx 执行升级操作 rpm -Uvh gitlab-ce-10.0.4-ce.0.el7.x86_64.rpm 重新配置 gitlab 重启 gitlab 服务 注：升级操作不建议进行。如果确实需要，也可以采取在一台新的服务器上安装新版本的 Gitlab
然后采用导入库的方式将旧系统的代码仓库导入到新 Gitlab 上。
查看文档
Github顾名思义是一个Git版本库的托管服务，是目前全球最大的软件仓库，拥有上百万的开发者用户，
也是软件开发和寻找资源的最佳途径，Github不仅可以托管各种Git版本仓库，还拥有了更美观的Web界面，
您的代码文件可以被任何人克隆，使得开发者为开源项贡献代码变得更加容易，当然也可以付费购买私有库，
这样高性价比的私有库真的是帮助到了很多团队和企业。 具体使用方法见博客http://blog.oldboyedu.com/git/
https://blog.csdn.net/zy00000000001/article/details/70505150
标签：rest gradle minimal add 指针 paper 特征 命令行 异步执行
原文地址：https://www.cnblogs.com/bubu99/p/12275453.html
