高级架构二 Git基础到高级

一 Git仓库的基本概念和流程

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

1.1 Git仓库的基本概念

1. 远程仓库（Remote）：
   也叫作资源库，是远程机器上的代码库，用于做不同版本库文件交换更新。如Gitlab，GitHub，gitee。
2. 本地库（Repository）：
   是用户在本地创建的目录，拥有远程库的一个快照，由工作区和版本库构成。

• 工作区（Workspace）：
  本地库的根目录中除.git目录以外的内容，存储内容的实际文件。
• 暂存区（stage/Index）：
  也叫做缓存区，暂存信息存放在.git目录"下的index文件（.git/index）中，用于临时保存内容的修改；
• 版本库（.git目录）
  是本地库的根目录中的一个隐藏目录.git，用于记录版本信息，Git进行版本控制所需要的文件，则都放在.git文件夹中；

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

本地库和远程库的关系

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

1.2 Git仓库的工作流程

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

1. 克隆远程库：从远程库上克隆完整的Git仓库（包括代码和版本信息）到本地；
2. 在本地库上修改代码：在本地库上根据不同的开发目的，创建分支，修改代码；
3. 提交到分支：在本地分支上提交代码；
4. 把修改合并到本地主分支：在本地库上提交更新，也就是说，把修改合并到本地主分支；
5. 把远程库合并到本地主分支：把远程库上的最新代码fetch下来，跟本地主分支合并，如果存在冲突，那么解决冲突。
6. 把本地主分支提交到远程库：生成补丁（patch），把补丁发送给远程库。

二 Git命令

2.1 创建版本库

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

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

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

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

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

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

2.2 添加文件和修改提交文件

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

1. 创建文件readme.txt, 此刻文件在工作区（WorkSpace）
   
   通过git status可以查看文件追踪的情况
   
2. 使用命令 git add readme.txt添加到暂存区里面去。
   
   我们发现添加到暂存区的时候会有警告出现。不过没关系，是换行符的警告。
   我们可以看到readme.txt目前处于暂存区。

如果要提交多个文件

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

git add test2.txt test3.txt

如果想要添加工作区所有文件到暂存区（注意后边有个点）

git add .

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

git rm --cached readme.txt

3. 提交文件到主分支

git commit -m 'first commit'

现在我们已经提交了一个readme.txt文件了，我们下面可以通过命令git status来查看是否还有文件未提交，注意：注释是必须要写的。

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

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

最新版本改成了

git restore test3.txt

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

（1）提交修改后的文件

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

git checkout -- readme.txt

注意 ：--后面要有空格

2.3 版本回退

2.3.1 日志查看

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

git log

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

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

2.3.2 版本回退和撤销

1. 版本回退
   现在我想使用版本回退操作，我想把当前的版本回退到上一个版本，要使用什么命令呢？可以使用如下2种命令，第一种是：git reset --hard HEAD^ ，那么如果要回退到上上个版本只需把HEAD^ 改成 HEAD^^ 以此类推。那如果要回退到前100个版本的话，使用上面的方法肯定不方便，我们可以使用下面的简便命令操作：git reset --hard HEAD~100 即可。未回退之前的readme.txt内容如下：
   
   我们查看文件的内容：
   
   查看提交日志：
   
   同时我们也可以通过sha1的前四位来做回退

git reset --heard sha1

2. 回退撤销
   我们看到 增加update 2内容我们没有看到了，但是现在我想回退到最新的版本，如：有update 2的内容要如何恢复呢？我们可以通过版本号回退，使用命令方法如下：
   git reset --hard 版本号 ，但是现在的问题假如我已经关掉过一次命令行或者update 2内容的版本号我并不知道呢？要如何知道增加update 2内容的版本号呢？可以通过如下命令即可获取到版本号：git reflog 演示如下：
   
   通过上面的显示我们可以知道，增加内容update 2的版本号是 8d95a43.我们现在可以命令

git reset --hard 8d95a43

查看撤销后的结果。

2.4 删除文件

添加并且提交了多个文件

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

git rm test.txt

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

2.5 Git配置信息Config

2.5.1 Config概述

在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

2.5.2 Config修改

演示修改用户名和邮箱：

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

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

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

三 .gitignore文件

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

• git add -A 提交所有变化
• git add -u 提交被修改(modified)和被删除(deleted)文件，不包括新文件(new)
• git add . 提交新文件(new)和被修改(modified)文件，不包括被删除(deleted)文件

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

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

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

3.1 格式规范

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

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

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

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

3.2 glob模式

所谓的 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等

3.3 案例使用

1. 在需要创建 .gitignore 文件的文件夹, 右键选择Git Bash 进入命令行，进入项目所在目录。
2. 输入 touch .gitignore 在文件夹就生成了一个".gitignore"文件
3. 然后用编辑器打开这个文件进行编辑就行了。
4. 然后就写规则来操作要忽略的文件了。

.gitignore内容

创建两个文件

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

提交也不会进入暂存区

3.4定义全局的.gitignore

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

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

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

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

3.5 .gitignore规则不生效

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

3.6 java开发通用模板

#java
*.class

#package file
*.war
*.ear
*.zip
*.tar.gz
*.rar
#maven ignore
target/
build/

#eclipse ignore
.settings/
.project
.classpatch

#Intellij idea
.idea/
/idea/
*.ipr
*.iml
*.iws

# temp file
*.log
*.cache
*.diff
*.patch
*.tmp

# system ignore
.DS_Store
Thumbs.db

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

3.7 diff命令

git diff readme.txt

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

HEAD commit版本

Index staged版本

1. 工作目录 vs 暂存区

$ git diff <filename>

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

$ git diff <branch> <filename>

2. 暂存区 vs Git仓库

git diff --cached <filename>

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

git diff --cached <commit> <filename>

3. 工作目录 vs Git仓库

git diff <commit> <filename>

意义：查看工作目录同Git仓库指定 commit 的内容的差异。
<commit>=HEAD 时：查看工作目录同最近一次 commit 的内容的差异。

4. Git仓库 vs Git仓库

git diff <commit> <commit>

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

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

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

HEAD 最近一次 commit

HEAD^ 上次提交

HEAD~100 上100次提交

四 Git分支管理

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

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

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

4.1 分支创建

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

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

git branch dev

分支切换到dev

git checkout dev

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

git checkout -b dev2

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

4.2 分支删除

1. 不能删除自己所在的分支
   
   我们可以切换到master删除一个合并后的或者没有发生变化的分支
   
2. 如果一个分支发生了变化不能删除
   
   我们发现dev2发生了变化，同时没有合并不能删除。如果要强制删除可以

git branch -D dev2

4.3 分支合并

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

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

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

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

4.4 分支本质

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

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

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

master分支

dev2分支

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

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

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

4.5 分支的冲突

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

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

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

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

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

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

git log --graph

五 Git stash

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 修复分支。

6.1 主分支

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

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

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

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

6.2 辅助分支

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

6.2.1 Feature分支

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

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

6.2.2 release分支

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

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

6.2.3 bugfix分支

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

七 推送本地仓库到远程

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

7.1 修改本地仓库用户名

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

$ git config --local user.name '鲁智深'
$ git config --local user.mail 'luzhishen@126.com'

7.2 Push命令

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

git remote add origin https://github.com/txjava-teach/txjava-code.git

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

然后推送本地库的文件。

git push -u origin master

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

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

git push origin master

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

查看远程仓库

git remote show

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

查看远程仓库明细

git remote show origin

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

远程拉取的url

push推送的url

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

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

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

7.3 远程分支查看

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

查看远程分支

git branch -a

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

git branch -av

我们修改A.txt文件

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

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

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

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

八Git多人协作

8.1 项目克隆

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

git clone https://github.com/txjava-teach/txjava-code.git

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

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

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

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

git clone https://github.com/txjava-teach/txjava-code.git testGit2

8.2 多人协作

8.2.1 创建仓库

创建林冲仓库

克隆远程仓库命名testGit1.

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

git config --local user.name '林冲'
git config --local user.email 'linchong@txjava.com'

8.2.2 协作处理

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

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

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

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

8.2.3 冲突处理

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

我们使用鲁智深修改B.txt内容: 拓薪教育1

提交并且推送到远程

此刻林冲也修改B.txt内容：拓薪教育2

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

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

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

我们可以修改冲突，此时和svn是一样的。我们保留林冲的"拓薪教育2"

推送到远程

搞定

8.3 分支推送协作

创建develop分支

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

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

git push --set-upstream origin develop

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

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

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

git push -u origin 分支名

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

分支查看

8.4 分支拉取协作

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

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

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

git checkout -b develop origin/develop

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

查看

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

git checkout --track origin/feature

8.5 远程分支的删除

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

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

git push origin --delete feature

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

查看origin远程对应的分支

git remote prune origin

九 tag标签远程管理

9.1 标签 tag管理

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

创建一个轻量级标签

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

git tag v1.0.1

创建一个带有附注的标签

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

标签不依赖于分支。

删除标签

git tag -d tag_ name

9.2 标签推送

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

我们创建3个标签

把多个标签推送到远程

git push origin 标签1 标签2......

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

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

git push origin --tag

9.3 标签拉取

git pull

我们通过林冲用户来拉取

9.4 删除远程标签

git push origin :refs/tags/标签名

远程标签被删除

同时也可以

git push origin --delete tag 标签1 标签2...

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

9.5 标签检出

git checkout -b <branchName> <tagName>

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

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

git checkout -b myfeature tx_master_v1.0

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

十 GitLab

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

10.1 centos7.x安装gitlab

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

[root@gitlab ~]# mkdir -p /service/tools

[root@gitlab ~]# cd /service/tools/

[root@gitlab tools]# yum localinstall -y gitlab-ce-10.8.4-ce.0.el7.x86_64.rpm            #安装下载好的rpm包
或者
[root@gitlab ~]# rpm -ivh https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-10.8.4-ce.0.el7.x86_64.rpm        #执行rpm -ivh 在线安装

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

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

external_url 'http://192.168.0.108'

[root@gitlab tools]# gitlab-ctl reconfigure        #重新加载配置

[root@gitlab tools]# gitlab-ctl stop        #停止gitlab，进行后面的汉化

[root@gitlab tools]# cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

10.8.4        #查看版本
或
[root@gitlab tools]# rpm -qa gitlab-ce

gitlab-ce-10.8.4-ce.0.el7.x86_64        #查看版本

[root@gitlab tools]# ls /opt/gitlab/    

[root@gitlab tools]# ll /var/opt/gitlab                #相关目录

10.2 汉化

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

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