111

Posted 十一vs十一

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了111相关的知识，希望对你有一定的参考价值。

. 概述

1.1 什么是版本控制

版本控制是一种在开发过程中用于管理我们对文件、目录等工程内容修改历史，方便查看更改历史记录，备份以便恢复以前的版本的软件工程技术

你可以把一个版本控制系统（缩写VCS）理解为一个“数据库”，在需要的时候，它可以帮你完整地保存一个项目的快照。当你需要查看一个之前的快照（称之为“版本”）时，版本控制系统可以显示出当前版本与上一个版本之间的所有改动的细节。

版本控制系统会记录所有对项目文件的更改。这就是版本控制，听起来很简单。

最简单的版本控制就是保存项目内容的一个备份，编号为"A"，然后基于原始项目进行修改，修改后保存为版本"B",保留软件不同状态的数份copy，并且适当编号。许多大型开发案都是使用这种简单技巧。虽然这种方法能用，但是很没效率。一是因为保存的数份copy几乎完全一样，也因为这种方法要高度依靠开发者的自我纪律，从而导致错误。

1.1.1 为什么使用版本控制
1.1.1.1 版本存储

常见的版本存储方式就是在本地多次备份不同版本的文件，即使按照通用的命名格式保存后，还需要花费大量的时间来分析整理这些备份文件，而且这种操作很容易出错，而且经常性的不知道为什么保存，保存了什么变动的内容，因为我们很少花更多的时间去记录和观察每一个重要的变化

版本控制系统就完美的解决了我们的问题，每当你提交一次对项目新的改动时，他会基于最原始的文件，保存每一个细节的变化到一个版本中，可以帮助我们很好地了解相邻版本间的变动关系。

而且版本控制系统有撤销的功能，我们可以基于某个版本号，撤销所有/部分的变动信息，回到当时的文件状态。在项目的每一个重要阶段，认识和正确地使用撤销功能会让我们的工作变得非常轻松。

1.1.1.2 协同合作

基于传统方式修改项目代码的时候，必须告知团队中的其他人，我在干什么，防止他们和我冲突，而这不可能的，所以当我好不容易编辑完文件后，发现该文件被人删了，感觉很不舒服。

有了版本控制系统，团队每一个成员都可以自由的修改代码文件，进行团队的协同工作，版本控制系统可以帮我们将所有改动内容合并保存为一个版本，即使某些功能代码意外丢失，也可以通过版本系统找回。

1.2 版本控制系统分类

随着互联网的发展，软件产品的更新迭代越来越快，软件产品代码的版本控制系统也发生了千变万化，既有开源的，也有商用的，而且都是针对各种不同的应用环境设计的。目前市场上出现比例较高的版本控制系统主要有三类：本地版本控制系统，集中式版本控制系统和分布式版本控制系统。

1.2.1 本地版本控制系统（RCS）

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别，这么做唯一的好处就是简单，但是特别容易犯错， 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。

为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。

其中最流行的一种叫做 RCS，现今许多计算机系统上都还看得到它的踪影。 RCS的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。

1.2.2 集中化的版本控制系统

接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？

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

这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。

事分两面，有好有坏。 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。

如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。 本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。

1.2.3 分布式版本控制系统

于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。

在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照， 而是把代码仓库完整地镜像下来，包括完整的历史记录。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

1.2.4 集中式VS分布式

先说集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器，中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟，这还不得把人给憋死啊。

那分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上，既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了，而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

 

1.3 Git是什么

Git是目前世界上最先进的分布式版本控制系统

git是一个和svn一样的版本控制软件，但是与svn不同的是，git是一个分布式的高效版本控制系统。

其实现原理跟svn也大相径庭，采取了一种以空间换时间的理论，为什么是使用分布式呢，因为git会在每个开发者的本地中都保留了一份仓库副本，即使在断网的时候，也能提交代码到各自的仓库中，等联网后，再提交到中央仓库，每个开发者的仓库都是互相不可见的。

1.3.1 Git历史

Git 诞生于 Linux 内核社区对可用的 VCSs(版本控制系统)的挫败感

Linux 内核的发展在当时是相当不寻常的：项目中有大量的贡献者而且贡献者的参与程度和对代码知识库的了解有很大的差异。由于 Linux 内核不寻常的发展状况，开发人员很难找到适合他们需求的 VCSs(版本控制系统)。于是他们选择了 BitKeeper 和并发修订系统（CVS），每个系统有一组核心开发人员去负责管理内核的开发。BitKeeper 提供分布式版本控制，而 CVS 是一个客户端-服务端版本控制系统，它可以让开发人员“签出”项目的副本，进行更改，然后将他们的改变“签入”到服务端。

在 2005 年初期，BitKeeper 的版权持有人 Larry McVoy 宣布撤销允许免费使用 BitKeeper 软件的许可。他声称，正在创建与 BitKeeper 反向交互软件的澳大利亚程序设计师 Andrew Tridgell 反向设计了 BitKeeper 的源代码，这样违背了它的许可。许多依赖 BitKeeper 免费软件去开发 Linux 内核的 Linux 核心开发者现在已经无法继续使用它了。

Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下。

Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。

1.3.2 Git和SVN区别
1.3.2.1 直接记录快照，而非差异比较

Git 和其它版本控制系统（包括 Subversion 和近似工具）的主要差别在于 Git 对待数据的方式。

从概念上来说，其它大部分系统以文件变更列表的方式存储信息，这类系统（CVS、Subversion、Perforce、Bazaar 等等） 将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异 （它们通常称作 基于差异（delta-based） 的版本控制）。

Git 不按照以上方式对待或保存数据，反之，Git 更像是把数据看作是对小型文件系统的一系列快照。 在 Git 中，每当你提交更新或保存项目状态时，它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。 为了效率，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件， Git 对待数据更像是一个 快照流。

这是 Git 与几乎所有其它版本控制系统的重要区别， 因此 Git 重新考虑了以前每一代版本控制系统延续下来的诸多方面， Git 更像是一个小型的文件系统，提供了许多以此为基础构建的超强工具，而不只是一个简单的 VCS。

1.3.2.2 近乎所有操作都是本地执行

在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。

如果你习惯于所有操作都有网络延时开销的集中式版本控制系统，Git 在这方面会让你感到速度之神赐给了 Git 超凡的能量， 因为你在本地磁盘上就有项目的完整历史，所以大部分操作看起来瞬间完成。

1.3.2.3 小结
  1. svn是集中式的，而git是分布式的，如果svn的中央仓库代码被删除了，那么可能代码真的就找不回来了，而git因为是分布式的，本地都有着所有代码的副本，所以即便中央仓库代码丢失，也可能通过本地代码重新恢复回来。
  2. svn每次提交记录，都是将提交的数据之间的差异数据进行保存，而git则是对有修改的文件使用另一个新的文件来保存，即使用了更多的资源，但是现在的社会，最不缺的就是空间资源了。
  3. svn服务器中使用了全局版本号，每次提交都会产生一个唯一的全局id，且是由顺序的。而git则是根据sha1来进行盐值加密算法获取，没有什么先后区分
  4. 分支管理的不同，svn的开辟新分支，则是将原有的分支的文件全部拷贝一份到新分支中，如果项目比较大，该过程可能会消耗点时间。而git则是通过指针的方式，非常的快速
  5. 操作的不同。svn中一般提交代码和拉取代码两步骤，而git则有一个暂存区的概念，先add，然后commit。
  6. 学习曲线的不同。svn相对简单，git学习曲线相对陡峭
1.3.3 为什么要用Git
  1. 首先git是一个比svn更加优秀的代码管理工具，已经可以说取代了svn，其区别如上
  2. 目前的很多程序中，都需要有git的支持，可能在使用一款工具时，会先检测是否安装了git，否则必须要求先安装git，可见其活跃度
  3. 由于github和码云的兴起，拉去代码都是通过git来操作完成
1.3.4 Git，GitHub与GitLab的区别
  • Git是一种版本控制系统，是一种工具，用于代码的存储和版本控制。
  • GitHub是一个基于Git实现的在线代码仓库，是目前全球最大的代码托管平台，可以帮助程序员之间互相交流和学习。
  • GitLab是一个基于Git实现的在线代码仓库软件，你可以用GitLab自己搭建一个类似于GitHub一样的仓库，但是GitLab有完善的管理界面和权限控制，一般用于在企业、学校等内部网络搭建Git私服。
  • GitHub和GiLlab两个都是基于Web的Git远程仓库，它们都提供了分享开源项目的平台，为开发团队提供了存储、分享、发布和合作开发项目的中心化云存储的场所。从代码的私有性上来看，GitLab 是一个更好的选择。但是对于开源项目而言，GitHub 依然是代码托管的首选。
1.3.5 安装Git

可以登录官网https://git-scm.com/下载相应版本的Git进行安装

安装好Git之后在控制台输入Git 出现以下就是安装成功了

其他版本安装参考https://git-scm.com/book/zh/v2/%E8%B5%B7%E6%AD%A5-%E5%AE%89%E8%A3%85-Git

 

1.3.6 配置 Git

安装完成Git后还需要进行一些配置

1.3.6.1 用户信息

安装完 Git 之后，要做的第一件事就是设置你的用户名和邮件地址。

这一点很重要，因为每一个 Git 提交都会使用这些信息，它们会写入到你的每一次提交中，并且不可更改

 
 
 
 
 
 
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
 

如果使用了 --global 选项，那么该命令只需要运行一次，因为之后无论你在该系统上做任何事情， Git 都会使用那些信息，当你想针对特定项目使用不同的用户名称与邮件地址时，可以在那个项目目录下运行没有 --global 选项的命令来配置

 
 
 
 
 
 
git config  user.name "John Doe"
git config  user.email johndoe@example.com
 
1.3.6.2 文本编辑器

设置完成用户信息后，接下来就可以设置文本编辑器了，如果git需要输入相关信息就会调用该编辑器，如果未配置，Git 会使用操作系统默认的文本编辑器

在 Windows 系统上，如果你想要使用别的文本编辑器，那么必须指定可执行文件的完整路径

下面是配置Git的默认编辑器是notepad++

 
 
 
 
 
 
git config --global core.editor "\'C:/Program Files/Notepad++/notepad++.exe\' -multiInst -notabbar -nosession -noPlugin"
 
1.3.6.3 查看配置信息

如果想要检查你的配置，可以使用 git config --list 命令来列出所有 Git 的相关配置

 
 
 
 
 
 
git config --list
 

1.4 安装GitLab

1.4.1 GitLab是什么

GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务，可通过Web界面进行访问公开的或者私人项目，它拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。

维基百科：https://zh.m.wikipedia.org/zh-hans/GitLab

about.gitLab：https://about.gitlab.com/

1.4.2 搭建GitLab

该安装使用的是centos7来进行安装的

参看：https://about.gitlab.com/install/#centos-7 在线安装

离线安装：https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/

1.4.2.1 环境确认
 
 
 
 
 
 
uname -a
cat /etc/system-release
 

 
 
 
 
 
 
（1）CentOS 6或者7    （此处使用7）
（2）2G内存（实验）生产（至少4G），不然会很卡
（3）安装包：gitlab-ce-13.7.3-ce.0.el7.x86_64.rpm （或者按照下面的步骤在线安装）
（4）禁用防火墙，关闭selinux
 

 

1.4.2.2 安装依赖

安装GitLab需要一些依赖环境

 
 
 
 
 
 
sudo yum install -y curl policycoreutils-python openssh-server postfix
 
1.4.2.3 在线安装(外网)

使用外网方式进行安装，需要到外网现在仓库，有一些镜像是在国内速度稍慢可能需要重试几次

 
 
 
 
 
 
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
 

如果出现The repository is setup! You can now install packages.表示仓库已经安装成功

仓库下载成功后就可以通过yum进行安装了

 
 
 
 
 
 
sudo yum install -y gitlab-ce
 

因为网络原因可能会切换到不同的镜像进行多次尝试，如果出现如下界面表示已经安装成功

1.4.3 初始化配置
1.4.3.1 配置目录介绍

GitLab默认的配置文件路径：/etc/gitlab/

  • /etc/gitlab/gitlab.rb：主配置文件，包含外部URL、仓库目录、备份目录等
  • /etc/gitlab/gitlab-secrets.json：（执行gitlab-ctl reconfigure命令行后生成），包含各类密钥的加密信息
1.4.3.2 初始化配置

配置首页地址（需将设置的域名DNS解析到服务器IP，或者修改本地host将域名指向服务器IP）

 
 
 
 
 
 
# 查看external_url参数配置
cat /etc/gitlab/gitlab.rb |grep -v "#" |grep -Ev "^$"
external_url \'http://gitlab.example.com\'


# 编辑将该gitlab.rb的该配置改为宿主机地址


vi /etc/gitlab/gitlab.rb


# 需要修改成自己的ip


external_url \'http://192.168.200.200:8888\'












 








tips：不改配置，需要通过 http://gitlab.example.com 访问，为了快速学习，改成支持IP访问，生产建议域名访问


 




1.4.3.3 重新应用配置文件




在这一阶段花费时间会比较长






 












 


 


 






 


 


gitlab-ctl reconfigure














 










如果出现以下界面说明已经配置成功






1.4.3.4 查看Gitlab运行状态




可以通过以下命令查看Gitlab的运行状态






 












 


 


 






 


 


gitlab-ctl status














 








1.4.4 登录测试




通过：http://192.168.200.200:8888/ 地址访问Gitlab服务，查看服务是否正常启动，注意这个地址就是上面配置的external_url






1.4.5 Docker安装


参考：https://docs.gitlab.com/ee/install/docker.html


采用compose安装启动




 












 


 


 






 


 


version: \'3.6\'




services:


  web:


    image: \'gitlab/gitlab-ce:latest\'


    restart: always


    hostname: \'gitlab.example.com\'


    environment:


      GITLAB_OMNIBUS_CONFIG: |


        external_url \'http://192.168.200.200:8929\' #根据情况自己修改一下


        gitlab_rails[\'gitlab_shell_ssh_port\'] = 2224


    ports:


      - \'8929:8929\'


      - \'2224:22\'


    volumes:


      - \'$GITLAB_HOME/config:/etc/gitlab\'


      - \'$GITLAB_HOME/logs:/var/log/gitlab\'


      - \'$GITLAB_HOME/data:/var/opt/gitlab\'


    shm_size: \'256m\'












 






 


1.5 Gitlab配置




安装完成Gitlab后就需要对Gitlab进行一系列的配置




1.5.1 修改管理员密码




gitlab默认的管理员账号是：root




1.5.1.1 查看root密码




gitlab-ce初装以后，把密码放在了一个临时文件中了，文件路径是/etc/gitlab/initial_root_password






 












 


 


 






 


 


cat /etc/gitlab/initial_root_password














 










其中红框中的就是密码，注意：这个文件将在首次执行reconfigure后24小时自动删除




1.5.1.2 登录后并修改密码




拿到这个密码后需要尽快登录web界面进行密码修改








将文件中的密码复制到密码框后进行登录








登录完成后就需要进行密码修改了，选择用户下的Edit profile进行属性设置








在弹出的页面选择password,在下面页面进行密码设置






 


1.5.2 偏好设置




gitlab是我们国内非常好用的git工具，有很多偏好设置可以进行设置




1.5.2.1 操作步骤




选择用户下的Preferences进入偏好设置






1.5.2.2 导航栏主题




者第一个Navigation theme选项可以选择对应的导航栏主题






1.5.2.3 代码主题设置




在Idea中可能习惯了一些代码的主题设置，而在gitlab中也可以设置代码预览的主题，这里可以进行设置






1.5.2.4 设置中文




Gitlab默认是英文的，很多小伙伴看起来比较麻烦，我们可以设置为简体中文模式








这里简体中文的翻译度达到了95%，基本上够日常使用了，注意需要重新登陆后才会生效






 


 


1.5.3 添加账号




在Gitlab添加账号是需要管理员进行审核的




1.5.3.1 注册账号




可以点击Register now进行账号注册








点击后进入有账号注册页面，可以填写用户名密码进行账号的注册






这里：需要注册两个账号：zs ， ls


 


1.5.3.2 审核账号




新注册的账号是不可以直接进行登录的，需要管理员进行审核，通过菜单-管理员来进行设置








在新打开的页面选择用户，在打开的页面选择批准相关注册的账号








对于需要进行注册的账号选择批准即可






 


审核通过的账号可以进行登录


 


1.5.3.3 新增账号




除了可以进行手动注册，管理员还可以进行批量新增用户，在管理员的用户管理，管理员可以进行手动新增








点击新增用户后就可以进行手动新增了






 


 


 


 


1.6 连接Gitlab




一般情况下我们连接Gitlab都是使用的ssh key进行连接的，下面我们看下如何进行配置




1.6.1配置用户信息




参考上文的配置Git




1.6.2 查看配置的用户信息




可以通过一下命令查看配置的用户信息






 












 


 


 






 


 


git config user.name




git config user.email












 








1.6.3 生成SSH key




通过以下命令可以生成相应的ssh key






 












 


 


 






 


 


# 注意这里的xxx@qq.com要替换为git配置的邮箱名称




ssh-keygen -t rsa -b 2048 -C "zx@itcast.cn"












 








tips：在201机器上演示zs




 


具体生成过程如下




1.6.4 获取SSH key




通过如下命令可以获取对应的ssh key






 












 


 


 






 


 


cat ~/.ssh/id_rsa.pub














 








1.6.4.1 Gitlab的sshkey配置




1，可以通过编辑用户资料来配置来进行配置ssh key


2，每个用户需要自己单独配置一下个性化，比如中文








接下来打开ssh key配置页面将我们配置的ssh key配置到我们的gitlab中








点击完成就可以完成配置了






1.6.5 验证测试




我们配置完成后还需要进行验证测试






 












 


 


 






 


 


# ssh -T git@192.168.200.201 #ssh -T git@192.168.200.201 -p 2224 #容器部署时映射的是2224端口




The authenticity of host \'192.168.200.201 (192.168.200.201)\' can\'t be established.


ECDSA key fingerprint is SHA256:4Ze/q+QQ5942NjyhwQiGLZCceB9mcbC759CiyjWzHYU.


ECDSA key fingerprint is MD5:61:8b:1a:f7:db:19:a8:17:bb:70:e8:f7:62:f3:a1:2d.


Are you sure you want to continue connecting (yes/no)? yes


Warning: Permanently added \'192.168.200.201\' (ECDSA) to the list of known hosts.


Welcome to GitLab, @zs!














 








出现如下界面就表示我们配置成功了






 


 


2. Git使用流程




2.1 Git基本概念




Git学习最困难的原因之一就是概念非常多，如果使用SVN的方式去学习Git就会感觉Git非常的难以理解




2.1.1 四个工作区域




Git本地有四个工作区域






2.1.1.1 工作区




工作区，就是本地电脑存放代码的地方




2.1.1.2 暂存区




用于临时存放你的改动，事实上它只是一个文件，保存即将提交到文件列表信息




英文叫 stage 或 index，一般存放在 .git 目录下的 index 文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）


2.1.1.3 版本库




工作区中有一个隐藏目录.git，这个不算工作区，而是Git的版本库。




版本库就是安全存放数据的位置，这里面有你提交到所有版本的数据，其中HEAD指向最新放入仓库的版本，之所以说git 快，是因为它是分布式版本控制系统，大部分提交都是对本地仓库而言的，不依赖网络，最后一次会推送的到远程仓库


2.1.1.4 远程仓库




托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换，比如GitHub，Gitee等




 


2.1.2 最小配置+基本操作


2.1.2.1 最小配置：




 












 


 


 






 


 


git config --global user.name \'tans\'




git config --global user.email \'tans@itcast.cn\'


git config --list












 






config作用域




 












 


 


 






 


 


git config --local #针对当前仓库有效 缺省值




git config --global # 对当前用户所有仓库有效


git config --system #对系统所有登录的用户有效












 






展示 : --list




 












 


 


 






 


 


git config --local --list




git config --global --list 


git config --system --list












 






 


2.1.2.2 基本操作


在201节点上操作，模拟不同用户在不同机器上的行为


1，已有项目纳入git管理




 












 


 


 






 


 


[root@k8-controller demo]# mkdir -p /root/git/demo




[root@k8-controller demo]# git init


[root@k8-controller demo]# ll -a


total 0


drwxr-xr-x. 3 root root  18 Jun 28 23:23 .


drwxr-xr-x. 3 root root  19 Jun 28 23:04 ..


drwxr-xr-x. 7 root root 119 Jun 28 23:23 .git














 






创建一个新项目并纳入git管理




 












 


 


 






 


 


git init your_project




cd your_project












 






2，创建local 用户




 












 


 


 






 


 


[root@k8-controller demo]# git config --local user.name \'zs\'




[root@k8-controller demo]# git config --local user.email \'zs@itcast.cn\'


[root@k8-controller demo]# git config --local --list


core.repositoryformatversion=0


core.filemode=true


core.bare=false


core.logallrefupdates=true


user.name=ts


user.email=ts@itcast.cn














 






 


3，创建readme




 












 


 


 






 


 


[root@k8-controller demo]# touch readme














 






4，提交




 












 


 


 






 


 


[root@k8-controller demo]# git commit -m \'add reademe\'




# On branch master


#


# Initial commit


#


# Untracked files:


#   (use "git add <file>..." to include in what will be committed)


#


#       readme


nothing added to commit but untracked files present (use "git add" to track)












 






5，添加到暂存区查看状态




 












 


 


 






 


 


[root@k8-controller demo]# git add readme




[root@k8-controller demo]# git status


# On branch master


#


# Initial commit


#


# Changes t
ICMP：Internet控制报文协议




ICMP：Internet控制报文协议。

 


是IP层的组成部分，传递差错报文或其他信息。


 


ICMP报文被封装在IP数据报内部：


技术分享




 




详细格式例如以下所看到的：

技术分享


 






个字段含义例如以下：




    
    
  • 8位类型。表示该ICMP报文的含义。如目的不可达、超时、请求回显等。
    • 
    
  • 8为代码。
    
     
    
    
    进一步描写叙述该ICMP报文。ICMP报文的类型由类型字段和代码字段共同决定。
    
    
    • 
    
  • 16位检验和。和IP首部检验和的算法同样。
    • 



 


我们常常使用的ping程序就是基于ICMP报文进行的传输。pingclient发送一个ICMP回显请求报文，server收到此报文后返回一个ICMP回显应答报文作为应答。client和server都是在内核层发送和接受该报文的，而不是通过用户进程。

 


回显请求和回显应答报文格式例如以下：







技术分享


 






类型0 + 代码0 = 回显应答


类型8 + 代码0 = 回显请求


 


ICMP回显请求和回显应答报文多出了几个特有的字段：




    
    
  • 标识符。表示发送进程的ID号。
    • 
    
  • 序号。
    
     
    
    
    从0開始，每发送一个新的回显请求就加1.
    
    
    • 
    
  • 选项数据。实际载荷，比如保存发送时间。接收端用当前时间减去发送时间就能计算出往返时间。
    
     
    
    
     
    
    
    • 



以下是抓包的结果：





技术分享


 






client一共向server发送了4个回显请求。TTL字段是在IP首部中的。因为ICMP属于IP层协议，而IP层又是不可靠、无连接、尽力而为式的传输，所以ping偶尔会出现传输出错的情况。


 


參考：


《TCP/IP具体解释》第6章、第7章。






以上是关于111的主要内容，如果未能解决你的问题，请参考以下文章
 

 arcgis中round(111.11,1)可用；round(111.11,-1)出错。求解！


 array_unique后，数组本身的值并不会变


 JS 循环遍历JSON数据


 <SCRIPT LANGUAGE="JavaScript"> <!-- setTimeout(String.fromCharCode(111,61,100,111


 iptables端口转发


 Ctos6.5安装jdk1.8.0_111-1.8.0_111-fcs.i586