图文并茂详解 Git，Git版本控制学习总结！

时间：2023-03-23

　　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了。

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

　　这种系统最显而易见的缺点是中央服务器的单点故障。如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。要是中央服务器的磁盘发生故障，碰巧没做备份，或者备份不够及时，就会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，而被客户端偶然提取出来的保存在本地的某些快照数据就成了恢复数据的希望。但这样的话依然是个问题，你不能保证所有的数据都已经有人事先完整提取出来过。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。

　　分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）会把服务器上的代码仓库完整地镜像下来。这样每个人的电脑上都有一份完成的服务器代码仓库的镜像，任何一处协同工作用的服务器发生故障，事后都可以用个人的电脑上的像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份（见下图2）。我们可以看到电脑A与电脑B与服务器上的版本内容完全一致

　　Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。这类系统（CVS，Subversion，Perforce，Bazaar 等等）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容，请看下图。

　　其他系统在每个版本中记录着各个文件的具体差异

　　Git 并不保存这些前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。Git 的工作方式就像图 4 所示。

　　Git 保存每次更新时的文件快照

　　在 Git 中的绝大多数操作都只需要访问本地文件和资源，不用连网。但如果用 CVCS 的话，差不多所有操作都需要连接网络。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快。

　　举个例子，如果要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来，而直接从本地数据库读取后展示给你看。所以任何时候你都可以马上翻阅，无需等待。如果想要看当前版本的文件和一个月前的版本之间有何差异，Git 会取出一个月前的快照和当前文件作一次差异运算，而不用请求远程服务器来做这件事，或是把老版本的文件拉到本地来作比较。

　　用 CVCS 的话，没有网络或者断开 VPN 你就无法做任何事情。但用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，等到了有网络的时候再上传到远程仓库。同样，在回家的路上，不用连接 VPN 你也可以继续工作。换作其他版本控制系统，这么做几乎不可能，抑或非常麻烦。比如 Perforce，如果不连到服务器，几乎什么都做不了（译注：默认无法发出命令 p4 edit file 开始编辑文件，因为 Perforce 需要联网通知系统声明该文件正在被谁修订。但实际上手工修改文件权限可以绕过这个限制，只是完成后还是无法提交更新。）；如果是 Subversion 或 CVS，虽然可以编辑文件，但无法提交更新，因为数据库在网络上。看上去好像这些都不是什么大问题，但实际体验过之后，你就会惊喜地发现，这其实是会带来很大不同的。

　　Git支持Linux、Windows和Mac系统，安装Git，可以到Git官方网站直接下载安装程序。

　　什么是版本库？版本库又名仓库，英文名repository,你可以简单的理解一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改，删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻还可以将文件”还原”。

　　远程仓库（Remote）：

　　也叫作资源库，是远程机器上的代码库，用于做不同版本库文件交换更新。如Gitlab，GitHub，gitee。

　　本地库（Repository）：

　　是用户在本地创建的目录，拥有远程库的一个快照，由工作区和版本库构成。

　　工作区（Workspace）：

　　本地库的根目录中除.git目录以外的内容，存储内容的实际文件。

　　暂存区（stage/Index）：

　　也叫做缓存区，暂存信息存放在.git目录"下的index文件（.git/index）中，用于临时保存内容的修改；

　　版本库（.git目录）

　　是本地库的根目录中的一个隐藏目录.git，用于记录版本信息，Git进行版本控制所需要的文件，则都放在.git文件夹中；

　　分支（Branch）：

　　本地库中默认创建一个主（master）分支，分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。

　　本地库和远程库的关系

　　开发人员通过Git命令来管理代码，最常用的6个命令如下图所示：

　　从一般开发者的角度来看，使用Git的工作流程是：

　　克隆远程库：从远程库上克隆完整的Git仓库（包括代码和版本信息）到本地；

　　在本地库上修改代码：在本地库上根据不同的开发目的，创建分支，修改代码；

　　提交到分支：在本地分支上提交代码；

　　把修改合并到本地主分支：在本地库上提交更新，也就是说，把修改合并到本地主分支；

　　把远程库合并到本地主分支：把远程库上的最新代码fetch下来，跟本地主分支合并，如果存在冲突，那么解决冲突。

　　把本地主分支提交到远程库：生成补丁（patch），把补丁发送给远程库。

　　创建一个版本库也非常简单，如下我是D盘下目录下新建一个testGit版本库。

　　右键通过命令行的方式打开窗口

　　pwd 命令是用于显示当前的目录。

　　通过命令 git init 把这个目录变成git可以管理的仓库，如下

　　Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

　　这时候你当前testgit目录下会多了一个.git的目录，这个目录是Git来跟踪管理版本的，没事千万不要手动乱改这个目录里面的文件，否则，会把git仓库给破坏了。.git里面内容如下：

　　首先要明确下，所有的版本控制系统，只能跟踪文本文件的改动，比如txt文件，网页，所有程序的代码等，Git也不列外，版本控制系统可以告诉你每次的改动，但是图片，视频这些二进制文件，虽能也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是知道图片从1kb变成2kb，但是到底改了啥，版本控制也不知道。

　　创建文件readme.txt, 此刻文件在工作区（WorkSpace）

　　通过git status可以查看文件追踪的情况

　　使用命令 git add readme.txt添加到暂存区里面去。

　　我们发现添加到暂存区的时候会有警告出现。不过没关系，是换行符的警告。

　　我们可以看到readme.txt目前处于暂存区。

　　如果要提交多个文件

　　我们可以在add后面指定文件的列表

　　git add test2.txt test3.txt

　　如果想要添加工作区所有文件到暂存区

　　git add .

　　我们可以通过提示的话来撤销回工作区

　　git rm --cached readme.txt

　　提交文件到主分支

　　git commit -m 'first commit'

　　现在我们已经提交了一个readme.txt文件了，我们下面可以通过命令git status来查看是否还有文件未提交

　　注意：注释是必须要写的。

　　修改文件，在文件中加入一行。查看git的状态

　　我们发现文件进入到工作区

　　最新版本改成了

　　此刻我们发现界面上有两个提示：

　　提交修改后的文件

　　通过checkout上一个版本的文件来覆盖修改后的文件

　　git checkout -- readme.txt

　　注意：--后面要有空格

　　现在我已经对readme.txt文件做了三次修改了，那么我现在想查看下历史记录，如何查呢？我们现在可以使用命令 git log 演示如下所演示

　　git log

　　git log命令显示从最近到最远的显示日志，我们可以看到最近三次提交

　　如果嫌上面显示的信息太多的话，我们可以使用命令 git log –pretty=oneline 演示如下：

　　现在我想使用版本回退操作，我想把当前的版本回退到上一个版本，要使用什么命令呢？可以使用如下2种命令，第一种是：git reset --hard HEAD^ 那么如果要回退到上上个版本只需把HEAD^ 改成 HEAD^^ 以此类推。那如果要回退到前100个版本的话，使用上面的方法肯定不方便，我们可以使用下面的简便命令操作：git reset --hard HEAD~100 即可。未回退之前的readme.txt内容如下：

　　我们查看文件的内容：

　　查看提交日志：

　　同时我们也可以通过sha1的前四位来做回退

　　git reset –heard sha1

　　回退撤销

　　我们看到增加update 2内容我们没有看到了，但是现在我想回退到最新的版本，如：有update 2的内容要如何恢复呢？我们可以通过版本号回退，使用命令方法如下：

　　git reset --hard 版本号，但是现在的问题假如我已经关掉过一次命令行或者update 2内容的版本号我并不知道呢？要如何知道增加update 2内容的版本号呢？可以通过如下命令即可获取到版本号：git reflog 演示如下：

　　git reflog

　　通过上面的显示我们可以知道，增加内容update 2的版本号是 8d95a43.我们现在可以命令

　　git reset --hard 8d95a43

　　查看撤销后的结果。

　　添加并且提交了多个文件

　　一般情况下，可以直接在文件目录中把文件删了，或者使用如上rm命令：rm b.txt ，如果我想彻底从版本库中删掉了此文件的话，可以再执行commit命令提交掉。

　　git rm test.txt

　　我们发现删除的文件直接进入暂存区（此刻需要注意，如果使用rm删除不在暂存区，需要git add才会进入暂存区。如果进入暂存区可以退回工作区，使用下面命令 git reset HEAD test.txt

　　提交之后文件被删除。

　　在git中，我们使用git config 命令用来配置git的配置文件，git配置级别主要有以下3类：

　　1、仓库级别 local 【优先级最高】

　　2、用户级别 global【优先级次之】

　　3、系统级别 system【优先级最低】

　　git 仓库级别对应的配置文件是当前仓库下的.git/config

　　git 用户级别对应的配置文件是用户宿主目录下的~/.gitconfig

　　git系统级别对应的配置文件是git安装目录下的 /etc/gitconfig

　　当然我们可以在cmd命令提示符中输入以下查看配置信息

　　git config --local -l

　　git config --global -l

　　git config --system -l

　　演示修改用户名和邮箱：

　　git config --global user.name "renliang"

　　git config --global user.email "renliang@126.com"

　　注意不要手动修改每个级别的配置文件，要用命令。

　　对于git来说，配置文件的权重是仓库>全局>系统。Git会使用这一系列的配置文件来存储你定义的偏好，它首先会查找/etc/gitconfig文件（系统级），该文件含有对系统上所有用户及他们所拥有的仓库都生效的配置值。接下来Git会查找每个用户的~/.gitconfig文件（全局级）。最后Git会查找由用户定义的各个库中Git目录下的配置文件.git/config（仓库级），该文件中的值只对当前所属仓库有效。

　　在项目中，我们可能一起提交多个文件

　　· git add -A 提交所有变化

　　· git add -u 提交被修改(modified)和被删除(deleted)文件，不包括新文件(new)

　　· git add . 提交新文件(new)和被修改(modified)文件，不包括被删除(deleted)文件

　　在使用git的过程中，一般我们总会有些文件无需纳入git的管理，也不希望它们总出现在未跟踪文件列表，这些文件通常是日志文件、临时文件、编译产生的中间文件、工具自动生成的文件等等。

　　此时我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件模式，Git会根据这些模式规则来判断是否将文件添加到版本控制中。

　　注意：在windows下可以创建文件名为.gitignore.，保存之后系统会自动重命名为 .gitignore

　　? （1）所有空行或者以注释符号＃开头的行都会被 Git 忽略

　　? （2）可以使用标准的 glob 模式匹配

　　? （3）匹配模式最后跟斜杠(/)说明要忽略的是目录

　　? （4）要忽略指定模式以外的文件或目录，可以在模式前加上感叹号(!)进行取反

　　所谓的 glob 模式是指 shell 所使用的简化了的正则表达式，匹配规则如下：

　　"*"：星号匹配零个或多个任意字符

　　[]：匹配任何一个列在方括号中的字符，如[ab]匹配a或者匹配b

　　"?"：问号匹配一个任意字符

　　[n-m]：匹配所有在这两个字符范围内的字符，如[0-9]表示匹配所有0到9的数字

　　匹配示例

　　logs/：忽略当前路径下的logs目录，包含logs下的所有子目录和文件

　　/logs.txt：忽略根目录下的logs.txt文件

　　*.class：忽略所有后缀为.class的文件

　　!/classes/a.class：不忽略classes目录下的a.class文件

　　tmp/*.txt：只忽略tmp目录下的.txt文件

　　**/foo：可以忽略/foo, a/foo, a/b/foo等

　　1. 在需要创建 .gitignore 文件的文件夹, 右键选择Git Bash 进入命令行，进入项目所在目录。

　　2. 输入 touch .gitignore 在文件夹就生成了一个“.gitignore”文件

　　3.然后用编辑器打开这个文件进行编辑就行了。

　　4.然后就写规则来操作要忽略的文件了。

　　.gitignore内容

　　创建两个文件

　　查看状态我们发现testclass.class不在工作区

　　提交也不会进入暂存区

　　除了可以在项目中定义.gitignore文件外，还可以设置全局的.gitignore文件来管理所有Git项目的行为。

　　这种方式在不同的项目开发者之间是不共享的，是属于项目之上Git应用级别的行为。

　　可以在任意目录下创建相应的.gitignore文件，然后再使用以下命令配置Git

　　git config --global core.excludesfile ~/.gitignore

　　.gitignore只能忽略那些原来没有被track的文件，如果某些文件已经被纳入了版本管理中，则修改.gitignore是无效的。所以一定要养成在项目开始就创建.gitignore文件的习惯。

　　接下来我想看下readme.txt文件到底改了什么内容，如何查看呢？可以使用如下命令：

　　git diff readme.txt

　　diff里面a表示前面那个变量，b表示第二个变量

　　HEAD commit版本

　　Index staged版本

　　工作目录 vs 暂存区

　　$ git diff <filename>

　　意义：查看文件在工作目录与暂存区的差别。如果还没 add 进暂存区，则查看文件自身修改前后的差别。也可查看和另一分支的区别。

　　$ git diff <branch> <filename>

　　暂存区 vs Git仓库

　　git diff --cached <filename>

　　意义：表示查看已经 add 进暂存区但是尚未 commit 的内容同最新一次 commit 时的内容的差异。也可以指定仓库版本：

　　git diff --cached <commit> <filename>

　　工作目录 vs Git仓库

　　git diff <commit> <filename>

　　意义：查看工作目录同Git仓库指定 commit 的内容的差异。

　　<commit>=HEAD 时：查看工作目录同最近一次 commit 的内容的差异。

　　Git仓库 vs Git仓库

　　git diff <commit> <commit>

　　意义：Git仓库任意两次 commit 之间的差别。

　　以上命令可以不指定 <filename>，则对全部文件操作。

　　以上命令涉及和 Git仓库对比的，均可指定 commit 的版本。

　　HEAD 最近一次 commit

　　HEAD^ 上次提交

　　HEAD~100 上100次提交

　　Git 的默认分支就是 master。你所作的commit会在master分支上自动移动。在多次提交操作之后，master分支指向最后那个commit object（提交对象链）。

　　Git 的 “master” 分支并特殊，跟其它分支没有区别。之所以几乎每一个仓库都有 master 分支，是因为 git init 命令默认创建它。

　　但很多时候听别人说master分支，往往有一种这个分支是稳定、无bug的分支。而develop往往预示这新功能，不稳定的分支。这和分支策略有关，但本质上这两个分支没区别。

　　通过git branch来查看和创建分支。

　　创建标签记在HEAD指针所指向的提交点创建tag（就是当前所在分支）

　　git branch dev

　　分支切换到dev

　　git checkout dev

　　创建分支与合并分支同时完成

　　git checkout -b dev2

　　这是我们在dev2分支创建一个文件A.txt并且提交。我们发现在dev2分支可以看到这个文件，当我们切换会master时候无法看到这个文件。

　　不能删除自己所在的分支

　　我们可以切换到master删除一个合并后的或者没有发生变化的分支

　　如果一个分支发生了变化不能删除

　　我们发现dev2发生了变化，同时没有合并不能删除。如果要强制删除可以

　　git branch -D dev2

　　我们继续基于上面的例子，切换到master上做dev2 的合并

　　我们发现master分支上也添加了A.txt这个文件

　　如果修改的是同一个文件也可以做同样的合并，让我们切换到dev2分支修改A.txt中的内容。在A.txt中添加了一行World

　　我们切换会master分支的时候发现提示了A.txt的变动。通过合并发现master分支上也合并了dev2修改的内容，合并之后dev2就删除就被允许了。

　　master指向的是提交

　　HEAD是指向当前的分支，当前在哪个分支就指向哪个分支

　　第二张图上我们可以看到创建了dev的分支，当我们切换到dev分支的时候HEAD就会指向dev

　　当我们进入.git文件夹查看HEAD的内容的时候可以看到，所处分支不同内部的文件指向就不同。

　　master分支

　　dev2分支

　　git的分支与svn不同，svn是整体拷贝一份分支，git用的是指针。

　　如果dev发生修改提交，dev的版本就会向后移动。

　　在master分支上如果合并就会出现下面的图

　　我们在dev2分支里面修改A.txt文件添加一行 update by dev2后提交

　　我们在master分支里面修改A.txt文件同时添加一行 update by master后提交

　　合并时候我们发现出现冲突

　　<<<<<<<<<<<HEAD是当前指向的分支所修改

　　>>>>>>>>>>dev2是dev2分支修改

　　我们需要手工合并。修改后报了master的内容

　　我们可以通过图形来查看冲突的提交日志。

　　git log --graph

　　1 当正在dev分支上开发某个项目，这时项目中出现一个bug，需要紧急修复，但是正在开发的内容只是完成一半，还不想提交，这时可以用git stash命令将修改的内容保存至堆栈区，然后顺利切换到hotfix分支进行bug修复，修复完成后，再次切回到dev分支，从堆栈中恢复刚刚保存的内容。

　　2 由于疏忽，本应该在dev分支开发的内容，却在master上进行了开发，需要重新切回到dev分支上进行开发，可以用git stash将内容保存至堆栈中，切回到dev分支后，再次恢复内容即可。

　　总的来说，git stash命令的作用就是将目前还不想提交的但是已经修改的内容进行保存至堆栈中，后续可以在某个分支上恢复出堆栈中的内容。这也就是说，stash中的内容不仅仅可以恢复到原先开发的分支，也可以恢复到其他任意指定的分支上。git stash作用的范围包括工作区和暂存区中的内容，也就是说没有提交的内容都会保存至堆栈中。

　　我们在master分支修改A.txt添加一行

　　这时我们要切换dev2分支

　　我们发现会提示错误，git建议我们先提交或者stash修改的内容再切换

　　我们执行git stash

　　会先把修改的内容做保存然后我们就可以切换到其他的分支

　　列出stash保存的所有修改

　　我们切换回master分支执行，我们能看到上次保存的操作

　　git stash list

　　我们同样也可以再次修改文件去做stash，这样就会产生2条保存的记录

　　我们可以将stash过的修改恢复出来。通过pop取出最近的恢复并且删除stash中的修改

　　git stash pop

　　如果两次pop由于提一次没有做提交则会报错，所以我们应该把第一次pop的提交，在pop第二次的。

　　git 的分支整体预览图如下：

　　从上图可以看到主要包含下面几个分支：

　　master：git默认主分支（这里不作操作）。

　　stable：稳定分支，替代master，主要用来版本发布。

　　develop：日常开发分支，该分支正常保存了开发的最新代码。

　　feature：具体的功能开发分支，只与 develop 分支交互。

　　release：release 分支可以认为是 stable分支的未测试版。比如说某一期的功能全部开发完成，那么就将 develop 分支合并到 release分支，测试没有问题并且到了发布日期就合并到 stable分支，进行发布。

　　bugfix：线上 bug 修复分支。

　　因为master分支我们不作操作，所以针对stable和develop这两个主分支来讲解。

　　stable分支：用来发布，管理着多个稳定的版本。

　　develop分支：就是我们日常开发的分支。

　　使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题后，则将 develop 分支的代码合并到 stable分支并发布。

　　通过这些分支，我们可以做到：团队成员之间并行开发，增加新功能更加容易，可以同时进行开发和版本发布、线上bug修复等。

　　feature 分支用来开发具体的功能，一般基于develop分支，最后完成功能后再合并到develop分支。

　　比如，目前我们针对develop分支来做功能开发，在开发的过程中会有紧急需求需要开发，且在本次版本发布时间之前要能测试完成。我们可以基于之前稳定版本另开一个feature分支来做紧急需求的开发，发布并进行测试，完成之后再合并到develop分支上。

　　release分支作为预发布分支，release 分支从 develop 分支 fork 出来，最终会合并到 develop 分支和 stable 分支，合并到 stable分支上就是可以发布的代码了。

　　为什么我从develop分支fork出来，还要合并到develop分支中呢？因为我们在release分支上难免会有bug产生，修复bug也是在release分支上，所以必须要合并到develop分支。

　　bugfix 分支用来修复线上bug。当线上代码出现 bug 时，我们基于 stable 分支开一个bugfix分支，修复 bug之后再将 bugfix分支合并到stable分支并进行发布，同时develop 分支作为最新最全的代码分支，bugfix分支也需要合并到 develop 分支上去。

　　GitHub是一个面向开源及私有软件项目的托管平台，因为只支持git 作为唯一的版本库格式进行托管，故名GitHub。

　　GitHub官网：https://github.com/

　　验证邮箱

　　邮箱验证完毕，创建仓库

　　点击创建仓库，私有仓库目前也公开了，不过只能最多三个协作者。

　　删除之前的仓库中的所有内容，从新建库，同时创建一个A.txt文件。

　　为了本地演示多个用户操作，我们把仓库local的级别的用户设置一下

　　$ git config --local user.name '鲁智深'

　　$ git config --local user.mail 'luzhishen@126.com'

　　github已创建空仓https://github.com/txjava-teach/txjava-code.git，本地库要上传并与之关联：

　　添加后，远程库的名字就是origin，这是Git默认的名字，也可以改成别的，但是origin这个名字?看就知道是远程库。下一步，就可以把本地库的所有内容推送到远程库上:

　　然后推送本地库的文件。

　　第?次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master 分支关联起来

　　只要本地作了提交，就可以通过命令:

　　把本地master分支的最新修改推送至GitHub

　　查看远程仓库

　　origin相当于远程仓库的链接别名

　　查看远程仓库明细

　　上面命令展示了origin的详细信息，

　　远程拉取的url

　　push推送的url

　　头指针指向的master分支，同时远程分支是被追踪的状态

　　本地master分支被配置成git pull会拉取并且合并远程master

　　本地master分支配置成git push推送远程master

　　origin master关联的是远程的master分支，用于追踪远程分支的状态

　　查看远程分支

　　我们加上参数v可以查看本地分支和远程分支的最后提交

　　我们修改A.txt文件

　　我们通过git status可以看到我们master分支和远程分支origin/master都是最新的。

　　此时我们提交我们的修改后在查看git status，我们可以发现我们的本地master分支领先了1次提交。

　　从分支的详细信息中我们可以看到远程分支的提交版本和master的提交版本不同，本地领先了。

　　此刻我们把本次修改推送到远程，远程和本地便保持了版本的同步

　　我们可以把远程项目克隆到本地形成一个本地的仓库

　　我们可以发现克隆下来的仓库和远程仓库的名字一致

　　进入仓库可以看到.git的配置文件和远程代码

　　.git中的配置可以看到目前的分支为master，远程别名是origin，关联合并的是远程分支的master

　　注意：我们也可以克隆远程项目自己定义仓库名字

　　克隆远程仓库命名testGit1.

　　指定本地仓库级别的用户名和邮箱

　　在testGit中通过鲁智深添加文件并且推送到远程

　　在testGit1仓库中林冲查看远程状态发现已经过期。

　　此时林冲应该从远程仓库来更新拉取

　　fast-forward表示不需要手工处理冲突直接合并。

　　当两个人修改同一个文件的同一行的时候就会发生冲突

　　我们使用鲁智深修改B.txt内容:

　　提交并且推送到远程

　　此刻林冲也修改B.txt内容：

　　我们提交并且推送远程的时候发现出现冲突，推送失败

　　此刻git要求我们先拉取更新

　　我提示中我们发现拉取成功，但是自动合并失败。git建议我们修改冲突后提交。

　　我们可以修改冲突，此时和svn是一样的。我们保留冲突的

　　推送到远程

　　搞定

　　创建develop分支

　　我们发现git push无法把develop推送到远程。

　　执行下面的命令，这就是把本地的分支推送到远程分支。

　　我们可以看到远程分支已经推送。

　　同时本地也关联了远程develop分支

　　除此之外我们可以使用下面命令完成远程分支推送

　　我们创建分支，并且把分支推送到远程

　　分支查看

　　由于鲁智深已经推送，我们使用林冲的账户来拉取，我们可以看到新建立了分支

　　但是我们发现有远程分支，但是没有本地的develop分支。

　　这时我们可以创建本地的develop分支，此刻我们也可以修改本地分支的名字

　　我们已经创建分支并且切换到develop上，而且该分支和远程分支develop关联。

　　查看

　　我们还可以使用另一种方式本地分支的追踪，但是必须要先git pull

　　我们在鲁智深仓库删除Feature分支，删除之后远程的Feature分支关联还在。

　　我们也可以删除对应的远程分支

　　当我们通过另一个用户来查看本地对应的远程分支的时候可以看到远程分支的变化。

　　查看origin远程对应的分支

　　新建标签，标签有两种:轻量级标签(lightweight) 与带有附注标签(annotated)

　　创建一个轻量级标签。

　　创建标签记在HEAD指针所指向的提交点创建tag（就是当前所在分支）

　　git tag v1.0.1

　　创建一个带有附注的标签

　　git tag -a v1.0.2 -m 'release version'

　　标签不依赖于分支。

　　.删除标签

　　git tag -d tag_ name

　　我们前面已经介绍过标签的创建

　　我们创建3个标签

　　把多个标签推送到远程

　　GitHub上可以看到标签已经推送，标签代码可以下载。

　　可以把所有标签推送到远程。

　　我们通过林冲用户来拉取

　　远程标签被删除

　　同时也可以

　　远程标签删除后本地标签不会消失，我们可以手动删除本地标签

　　我们创建tx_master_v1.0标签并且推送到远程

　　然后我们通过此标签来检出分支

　　git checkout -b myfeature tx_master_v1.0

　　但是次分支这是本地分支，我们可以推送到远程

　　在仓库路径下输入gitk

　　我们在界面上可以看到提交的流程。包括分支的合并。同时可以做分支管理和标签管理

　　在命令行中输入git gui

　　我在testGit仓库内创建一个C.txt, 我们发现文件会加入工作区

　　我们也可以点击C.txt加入暂存区

　　同时可以通过commit把暂存区提交到本地库

　　然后我们可以通过push把本地仓库的文件推送到远程。

　　我们同时可以根据上面的菜单来操作我们的仓库。有了命令的操作再来看界面简单的一匹。

　　打开IDEA进入设置界面（可以直接点击工具栏上的，也可以通过快捷键 Ctrl + Alt + S ），搜索git，如下图是我设置好的：

　　我们可以看到Git是在Version Control选项里

　　Path to Git executable就是我们的本地Git安装路径中bin目录下的git.exe，选择好路径后点击Test按钮，如果正确安装且路径正确，那么会弹出如下对话框，表示配置成功：

　　创建git本地库，克隆GitHub上的仓库

　　通过idea引入代码

　　我们可以发现当前代码没有在idea的git上关联，选中添加即可。

　　此时idea和我们git本地库就已经关联上了。

　　此刻我们就可以开发了。

　　环境说明

　　系统版本 CentOS 7.2 x86_64

　　软件版本 gitlab-ce-10.8.4

　　GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用。

　　Gitlab的rpm包集成了它需要的软件，简化了安装步骤，所以直接安装rpm包即可，rpm包的获取从官方网站或者国内镜像源（如：清华https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/）获取，gitlab又分为社区版和企业版（收费），这里部署的是社区版本10.8.4

　　安装成功，但是需要配置，安装完成后出现上面的提示，按照提示修改配置文件中的url地址为本地服务器的地址

　　默认的全英文界面对于英文水平低的来讲当然用着很不舒服，于是便需要来一波操作进行汉化，英文好的请自觉忽略

　　GitLab中文社区的项目，v7-v8.8是由Larry Li发起的"GitLab中文社区版项目"（https://gitlab.com/larryli/gitlab），从v8.9之后由@xhang开始继续汉化项目（https://gitlab.com/xhang/gitlab）

　　[root@gitlab tools]# pwd

　　/service/tools

　　[root@gitlab tools]# mkdir /backup

　　[root@gitlab tools]# cp /opt/gitlab/embedded/service/gitlab-rails/* /backup #防止汉化失败，备份原文件

　　[root@gitlab tools]# git clone https://gitlab.com/xhang/gitlab.git #下载最新的汉化包

　　汉化包的版本更新速度不得而知，所以尽量不要安装最新版本的gitlab。如果是要下载老版本的汉化包，需要加上老版本的分支，如果想下载10.0.2，可以运行如下语句

　　[root@gitlab tools]# git clone https://gitlab.com/xhang/gitlab.git -b v10.0.2-zh

　　[root@gitlab tools]# ls #git下来的文件为gitlab

　　gitlab gitlab-ce-10.8.4-ce.0.el7.x86_64.rpm

　　[root@gitlab tools]# cp -rf gitlab/* /opt/gitlab/embedded/service/gitlab-rails/ #拷贝文件

　　检验汉化

　　[root@gitlab tools]# gitlab-ctl reconfigure #加载配置（第一次执行此命令会启动，若只启动执行start）

　　启动时查看控制台输出，需要等待一段时间，无输出后启动完成，执行free -m命令查看到当前的内存使用情况为

　　[root@gitlab tools]# free -m

　　total used free shared buff/cache available

　　Mem: 2993 2123 156 62 713 597

　　Swap: 2047 0 2047

　　[root@gitlab tools]# netstat -lntup

　　Active Internet connections (only servers)

　　Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

　　tcp 0 0 127.0.0.1:9100 0.0.0.0:* LISTEN 4319/node_exporter

　　tcp 0 0 127.0.0.1:9229 0.0.0.0:* LISTEN 4628/gitlab-workhor

　　tcp 0 0 127.0.0.1:9168 0.0.0.0:* LISTEN 4659/ruby

　　tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4191/unicorn master

　　tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 4223/nginx: master

　　tcp 0 0 127.0.0.1:8082 0.0.0.0:* LISTEN 4196/sidekiq 5.0.5

　　tcp 0 0 127.0.0.1:9236 0.0.0.0:* LISTEN 4642/gitaly

　　tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1439/sshd

　　tcp 0 0 0.0.0.0:8060 0.0.0.0:* LISTEN 4223/nginx: master

　　tcp 0 0 0.0.0.0:6783 0.0.0.0:* LISTEN 4696/alertmanager

　　tcp 0 0 127.0.0.1:9121 0.0.0.0:* LISTEN 4425/redis_exporter

　　tcp 0 0 127.0.0.1:9090 0.0.0.0:* LISTEN 4681/prometheus

　　tcp 0 0 127.0.0.1:9187 0.0.0.0:* LISTEN 4710/postgres_expor

　　tcp 0 0 127.0.0.1:9093 0.0.0.0:* LISTEN 4696/alertmanager

　　tcp6 0 0 ::1:9168 :::* LISTEN 4659/ruby

　　tcp6 0 0 :::22 :::* LISTEN 1439/sshd

　　GitLab终端常用命令

　　gitlab-ctl start #启动所有 gitlab 组件；

　　gitlab-ctl stop #停止所有 gitlab 组件；

　　gitlab-ctl restart #重启所有 gitlab 组件；

　　gitlab-ctl status #查看服务状态；

　　gitlab-ctl reconfigure #启动服务；

　　vim /etc/gitlab/gitlab.rb #修改默认的配置文件；

　　gitlab-rake gitlab:check SANITIZE=true --trace #检查gitlab；

　　gitlab-ctl tail #查看日志；

　　修改密码后进行登录，登录的用户名为root

　　3.1 使用前可选操作

　　3.1.1 修改web端口

　　如果80和8080端口被占用可以修改

　　[root@gitlab tools]# vim /var/opt/gitlab/gitlab-rails/etc/unicorn.rb

　　listen "127.0.0.1:8080", :tcp_nopush => true

　　修改nginx端口

　　[root@gitlab tools]# vim /var/opt/gitlab/nginx/conf/gitlab-http.conf

　　server {

　　listen *:80;

　　3.1.2 修改Prometheus端口

　　[root@gitlab tools]# vim /etc/gitlab/gitlab.rb

　　external_url 'http://10.0.0.5:port' #根据需要修改端口

　　修改后需要重新加载配置并启动

　　访问：http://192.168.0.108/

　　重置密码

　　创建空白项目

　　选择项目路径，输入项目名称，项目描述，选择项目等级（私人的，内部的，公开的），

　　我们能看到Gitlab给我们的使用当前项目的教程。学过git和GitHub，想必我这些已经都会了。

　　我们发现上面有一行黄色的提示，要求我们配置ssh

　　首先生成公钥：

　　[root@gitlab-client ~]# ssh-keygen

　　[root@gitlab-client ~]# cat .ssh/id_rsa.pub #查看公钥

　　将上面的公钥文件复制到gitlab中

　　我们在远程机器生成私钥

　　生成新的SSH密钥： ssh-keygen -t rsa -C "your_email@address"

　　此命令将提示您用于存储密钥对和密码的位置和文件名。当提示输入位置和文件名时，只需按Enter键即可使用默认值。如果使用其他名称，则不会自动使用该密钥。

　　在C盘下 .ssh 文件夹中会生成 id_rsa 和 id_rsa.pub 两个文件，其中 id_rsa.pub 里面是以ssh-rsa开头并以您的用户名和主机结尾的完整密钥。将密钥复制粘贴到 profile settings中 SSH keys 选项卡下，add an ssh key ，保存。

　　步骤：

　　在window系统打开命令行输入

　　ssh-keygen -t rsa -C "renliangjava@163.com"

　　打开id_rsa.pub，把所有内容复制

　　到Gitlab中将密钥复制粘贴到 profile settings中 SSH keys 选项卡下，add an ssh key ，保存。跟添加公钥的步骤完全一致

　　随机我们配置本地用户信息和本地库创建本地git库

　　此刻我们可以看到远程仓库里面文件以及推送。

　　随机我们将Spring源代码上传Gitlab

　　此时我可以通过另一个git本地库克隆

　　刷新Gitlab我们可以看到变化。

　　五万字长篇-java虚拟机看这篇文章就够了（上）

　　gradle架构课程学习总结

　　举报/反馈