零、引很多时候，有人用网盘共享代码，或者直接打一个归档发送代码的时候，我都十分头疼，说，为什么你不用Git，就会有人问我，Git到底是什么，更有甚者完全不知道Git，GitHub，GitLab甚至Gitee之间的区别，中间都沾染了一个Git，便慌了手脚，不知其所以。没耐心时，我便解释道，Git是存代码的网盘，显然，这么解释并不准确。然而，对于没接触过版本控制的人或初学者，Git和GitHub甚至是划等号的，理解为代码云盘，其实并不然。一、何为版本控制那么究竟什么是版本控制（VCS，Version Control System），Wiki百科的定义是“维护工程蓝图的标准作法，能追踪工程蓝图从诞生一直到定案的过程。此外，版本控制也是一种软件工程技巧，借此能在软件开发的过程中，确保由不同人所编辑的同一程序文件都得到同步”。好家伙，我直接你说这个谁懂啊.jpg所以，为了容易理解，我们想象这样一个场景。当你在写毕业论文的时候，慷慨挥洒数万字，一交查重红一半。这时候我们就需要对我们的论文进行修改，将重复的部分修正掉，然而，这就面临着一个问题，我们究竟是在原来的文件上直接修改并覆盖，还是另存成另一个文件呢。大概率，我们是舍不得我们死掉数亿脑细胞憋出来的奇怪文字的，于是乎，另存为，重命名一气呵成：毕业论文2.0.docx，毕业论文2.1.docx，毕业论文2.1最终版.docx，毕业论文2.1最终绝对不改版.docx，毕业论文2.1最终绝对不改版-副本.docx。一同操作之下，我们的毕业论文终于写好了，而我们的文件夹里多出了一堆莫名其妙的中间状态的文件，你说删也不是，万一哪天需要回溯查一下以前的日志呢；不删吧，乱七八糟，什么名字都有。更可怕的是，这些论文不仅是你自己改的，甚至还有你的导师直接帮你修改的部分片段，这下你犯了难，到底哪些是教授改的，那些是自己改的，到底要留哪些文档？于是乎，你想到了一个绝妙的办法，那我何不直接只留一份文档，然后另外建一个表格，只要记录每次的修改内容不就得了。这是一个好办法，这也就是系统化的版本控制系统的雏形，就像下面这张表格。提交ID修改的文件修改内容修改人修改时间f0cf2288毕业论文.docx新增：创建文件xxx学生2022-01-05 15:00:00 ( UTC +8)7e59772a开题报告.docx新增：关于背景的研究xxx学生2022-01-05 15:00:00 ( UTC +8)8d90d5f5毕业论文.docx修改：变更标题为xxxxxx教授2022-01-05 16:00:00 ( UTC +8)d271eceb毕业论文.docx新增：实验数据xxxxxx学生2022-01-05 16:30:00 ( UTC +8)c72f6412毕业论文.docx修改：实验数据xxx为xxxxxx教授2022-01-05 17:30:00 ( UTC +8)7c0e4c8d开题报告.docx修改：变更标题为xxxxxx教授2022-01-05 18:00:00 ( UTC +8) 这样，我们只需要保存最新版本的文件，而期间的全部修改，将有版本控制系统进行，在上面这个例子中，这个系统便是这个记录变化的表格。根据此，我们可以发现，版本控制系统首先它可以保存最新版本的文件，一般称这个保存文件的空间为仓库；它可以记录每次修改的内容，一般称为提交（commit）；它可以多人协同工作，即多个人维护同一个仓库中的文件。二、为什么选择Git现在，我们已经了解了什么是版本控制，那么我们到底应该用哪个版本控制软件呢？根据上文，我们了解到，其实版本控制只是一个“标准工作流程”，或者说是一种方法，那么为了实现这种方法，我们自然需要一个软件的帮助，不然每个代码文件我们都用excel表格来记录变化那岂不是脑子有点毛病。其实，版本控制软件有很多，比如Git的爹BitKeeper，CVS，以及后面的SVN。然而，在一众版本控制软件中，Git最终脱颖而出，成为这个时代的主流，这不乏其中的历史原因（有兴趣可以了解一下当年BitKeeper与Linux与Linus与Git的历史）。然而除了历史原因之外，也因为Git的本身设计足够优秀，我们简单对比一下Git与风靡一时的SVN便可一窥究竟。不同点GitSVN部署方式分布式集中式数据备份分布式备份服务端全量备份同步可提交在本地后与其他服务器或用户同步依赖部署SVN的服务器分支自行创建的分支不会影响其他用户且速度较快创建分支将影响全体用户且每次变化将引起所有用户同步冲突处理不中断提交，标记冲突文件，解决冲突中断提交，后提交者需要自行解决冲突后重新提交托管平台有，且很多，且有诸多大企业背书有，但少，且可靠性差我们可以看出来，Git的一大特点即分布式，即每个使用者在本地机器上安装Git后，创建或拉取仓库后，你的本地将拥有该仓库的全部信息，当其他用户下线或中央服务器宕机时不会影响本地仓库进程，可先在本地提交更改后待远程仓库恢复后向全部分布式网络中的仓库推送修改。而使用SVN则高度依赖部署SVN服务端的服务器，当失去与服务端的连接则无法提交自己的修改。而分布式还有一大有点，当远程数据丢失时，由于分布式特性，每一个本地仓库都有着全量的仓库部分，不会出现由于服务器故障导致全部文件丢失的情况。三、Git的安装1. Linux由于最早Git便是在Linux上开发的（实际上是Linus为了维护Linux的代码而开发的，可以参考Linux社区与BitKeeper当年的纠纷），所以现在很多Linux镜像都会默认内置Git镜像，我们可以使用terminal试一下到底有没有安装Git，即git如果出现的不是usage: git后面接了一串指令的指令帮助，则当前系统没有安装Git，然而由于Git的知名度，大多数包管理软件都会包含Git，我们只需要通过相应的包管理软件进行安装即可，比如# CentOS等其他使用YUM包管理器的Linux发行版yum -y install git yum -y install git # Debian或Ubuntu等其他使用APT包管理器的Linux发行版 apt-get install git2. Windows虽然Git脱胎于Linux，然而其迅速走红和其优秀的开源性，很快就有人将其移植到Windows与Mac设备上，但是我手上没有Mac设备，因此只讲Windows设备。首先，我们可以在官网下载最新版本的Git for Windows安装包，一般选择64位即可。下载后，我们只需要双击运行，一步一步按照顺序点下一步安装即可（我一般就是全默认设置，如果了解具体的参数设置可以自行搜索Windows下Git安装详细教程）3. 配置当我们安装好了以后，最后需要简单配置一下Git的用户信息，我们可以用git config --list来列出全部的Git配置。# 配置用户名，将User改成自己的名字 git config --global user.name "User" # 配置用户邮箱，将email@example.com改为自己的邮箱 git config --global user.email "email@example.com" # 注：以上两行命令中的“--global”为全局指令，即加上该参数则对全局账户进行设置，如果不加则仅对当前仓库进行配置四、Git命令行1. 创建代码仓库现在，我们下载并安装好了git，终于可以拿来管理我们的代码了。首先，我们需要创建一个仓库。首先，我们需要准备一个工作区用来存放我们的仓库文件，即一个文件夹。Windows下可以直接右键新建文件夹，或者使用命令行mkdir git-test当我们新建好了文件夹后，我们需要进入到文件夹中，在文件夹内右键选择“在Windows终端打开”（Windows11下），或使用cd指令进入该文件夹cd /xxx/xxx/git-test #/xxx/xxx为该目录上级目录的绝对路径当然，不事先新建文件夹也可以，可以在已经有代码文件的文件夹下执行下面的命令，或者由Git创建仓库工作区。当我们进到这个文件夹后，在终端（也就是CMD）或者Git Bash中输入git指令。输入指令后，文件夹中讲初始化出一个.git的隐藏文件夹。# 在本文件夹内初始化一个Git仓库 git init # 如果使用这个方式，则不需要先创建空文件夹，git会自动创建一个叫xxx的文件夹并将仓库初始化 git init xxx 2. 添加/删除/修改文件这个时候，我们可以在这个仓库文件夹中创建我们的文件，这个文件可以是任何格式，为了方便，我们C语言源码作为例子。创建一个hello.c的文件，在文件中写入如下代码：int main(){ printf("Hello World"); }现在，我们保存文件。注意，此时的文件仅存在于我们的本地工作区，并未包含在Git仓库的暂存区中，我们需要使用git指令将该文件添加到仓库的暂存区中# 查询工作区与暂存区内的变化，每次变化都会记录，可以使用这个指令查看变化，无论是添加还是删除都会显示，以后不再赘述 git status # 将hello.c存入暂存区 git add hello.c # 如果创建了一个目录（文件夹）也可以使用add指令添加到暂存区（会将其内部子文件夹也进行添加） git add folder-name # 如果要提交的目录和文件太多，可以直接用.提交全部仓库根目录下的文件 git add . # 如果对文件多处进行了修改，可以在后面加上-p参数对每处变化进行缺人 git add xxx -p现在，我们已经将文件成功添加到Git的暂存区里了（注意，这里是暂存区，而不是已经提交到了git。为了保证事务的原子性，需要后面统一commit提交到git中）。那么，当我们对文件进行删除的时候，我们也需要进行相关的操作：# 将文件夹中的文件删除，并提交到暂存区。注意，当文件的修改或新增没有提交的情况下是不允许进行该操作的 git rm hello.c # 将通过文件恢复，可以恢复rm及其他操作的更改 git restore . # 恢复根目录 git restore folder-name # 恢复指定目录 git restore hello.c # 恢复指定文件 # 在Git中删除该文件，但是在本地工作区内不删除 git rm --cached hello.c # 撤销操作，可以撤销上一步，具体的后面再提 git reset除了删除，我们还可以进行重命名操作：# 更改后将直接提交至暂存区 git mv 原文件名 新文件名最后，对文件的修改，我们只需要对文件内容进行修改即可，修改后的文件我们依旧使用add添加指令提交到暂存区3. 提交变化现在，我们已经对文件进行了新建删除修改操作并已经提交到了暂存区，然而暂存区还并不是我们Git的仓库存储的位置，所以我们还需要将我们已经提交到暂存区的变化再次提交到Git仓库中。# 将暂存区提交至仓库，每次提交需要写明提交信息，信息写在 -m 参数后 git commit -m "提交信息" # 仅将暂存区的指定文件提交至仓库，多个文件用空格隔开 git commit hello.c -m "提交信息" # 跳过暂存区，直接将工作区提交至仓库 git commit -a -m "提交信息" # 重新提交一次并取代上一次的提交，如果提交内容没有变化，则只修改提交信息 git commit --amend -m "提交信息" # 重新提交，并指定重新提交的文件 git commit --amend hello.c4. 分支当我们开发时，大多项目是分模块，由不同的开发人员开发完成的。对于不同的开发模块，我们希望开发该模块时不影响到其他的部分，如果我们所有人调试所有模块都在一起进行，那么如果有一个人出现问题所有人都要受到波及，这时候我们就要引入分支，当我们使用分支的时候，我们仅对当前分支进行修改调试，当调试通过后，我们通过分支合并进行对分支的整合以达到隔离开发与最终整合的目的，保证了开发互不影响。 # 列出所有本地分支 git branch # 列出所有远程分支 git branch -r # 列出所有本地分支和远程分支 git branch -a # 新建一个分支，但并不切换进新分支 git branch name # 新建一个分支，并切换到该分支 git checkout -b name # 新建一个分支，并将指定提交id的commit拉取进该分支 git branch name commit-id # 新建一个分支，与指定的远程分支建立追踪关系 git branch --track name remote-name # 切换到指定分支，并更新工作区 git checkout name # 切换到上一个分支 git checkout - # 在现有分支与指定的远程分支之间建立追踪关系 git branch --set-upstream name remote-name # 合并指定分支到当前分支 git merge name # 选择一个commit，合并进当前分支 git cherry-pick commit-id # 删除分支 git branch -d name # 删除远程分支 git push origin --delete name git branch -dr name5. 撤销当我们对文件进行了修改或删除，但是我们发现出了错误，此时我们需要对我们的操作进行撤销# 将暂存区的文件恢复到工作区 git checkout hello.c # 将指定提交id的指定文件恢复至暂存区与工作区 git checkout commit-id hello.c # 将暂存区的所有文件恢复到工作区 git checkout . # 重置暂存区的指定文件，与上一次提交保持一致，但工作区不变 git reset hello.c # 重置暂存区与工作区，与上一次commit保持一致 git reset --hard # 重置当前分支的指针为指定提交id，同时重置暂存区，但工作区不变 git reset commit-id # 重置当前分支的指针指向指定commit，同时重置暂存区和工作区，与指定commit一致 git reset --hard commit-id # 重置当前分支的指针为指定commit，但保持暂存区和工作区不变 git reset --keep commit-id # 新建一个commit，用来撤销指定commit # 后者的所有变化都将被前者抵消，并且应用到当前分支 git revert commit-id # 暂时将未提交的变化移除，稍后再移入 git stash git stash pop6.标签与版本发布当我们的开发告一段落，我们发布了一个正式的版本，这时候，我们可以通过标签系统将我们此时发布的版本进行标记发行# 列出所有tag git tag # 新建一个tag在当前commit git tag name # 新建一个tag在指定commit git tag name commit-id # 删除本地tag git tag -d name # 删除远程tag git push origin :refs/tags/name # 查看tag信息 git show name # 提交指定tag至远程 git push 地址 name # 提交所有tag至远程 git push 地址 --tags # 新建一个分支，指向某个tag git checkout -b branch-name tag-name # 将仓库所有文件归档以备发布，gzip为Linux下的归档工具，可指定格式为zip或者tar git archive --format=zip master | gzip > file.zip7. 查看仓库变化信息# 显示有变更的文件 git status # 显示当前分支的版本历史 git log # 显示commit历史，以及每次commit发生变更的文件 git log --stat # 搜索提交历史，根据关键词 git log -S keyword # 查询全部符合筛选条件的提交描述的提交 git log HEAD --grep "关键字" # 显示某个文件的版本历史，包括文件改名 git log --follow filename git whatchanged filename #查看某文件的全部提交及变化内容 git log -p filename # 显示所有提交过的用户，按提交次数排序 git shortlog -sn # 显示指定文件是什么人在什么时间修改过 git blame filename # 显示暂存区和工作区的差异 git diff # 显示暂存区和上一个commit的差异 git diff --cached filename # 显示工作区与当前分支最新commit之间的差异 git diff HEAD # 显示两次提交之间的差异 git diff commit-id1 commit-id2 # 显示某次提交的元数据和内容变化 git show commit-id # 显示某次提交发生变化的文件 git show --name-only commit-id # 显示某次提交时，某个文件的内容 git show commit-id:filename # 显示当前分支的最近几次提交 git reflog五、远程托管现在，我们已经在本地完成了全部Git的操作，我们终于可以愉快的在本地使用版本控制了，再也不用担心哪次手残删了重要的文件了。然而，现在还有另一个问题，那就是我们现在也只能在本地进行仓库的操作，那么怎么进行团队间的合作呢？我们可以通过HTTP协议或者SSH连接到其他人电脑上IP上的Git，这样，我们就可以用远程指令在多个不同合作用户之间进行仓库同步了。然而，就像电话一样，如果两两都需要接一条线的话，那么我们本地需要维护太多个远程仓库了，在这种场景下，远程仓库托管就应运而生了。我们可以将我们的仓库同步到一个开放的远程的仓库上，这个远程的仓库有着完整的域名配置，Git系统等等，以它作为中转，我们所有同步开发这只需要都连接到该远程仓库就可以实现同步了。这个流程大概就是我在本地创建了一个仓库，然后申请了一个类似于GitHub的托管平台的账户，我将我的本地仓库推送到GitHub上面，如果是公开仓库的话所有人都可以看到，这时我拉来了另一个开发者一起开发这个项目，他从GitHub上拉取了我的仓库到他的本地，这样就存在了三个仓库，这也符合了Git分布式的概念。我在本地仓库进行工作，他在他的仓库上工作，当我们的工作都进行的差不多了，统一提交到这个远程的仓库托管平台就可以了。同时，我们也可以获得到该远程平台上最新的代码进度到本地仓库。现在，全世界最大的代码托管平台当然是GitHub，在微软的钞能力加持下，GitHub已经成为了世界第一大的源代码托管平台。出了托管源代码，GitHub也发展出了很多新的与Git无关的功能，比如Release，Issue等等。因此，当我们学会使用Git后，自然需要学习如何使用GitHub，这篇文章就不再延申。然而，由于GitHub的全英文，加之国内种种原因导致访问GitHub及其缓慢与困难，大大提高了GitHub的使用门槛，在这种环境下，Gitee应运而生。然而，虽然开源中国打着开源的旗号，实则做的是垄断的生意，以开源之名四处对开发者相逼。而且由于某种不可名状的不可抗力，Gitee的监管力度与开放程度堪称灾难（我之前有个很正常的没涉黄没侵权没有任何问题的仓库就给我封了）。因此，我在此呼吁各位，千万不要使用Gitee，那玩意连注销账户都注销不了，被封的仓库删也删不要掉，发邮件根本没人理，所以懂得都懂。除了垃圾到了极点的Gitee和访问极其困难的GitHub之外，还有一个托管平台大放异彩，那就是GitLab。GitHub虽然“不作恶”，但是毕竟代码不是放在自己手上，不放心，而且以前也出过仓库被黑客勒索和GitHub用私有仓库训练AI的事情，保密性高的国内项目是不会放在上面的。而GitLab支持本地化部署，即部署在自己的服务器上，这就有了相当强的优势了（我上家公司用的就是私有化部署的GitLab），因此我前段时间也在自己的一个闲置服务器上部署了一个，相关详情教程见上篇博客。说了这么多，言归正传，我们继续讲Git的远程操作指令。# 下载远程仓库的所有变动 git fetch 远程仓库名 # 显示所有远程仓库 git remote -v # 显示某个远程仓库的信息 git remote show 远程仓库名 # 增加一个新的远程仓库，并命名 git remote add 远程仓库名 远程仓库地址 # 取回远程仓库的变化，并与本地分支合并 git pull 远程仓库名 分支名 # 上传本地指定分支到远程仓库 git push 远程仓库名 分支名 # 强行推送当前分支到远程仓库，即使有冲突 git push 远程仓库名 --force # 推送所有分支到远程仓库 git push 远程仓库名 --all六、参考与感谢[1] 维基百科.版本控制[2] 维基百科.Git[3] 廖雪峰.Git教程[4] 阮一峰.常用 Git 命令清单[5] Git文档 2022-01-05 22:47 UtopiaXC 于大连
垃圾Gitee狗都不用今天早上收到一封邮件，居然是Gitee发来的，我一看，好家伙，给我仓库封了，理由是侵权。当初这个仓库就是随手写的模拟我们学校疫情期间的出校请假证明，而且写完之后学校系统就升级了我这个就没用了，一直放在GitHub上面没管。后面有一次学校实训，非要用Gitee提交代码，我就顺手把GitHub上面的仓库都同步过来了，好家伙，我都一年多没上了，这会告诉我我仓库给我封了。我深深地对国内这些托管机构产生了信任危机，当机立断发邮件要求删除我的被封仓库并注销我的账户。被封邮件GitLab由于GitHub有的时候不挂代理真的太慢了，在国内给别人看代码实在不方便，而且还准备教工作室的学弟学妹们用这些，所以萌生了一个自己部署Git托管的想法。上一家离职的公司代码托管是自己部署的GitLab，用着也算是熟了。之前一直没自己部署是因为没有啥性能靠谱的服务器，这次是趁着年底，买了个天翼云的8H16G的机子，然后把mc放到那上面去了，这样我原来的4H8G的腾讯云的机器就闲下来了，我寻思还不如找点东西部署上去，正好要一个Git托管，就放在这上面好了。部署GitLab分两个版本，一个是企业版，就是GitLab EE，一个是社区版，GitLab CE。EE的话多了一些功能（其实具体的我也不知道多了啥，想知道去官方看文档吧。反正我就仓库管理流水线啥的标准版也有）。查了半天CE其实是EE的非空真子集，而且EE不激活订阅的话CE的功能一样也能用，所以这里建议直接部署EE，反正也没什么损失，万一以后想订阅了呢。部署方式部署方式的话有两种，一个是用官方的脚本直接把服务部署在系统上，另一种是用docker。考虑到未来迁移、维护的一些问题，我选择了docker部署。安装dockerdocker的安装直接使用官方提供的脚本即可sudo curl -sSL get.docker.com | sh如果希望使用docker compose的话可以再装一个，我用的是pip安装的（需要python3）（虽然后面我也没用到这玩意部署所以你也可以不用）pip3 install docker-compose获取镜像不少人获取的是非官方的中文镜像，其实没必要，官方的汉化已经达到95%了，不过需要用户自己更改自己的语言，网站默认还是英文。docker pull gitlab/gitlab-ee # 这里要是不想装EE的话，后面的ee改成ce就行 启动服务事先找个路径，创建三个文件夹，比如在/home下，创建一个gitlab文件夹，在gitlab文件夹下创建config、logs、data这三个文件夹用于保存docker映射出的文件由于gitlab自带nginx和数据库PostgreSQL ，我们需要将其暴露出来并作反向代理。docker run -d \ # 启动docker --hostname git.utopiaxc.cn \ # 规定域名 -p 8443:443 \ # 建立docker端口映射以便后面做反向代理，将SSL的443端口映射到主机8443 -p 880:80 \ # 将Nginx的80端口映射到主机880 -p 822:22 \ # 将SSH的22端口映射到主机822 --name gitlab \ # docker服务命名，起什么都可以 --restart always \ # 崩溃自动重启设置为一直 -v xxx/config:/etc/gitlab \ # 将配置文件路径映射出来，xxx为上面提到的路径，如/home/gitlab -v xxx/logs:/var/log/gitlab \ # 将日志文件路径映射出来方便后续查找问题 -v xxx/data:/var/opt/gitlab \ # 将数据目录映射出来方便管理与迁移 -m 5000M \ # 最小内存，这里建议设置超过2000M，我一共8G所以设置了5G --memory-swap=5000M \ # 最小交换内存，这里不得小于最小内存 gitlab/gitlab-ee:latest # 指定docker镜像，即我们上面拉取到的最新版的gitlab镜像执行完这个巨长的shell之后，我们的gitlab服务就启动好了，我们直接通过域名的880端口就可以访问到了。默认管理员账户为root，初始密码在config文件夹中的initial_root_password文件中。（启动会有点慢，虽然已经显示启动成功但是访问的时候还是会显示502，这时的502是带有gitlab标志的502，稍等片刻即可）反向代理我们使用主机的nginx反向代理gitlab服务，注意这里反代的域名和上面启动gitlab的域名要一致。以下为nginx反代配置文件。#PROXY-START/ location ^~ / { proxy_pass http://127.0.0.1:880; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header REMOTE-HOST $remote_addr; add_header X-Cache $upstream_cache_status; #Set Nginx Cache set $static_fileHUnD4FzV 0; if ( $uri ~* "\.(gif|png|jpg|css|js|woff|woff2)$" ) { set $static_fileHUnD4FzV 1; expires 12h; } if ( $static_fileHUnD4FzV = 0 ) { add_header Cache-Control no-cache; } } #PROXY-END/配置文件下面我们来修改gitlab的配置文件，由于上一步我们已经将config映射出来了，所以我们可以很容易的在xxx/config中修改gitlab的配置。由于配置实在是太多了，大家可以去看官方的文档，这里只主要展示我做的修改。只需要修改gitlab.rb文件即可，里面有大量的可配置模板，可以直接将里面的注释去掉进行修改，也可以直接加在文件的最末尾。域名这个用docker部署的话其实不需要修改registry_external_url 'https://registry.example.com' # 将https://registry.example.com改成自己的域名SSH服务端口这一步修改的不是SSH服务的运行端口，而是在克隆的时候的链接中的端口。由于我主机没做SSH反代，所以直接使用的822gitlab_rails['gitlab_shell_ssh_port'] = 822邮件服务这里我用的是outlook的office365企业版，所以是这么配置，至于其他邮箱的配置方法可以参考官方文档，有细微差异。gitlab_rails['smtp_enable'] = true gitlab_rails['smtp_address'] = "smtp.office365.com" gitlab_rails['smtp_port'] = 587 gitlab_rails['smtp_user_name'] = "example@youdomain.com" gitlab_rails['smtp_password'] = "your password" gitlab_rails['smtp_domain'] = "youdomain.com" gitlab_rails['smtp_authentication'] = "login" gitlab_rails['smtp_enable_starttls_auto'] = true gitlab_rails['smtp_openssl_verify_mode'] = 'peer'时区gitlab_rails['time_zone'] = 'Asia/Shanghai'应用配置配置文件修改后需要应用并重启，在主机执行docker exec指令即可。docker exec -t gitlab gitlab-ctl reconfigure # 应用配置 docker exec -t gitlab gitlab-ctl restart # 重启docker当然，出了通过docker exec对内部执行命令行之外，也可以直接重启docker服务。重启后会显示带gitlab标志的502，这是正常现象，说明正在启动，等完全启动后就不会显示502了。其他配置剩下的配置就自己用管理员账户去管理员后台看就行了，看不懂英文的可以在用户配置中将location改为中国-简体中文。具体怎么改随便一搜就能搜到。最后最后声明一下吧，我这个gitlab不是公开的，是我自用还有和工作室的小伙伴用的，需要实名注册，我会审核，不认识的账户我会直接删掉，所以就别费工夫来注册薅羊毛之类的了（我的机器硬盘确实小）。然后，预告一下，下一篇可能是一篇杂文或者是别的，因为最近这不是从北京回大连了么，可能会写一些关于这方面的东西，也是好久没更新博客了，最近比较闲，所以可能会多更新几篇。 2021-12-30 22:59 UtopiaXC 于大连