Git-大合集
Posted 南城诗客^
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Git-大合集相关的知识，希望对你有一定的参考价值。
安装 Git
linux 安装
#yum install git
1
假如多人协作开发，应该在每个使用者的机器上安装 git
源码安装
yum install dh-autoreconf curl-devel expat-devel gettext-devel \\
openssl-devel perl-devel zlib-devel
yum install asciidoc xmlto docbook2X
$ tar -zxf git-2.8.0.tar.gz
$ cd git-2.8.0
$ make configure
$ ./configure --prefix=/usr
$ make install
1.3 初始化版本库
什么是版本库呢？版本库又名仓库，英文名repository，可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。
1.3.1 创建版本库：
首先，选择一个合适的地方，创建一个空目录
$ git init # 初始化，把当前目录变为由 git 管理的版本库
Initialized empty Git repository in /Users/yanshunjun/Desktop/mygithub/.git/
$ ls -a
. .. .git
可以看到在当前目录下会创建一个隐藏的文件夹 .git
轻易不用动它里面的任何文件，因为这个目录是 Git 来跟踪和管理版本库用的，假如你搞坏了，它就会给你点儿颜色看(Git 仓库就会被破坏)。
非空目录其实也是可以创建仓库的，不过不建议这么干。有必要吗！
1.3.2 版本库（Repository）
.git 目录就是 Git 的版本库
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支 master(通常称为主分支)，以及指向 master 的一个指针叫HEAD
分支和指针后面再讲
1.4 工作区、暂存区和 master 分支
Git 和 SVN 不同之一，就是有 工作区、暂存区的概念
* 工作区： 用来平时的开发、编辑文件之用，在你创建的仓库目录下，就是工作区
* 暂存区： 用来暂时存放准备提交到仓库的文档的地方，在 .git 目录下。
* master 分支： 真正用来存放和发布已经完成的代码文件的地方，在 .git 目录下。
1.4.1 三者的关系位置见下图
最初文件在工作区
git add readme.txt 后，文件被添加到暂存区，此时工作区的文件和暂存区的文件一致。
git commit -m “new file readme.txt” 后，在暂存区的所有文件和目录都将后被提交（移动）到分支 master。
而此时，工作区的文件会和当前分支 master 的文件一致，而暂存区没有任何文件，是清洁的。
总结： 一个文件被提交到版本库的基本流程是：
1. 在你的工作区创建编写你的代码文件 readme.txt (当然也包括目录)
2. 用命令 git add readme.txt 将文件 readme.txt 放到暂存区，这个可以多次执行添加
3. 用命令 git commint -m "new file readme.txt" 将暂存区的所有文件和目录一起提交到 master
可以多次添加，一次提交
1.4.2 实操：
$ pwd
/Users/yanshunjun/Desktop/mygithub
$ mkdir study
$ cd study
$ vi readme.txt
$ cd ..
$ git add study # 我这里是把目录一起提交了
$ git commit -m "crete a readme file"
[master (root-commit) 63e4ecd] crete a readme file
1 file changed, 2 insertions(+)
create mode 100644 study/readme.txt
强调一下， git commit 的 -m 参数后面跟的是关于这次提交版本的描述信息。 这个参数不是必须的，但是强烈要求这么干，这样便于以后自己对版本回滚操作，协同开发时，也便于其他人员可以获取到每次提交改动的基本信息
暂存区是Git非常重要的概念，弄明白了暂存区，就弄明白了Git的很多操作到底干了什么。
精简内容
#修改工作区文件
echo 3 > a.txt
#添加工作区当前目录下所有文件的修改到 暂存区
git add .
#提交暂存区的文件到 master 分支
git commit -m "add 3 to a.txt"
#查看目前的提交版本状态
git log --graph --oneline --decorate --all
#输出如下内容 HEAD 表示当前所在的版本
* e9817e5 (HEAD, master) add 3 to a.txt
* 1df67f6 add 2 to a.txt
* 15f0139 add a.txt
#回退版本到 1df67f6
git reset --hard 1df67f6
#验证版本是否切换
git log --graph --oneline --decorate --all
#输出如下内容
* 1df67f6 (HEAD, master) add 2 to a.txt
* 15f0139 add a.txt
#查看当前版本库的所有标签
git tag
#给当前分支所在的提交点 打标签
git tag 标签名称
git tag 1.0
#给历史提交点打标签
git tag 标签名称 commit id
git tag 2.0 23fe3456
#利用 标签切换 版本号
git reset --hard 标签名称
git reset --hard 2.0
删除标签
git tag -d 标签名
1.5 时空穿越
git 支持版本的回滚操作，并且，你可以在之前任何一个版本和当前最新有效提交后的版本之间来回切换。
1.5.1 提交修改
之前，我们知道了如何创建一个新的文件 readmi.txt ，并提交到仓库；现在让我们来修改这个文件，内容变为这样：
Git is a distributed version control system.
Git is free software.
并且再创建一个新的空文件 test.txt 和空文件夹 newdir
bash-3.2$ pwd
/Users/yanshunjun/Desktop/mygithub
bash-3.2$ vi study/readme.txt
bash-3.2$ touch test.txt;mkidr newdir
观察一下仓库的最新变化和状态
bash-3.2$ git status
On branch master
Changes not staged for commit: # 未提交的更改
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: study/readme.txt # 已经修改的文件
Untracked files: # 没有被添加过的文件
(use "git add <file>..." to include in what will be committed)
test.txt
no changes added to commit (use "git add" and/or "git commit -a")
空的目录是不会被 Git 跟踪的，也没这个必要！
可以看看被修改过的文件，到底修改了哪些内容
bash-3.2$ git diff study/readme.txt
diff --git a/study/readme.txt b/study/readme.txt
index 46d49bf..9247db6 100644
--- a/study/readme.txt
+++ b/study/readme.txt
@@ -1,2 +1,2 @@
-Git is a version control system. # 修改前的内容
+Git is a distributed version control system. # 修改后的内容
Git is free software.
(END)
之后一起放到暂存区
bash-3.2$ git add .
. 会把当前目录下需要提交的所有文件和目录放到暂存区
提交前可以再次观察下仓库的状态
bash-3.2$ git status
On branch master
Changes to be committed: # 下面的文件将会被提交
(use "git reset HEAD <file>..." to unstage)
modified: study/readme.txt
new file: test.txt # 第一次被添加后的状态为 new file
提交到仓库
bash-3.2$ git commit -m "add distributed"
[master a34d237] add distributed
2 files changed, 1 insertion(+), 1 deletion(-)
create mode 100644 test.txt
再次观察仓库的状态
bash-3.2$ git status
On branch master
nothing to commit, working tree clean # 不需要提交，工作区是清洁的
1.5.2 回到过去（版本的回滚）
想象一种场景，你把你代码写好，提交到版本库，准备发布 v1.0。但此时，你的老板说要添加一个新的功能。于是你就在原来的代码文件的基础上修改添加，又再次提交到版本库。可老板这时候，又反悔了，说这个功能不能现在添加。那你是不是又要，再次修改呢？有了git 当然不用，此时你就需要版本回滚，滚到原来最初的版本。
让我们来模拟一下
首先把 readme.txt 文件的内容修改成下面的样子
Git is a distributed version control system.
Git is free software distributed under the GPL.
然后提交修改后的文件
bash-3.2$ vi study/readme.txt
bash-3.2$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: study/readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
bash-3.2$ git add .
bash-3.2$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: study/readme.txt
bash-3.2$ git commit -m "add GLP for readme.txt"
[master da197f4] add GLP for readme.txt
1 file changed, 1 insertion(+), 1 deletion(-)
bash-3.2$ git status
On branch master
nothing to commit, working tree clean
验证最新提交后的版本
bash-3.2$ pwd
/Users/yanshunjun/Desktop/mygithub
bash-3.2$ cat study/readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
准备版本回退
在回退版本之前，我们先来回想一下 readme.txt 文件共修改了几次， 3 次对吧。但实际的开发中，有很多文件，一个文件里会有上千行代码，修改过的次数远远超出了你的智商能够承受的范围。怎么办？ Git 早就为你想好了。
git log 命令可以查看提交的版本历史
commit da197f447342e65bbf37f5b2e609c71d52db7955 (HEAD -> master)
Author: sharkgit1976 <dockerhub@163.com>
Date: Sun Oct 15 10:04:23 2017 +0800
add GLP for readme.txt
commit a34d2370138d520d1fabc1aa2acc2d234047a39a
Author: sharkgit1976 <dockerhub@163.com>
Date: Sat Oct 14 17:31:19 2017 +0800
add distributed
commit 63e4ecd9409ff1679b8367c116a1c68f045af88d
Author: sharkgit1976 <dockerhub@163.com>
Date: Sat Oct 14 16:16:22 2017 +0800
crete a readme file
git log 常用参数**
某一个人的提交记录:
git log --author=name
一个压缩后的每一条提交记录只占一行的输出:
git log --pretty=oneline
或者你想通过 ASCII 艺术的树形结构来展示所有的分支, 每个分支都标示了他的名字和标签:
git log --graph --oneline --decorate --all
看看哪些文件改变了:
git log --name-status
更多的信息，参考：
git log --help
所以加上参数 --pretty=oneline 会显示的更简洁
da197f447342e65bbf37f5b2e609c71d52db7955 (HEAD -> master) add GLP for readme.txt
a34d2370138d520d1fabc1aa2acc2d234047a39a add distributed
63e4ecd9409ff1679b8367c116a1c68f045af88d crete a readme file
(END)
最前面的一串字符 da197f…7955 是commit id（版本号），是一个SHA1计算出来的一个非常大的数字，用十六进制表示。
每提交一个新版本，实际上Git就会把它们自动串成一条时间线。
开始版本回退
开回退之前，起码需要知道当前的版本。 在Git中，用HEAD表示当前版本和分支，从上面的信息中我们现在处于分支 master 的 da197f4…7955 版本。下面我用命令 git reset 回退版本到上次修改前的版本，也就是 a34d2370138…a39a 。
命令用法：
git reset --hard 版本号
版本号的表示形式：
1. 可以是十六进制的形式
2. 也可以是 Git 内部变量的形式。 上一个版本就是HEAD^，上上一个版本就是HEAD^^，100 个版本写成 HEAD~100
十六进制的版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。
bash-3.2$ git reset --hard HEAD^
HEAD is now at a34d237 add distributed
验证版本
bash-3.2$ cat study/readme.txt
Git is a distributed version control system.
Git is free software.
回到未来
再看看版本库日志
a34d2370138d520d1fabc1aa2acc2d234047a39a (HEAD -> master) add distributed
63e4ecd9409ff1679b8367c116a1c68f045af88d crete a readme file
(END)
可以看到最近一次修改后提交的版本 add GLP for readme.txt 不见了，此时，我们是不是回不到未来了呢？
要想回到未来(最后一次提交的版本），就必须知道那个版本 ID，但是现在没有了，怎么办?
放心 Git 又给想好了， git reflog 命令会记录每一次导致版本变化的命令以及涉及到的版本号
bash-3.2$ git reflog
a34d237 (HEAD -> master) HEAD@0: reset: moving to HEAD^
da197f4 HEAD@1: commit: add GLP for readme.txt
a34d237 (HEAD -> master) HEAD@2: commit: add distributed
63e4ecd HEAD@3: commit (initial): crete a readme file
(END)
这样我们现在又可以回到未来了
da197f4 就是我们要回去的版本 ID
bash-3.2$ git reset --hard da197f4
HEAD is now at da197f4 add GLP for readme.txt
bash-3.2$ cat study/readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
bash-3.2$ git log --pretty=oneline
da197f447342e65bbf37f5b2e609c71d52db7955 (HEAD -> master) add GLP for readme.txt
a34d2370138d520d1fabc1aa2acc2d234047a39a add distributed
63e4ecd9409ff1679b8367c116a1c68f045af88d crete a readme file
就这样，在 Git 的帮助下，你滚来滚去…
1.5.3 HEAD 指针
用过其他版本控制的软件的同学，可能会感觉 Git 的版本切换很快，就是因为有指针在起作用。
HEAD 指向哪个版本，当前就是哪个版本；当你来回切换版本的时候，Git 只是把 HEAD 指向你要切换的版本，顺便把工作区的文件更新一下,见下图：
版本回退后的指针指向：
1.6 我的兄弟们（分支管理）
创建分支 bac
bash-3.2$ git branch bac
切换到分支 bac
bash-3.2$ git checkout bac
Switched to branch 'bac'
创建并切换分支
上面的两条命令可以合并为一条
bash-3.2$ git checkout -b bac
查看分支
bash-3.2$ git branch
* bac
master
星号代表当前所在的分支
在分支 bac 上修改文件，并创建一个新文件 bac_new.txt，最后正常添加、提交。
bash-3.2$ echo "changes on the branch of bac" >> study/readme.txt
bash-3.2$ touch bac_new.txt
bash-3.2$ git add .
bash-3.2$ git commit -m "added a new line in readme.txt,create a file bac_new.txt"
[bac 096a515] added a new line in readme.txt,create a file bac_new.txt
2 files changed, 1 insertion(+)
create mode 100644 bac_new.txt
bash-3.2$ tail -3 study/readme.txt
Git 管理的是修改
Git 管理的不是文件
changes on the branch of bac
bash-3.2$ ls
bac_new.txt newdir study
此时会被提交到 bac 分支，工作区当然也是属于 bac 分支的
切换到 master 分支，并观察文件的变化
bash-3.2$ git checkout master
Switched to branch 'master'
bash-3.2$ tail -3 study/readme.txt
Git is free software distributed under the GPL.
Git 管理的是修改
Git 管理的不是文件
bash-3.2$ ls
newdir study
切换到 master 分支后， HEAD 指针也就会指向 master 所指向的提交点，工作区也就属于 master，自然，你看不到在 bac 分支对文件做的任何修改
把分支 bac 合并到 master分支
bash-3.2$ git branch # 确定一下你现在所在的分支是 mster
bac
* master
bash-3.2$ git merge bac # 把 bac 分支合并到 master
Updating 6b0e1ca..096a515
Fast-forward
bac_new.txt | 0
study/readme.txt | 1 +
2 files changed, 1 insertion(+)
create mode 100644 bac_new.txt
bash-3.2$ ls # 确认工作区的文件
bac_new.txt newdir study
把 bac 分支合并到 master 分支后的文件变化：
合并完成后，删除分支 bac，并查看分支
bash-3.2$ git branch -d bac
Deleted branch bac (was 096a515).
bash-3.2$ git branch
* master
bash-3.2$
删除分支 bac 就变成下图的样子：
Git鼓励大量使用分支：
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
* 查看分支：git branch
* 创建分支：git branch <name>
* 切换分支：git checkout <name>
* 创建+切换分支：git checkout -b <name>
* 合并某分支到当前分支：git merge <name>
* 删除分支：git branch -d <name>
1.6.3 分支管理的策略
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
下面我们实战一下–no-ff方式的git merge：
首先，仍然创建并切换dev分支：
$ git checkout -b dev
Switched to a new branch 'dev'
修改readme.txt文件，并提交一个新的commit：
$ git add readme.txt
$ git commit -m "add merge"
[dev 6224937] add merge
1 file changed, 1 insertion(+)
现在，我们切换回master：
$ git checkout master
Switched to branch 'master'
准备合并dev分支，请注意–no-ff参数，表示禁用Fast forward：
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
合并后，我们用git log看看分支历史：
$ git log --graph --pretty=oneline --abbrev-commit
* 7825a50 merge with no-ff
|\\
| * 6224937 add merge
|/
* 59bc1cb conflict fixed
...
可以看到，不使用Fast forward模式，merge后就像这样：
1.7.1 创建标签
在Git中打标签非常简单，首先，切换到需要打标签的分支上
bash-3.2$ git checkout bac
Already on 'bac'
bash-3.2$ git branch
* bac
master
shark
yan
敲命令git tag 就可以打一个新标签
默认是把标签打到最新一次的 commit 上
bash-3.2$ git tag v1.0
v1.0 就是标签名
可以用命令git tag查看所有标签
bash-3.2$ git tag
v1.0
给历史 commit 打标签
先查看历史版本
bash-3.2$ git log --pretty=oneline --abbrev-commit
fa6419a (HEAD -> bac, tag: v1.0) Problem one has been repaired
096a515 added a new line in readme.txt,create a file bac_new.txt
6b0e1ca del file useless.txt
3dc63a6 added a file useless.txt
比方说要对 del file useless.txt 这次提交打标签，它对应的 commit id 是 6b0e1ca，敲入命令
bash-3.2$ git tag v0.8 6b0e1ca
bash-3.2$ git tag
v0.8
v1.0
注意，标签不是按时间顺序列出，而是按字母排序的
查看标签信息: git show
bash-3.2$ git show v0.8
commit 6b0e1cafc5a72ef8367e4c83e23558f8f00084c8 (tag: v0.8)
Author: sharkgit1976 <dockerhub@163.com>
Date: Mon Oct 16 14:32:44 2017 +0800
del file useless.txt
diff --git a/useless.txt b/useless.txt
deleted file mode 100644
index e69de29..0000000
(END)
通过-s用私钥签名一个标签
bash-3.2$ git tag -s v0.1 -m "signed version 0.1 released" 63e4ecd
fatal: cannot run gpg: No such file or directory
error: gpg failed to sign the data
error: unable to sign the tag
签名采用PGP签名，因此，必须首先安装gpg（GnuPG），如果没有找到gpg，或者没有gpg密钥对，就会报上面的错误信息。如果报错，请参考GnuPG帮助文档配置Key。
正常的话不会输出任何信息，你是知道的，Linux 就是这样。
查看 PGP 签名信息
git show
用PGP签名的标签是不可伪造的，因为可以验证PGP签名。验证签名的方法比较复杂，这里就不介绍了。
1.7.2 操作标签
删除本地标签
bash-3.2$ git tag -d v0.8
Deleted tag 'v0.8' (was 6b0e1ca)
默认标签只会存储在本地，不会被自动推送到远程。
小结时刻
git tag 用于新建一个标签，默认为 HEAD，也可以指定一个 commit id；
git tag -a -m “blablabla…” 可以指定标签信息；
git tag -s -m “blablabla…” 可以用 PGP 签名标签；
git tag 可以查看标签信息及 PGP 签名信息（假如有）
git tag 可以查看所有标签。
git tag -d 删除标签
Gitlab部署和基本配置
一、安装和配置依赖环境
最少需要 4G 内存
1 关闭防火墙和 SELinux
2 安装依赖包
yum install -y curl policycoreutils-python openssh-server perl
二、添加GitLab软件包存储库并安装软件包
1 添加 GitLab 仓库文件
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
2 配置服务器的 FQDN
external_url 的值，将用于与 GitLab实例进行交互的地址。通过SSH / HTTP / HTTPS克隆将使用此地址。访问Web UI将引用此DNS条目。
下面我们声明一个变量,一般安装工具使用此变量部署 GitLab Server
EXTERNAL_URL="https://gitlab.sharkyun.com"
注意： gitlab.sharkyun.com 需要能被正常解析为 GitLab Server 的 IP
安装 Git ce （社区版）
Git ee 是企业版，收费
yum install -y gitlab-ee
三、配置 Gitlab Server
gitlab的配置文件 /etc/gitlab/gitlab.rb
1 配置时区
gitlab_rails['time_zone'] = 'Asia/Shanghai'
2 绑定监听的域名或IP
external_url 'http://192.168.60.119'
此地址用于访问 GitLab 服务器。
3 使用非默认的 80 端口
如果需要手工修改nginx的port ，可以在gitlab.rb中设置 nginx[‘listen_port’] = 8000 ，然后再次 gitlab-ctl reconfigure即可
4 配置发送邮件通知
假如你想让互联网的邮箱服务提供商，帮你的 gitlab 发送邮件，就需要在配置文件中设置，并且需要在邮件服务提供商那里开通 SMTP和POP3 功能。
关于 SMTP 和 POP3 的区别，访问 https://www.zhihu.com/question/24605584
这里简单说一下， SMTP 用于发邮件, POP3 用于收邮件。
这里我以 126 邮箱为例，演示一下
配置系统使用的SMTP 服务器设置
在配置文件： /etc/gitlab/gitlab.rb 中做如下修改
这部分，不管是使用postmail或者SMTP都需要做如下的配置。
#是否开启系统邮箱，默认开启
gitlab_rails['gitlab_email_enabled'] = true
#用这个账号去发送邮件,也就是开通了 SMTP 服务的账户
gitlab_rails['gitlab_email_from'] = 'my@126.cn'
#发送邮件中要显示的发件人名称
gitlab_rails['gitlab_email_display_name'] = 'Gitlab Server Admin'
#邮件的标题后缀，如下图
gitlab_rails['gitlab_email_subject_suffix'] = '[gitlab]'
配置完系统的发件信息，接下来设置邮件服务提供商的账户登录验证信息。
要想使用邮件服务商为 gitlab 系统发送邮件，是需要进行登录， 登录就需要先验证的。
所以要填写相关用于登录验证的信息
值的注意的是，上面 gitlab_email_from 的账户必须和这里的用户名(smtp_user_name)一致。
#是否开启系统邮箱，默认开启
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.126.com"
gitlab_rails['smtp_port'] = 465
#用这个账号去发送邮件,也就是开通了 SMTP 服务的账户
gitlab_rails['smtp_user_name'] = "my@126.com"
gitlab_rails['smtp_password'] = "xxx" # 授权码，非登录密码
gitlab_rails['smtp_domain'] = "126.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = true
gitlab_rails['smtp_openssl_verify_mode'] = 'peer'
#更多查看下方网址
#https://docs.gitlab.com/omnibus/settings/smtp.html
#如果你不配置发件人, 有些邮件服务器会发送失败,
#所以我们最好把账号和发件人都配置了, 并且保持一致, 这样保证兼容问题
SMTP 客户端授权码
重启相关服务，使最新的配置文件生效
[root@vm1 ~]# gitlab-ctl reconfigure
#再重启一下
[root@vm1 ~]# gitlab-ctl restart
使用gitlab-rails console命令进行发送邮件测试，如下所示：
irb(main):003:0> Notify.test_email('收件人邮箱', '邮件标题', '邮件正文').deliver_now
示例
[root@vm1 ~]# gitlab-rails console
Loading production environment (Rails 4.2.10)
irb(main):001:0> Notify.test_email('86000153@qq.com', 'Message Subject', 'Message Body').deliver_now
...
irb(main):002:0>quit
[root@vm1 ~]#
配置并启动相关服务
每次必须配置后，才能启动相关服务器，不论是不是第一次启动服务。
使用gitlab-ctl reconfigure 自动配置，并安装数据库，初始化信息，如下所示(第一次使用配置时间较长)：
[root@vm1 ~]# gitlab-ctl reconfigure
.....
启动服务器执行如下命令
gitlab-ctl star
四、初次登录
1 设置 root 管理员密码
用户在第一次登录服务器的时候，都需要重新设置密码。
在浏览器中输入 Gitlab 服务器地址
由于安装的版本不同，有可能你看到页面的布局和这里的不一样。
2 登录
修改密码成功后，再次访问服务器，会显示登录页面
3 设置中文页面
页面拉取到最后
修改完毕后，刷新页面即可
4 修改管理员 root 的密码
假如忘记密码可以执行如下命令修改
命令: gitlab-rake “gitlab:password:reset”
[root@prodgitlab ~]# gitlab-rake "gitlab:password:reset"
Enter username: root // 输入需要修改密码的用户名
Enter password:
Confirm password:
Password successfully updated for user with username root.
Gitlab-02-Gitlab-使用
创建用户
填写用户密码和邮箱
设置用户类型
最后将页面下拉到底，点击 Create user
用户通过确认邮件中链接修改初始密码
让用户登录到自己的邮箱查看有没有验证邮件
git操作指令合集