搭建gitlab服务器

搭建

之前我们是基于比较low的方式手工搭建了一个git服务器，然后在上面放了一个git仓库，而且企业级里面一般不会这么干

实际上，我们可能会需要在git服务器上用可视化界面的方式去查看所有的提交，分支，以及代码，包括需要在git服务器上去进行分支的合并，而不是在本地去执行分支合并，分支合并之前，我们可能需要先执行code review，可以在git服务器上可以看到本次修改了哪些代码？

包括，还有很多其他的事情可以做，然后一些代码的bug缺陷管理和追踪

真正在企业里，都是用专用的git服务器，gitlab，其他的一些git管理软件

硬件准备，给一台2核4G内存的虚拟机，因此需要使用64位的centos

1、Gitlab安装

（1）第一步：在系统防火墙上开启允许ssh和http访问

yum install -y curl policycoreutils-python openssh-server cronie lokkit -s http -s ssh

（2）第二步：安装postfix来支持gitlab发送邮件

yum install -y postfix service postfix start chkconfig postfix on

（3）第三步：安装gitlab

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash EXTERNAL_URL="http://192.168.31.80" yum -y install gitlab-ee

此时会自动安装和配置gitlab，同时在指定的url启动gitlab

（4）第四步：查看gitlab状态

gitlab-ctl status

（4）第四步：按照上面指定的url访问gitlab

重新设置密码，然后使用root和自己设置的密码来访问gitlab

2、使用Gitlab

（1）以管理员身份登录进去之后，可以创建项目了，但是创建之前，可以先创建组和用户，然后创建项目的时候，需要将项目选择归属到组或者用户。一般一个组就是一个大的部门，一般选择为private私有的。

实践经验

比如说，你的公司比较大，有一个团队是基础架构团队，做的都是kv，nosql，缓存，开源项目的二次开发、运维和管理；还有一个团队是做的面向终端用户的，可能做的就是电商业务系统

你的不同技术团队，开发的项目是不同的，可以一个group作为一个团队

每个Group里面有对应的多个用户

（2）进入项目，在settings->members中，还可以手动设置除了组之外的其他人有权限访问这个项目

（3）将自己本地生成的ssh key公钥，添加到gitlab中去。使用开发人员自己的账号登录gitlab，然后选择右上角的profile setting -> ssh keys，将自己的ssh key加入进去。

（4）将oa项目的代码修改成远程仓库为gitlab上的oa-parent

使用Gitlab

实践经验

你的不同技术团队，开发的项目是不同的，可以一个group作为一个团队

每个Group里面有对应的多个用户

（2）进入项目，在settings->members中，还可以手动设置除了组之外的其他人有权限访问这个项目

（4）将oa项目的代码修改成远程仓库为gitlab上的oa-parent

需要在gitlab上，去掉对oa-parent项目的一个master分支的强制保护

默认情况下，gitlab做的非常好，就是将master分支给保护住了，不让任何研发人员直接push代码到master分支的，要求必须采用pull request方式，在gitlab上提交merge的请求，通过管理员的code review

如果一个成员是master权限，那么他就可以将代码直接push到master，同时只有master权限的可以去review pull request

git remote remove origin 重新再次：git remote add origin gitlab项目地址

张三和李四的本地仓库都做一样的事情

张三，执行：git push -u origin master，再次将本地仓库的代码推送到gitlab上去

查查看gitlab上的仓库，就已经有代码了

（5）此时试着在张三本地仓库修改代码，推送到远程仓库，然后李四拉取代码，都走通，就ok了

正常来说，如果李四就是第一次从gitlab拉取代码下来，那么其实是会自动将本地master分支和origin/master关联在一起的

但是我们刚才的情况，是都更改了一下remote origin

所以这里要重新手动将本地master分支和远程origin/master分支做一下关联：git branch --set-upstream-to=origin/master master

3、维护gitlab

启动gitlab：gitlab-ctl start 停止gitlab：gitlab-ctl stop 重启gitlab：gitlab-ctl restart

gitlab日志：/var/log/gitlab

查看gitlab日志：gitlab-ctl tail 查看gitlab对应的Nginx访问日志：gitlab-ctl tail nginx/gitlab_access.log 查看gitlab对应的数据库postgre-sql的日志：gitlab-ctl tail postgresql

gitlab数据存放目录：/var/opt/gitlab/git-data

gitlab是一种开源的管理软件，实际上做到这里为止的话，基本上你就可以玩儿起来了

授人以鱼不如授人以渔。。。。我不太想给大家讲里面的所有的功能，你可以自己去探索，而且可以自己去看官方文档

gitlab使用文档：http://docs.gitlab.com/ce/

权限控制和分支保护

Git高阶实战技巧这一部分的最后一讲，在实际生产环境中，各种高阶的实战技巧

代码权限这回事儿

实际上，如果没有gitlab，你会发现你做代码权限的控制很不方便

但是，有了gitlab之后，你会发现很方便

在实际企业中，结合gitlab，代码权限控制

（1）第一件事情，有些分支是需要被保护起来的，就是说不能直接被push，尤其是master分支。

在settings->repository，有一个protected branch，就是master分支默认是被保护起来的，只有这个项目的master角色的开发人员，才能直接对master分支进行push操作

绝对不允许任何普通的研发人员随意就可以往master分支上push代码

也绝对不允许普通的研发人员，可以有权利把merge request合并到master分支上去

只有拥有master权限的用户才可以s

我们实践中是怎么弄的，一个仓库对应着一个项目，一个项目总有一个leader，项目负责人，高工，架构师

总之，一遍就是这个项目里的高工和架构师才有master的权限，可以push代码到master，还有将merge request合并到master去

（2）仓库全都是private私有的，如果在一个部门中建立了一个项目，那么默认这个部门下的研发人员对这个项目都是有权限的，但是有的人是master，有的人是developer

developer是只有权限对普通的分支进行各种操作的，feature，develop，release

但是最后developer是没有权限直接push代码到master分支的

而且，developer最后是需要提交merge request，将release分支合并到master分支的，此时只有master权限的人才可以去review merge request，将其他分支merge到master分支

其他团队的人，其他group的人，默认是没有权限来访问我们部门的项目的

每个部门的人，默认就只能访问自己部门的项目和代码

每个项目的话呢，又只有master负责人有权限操作master分支

其他团队的人可以作为guest来访问我们团队的项目，因为经常会遇到什么呢？有其他团队的人说，让我看一下你们的代码行不行啊，那此时可以啊，给一个reporter权限就可以了

guest，你可以给一些大领导，有些大领导是不需要修改代码的，可能也不看代码，然后就是来看看你的项目里的一些issue，gitlab管理一些缺陷，大领导，可能会关注一些bug的情况，会进来看看bug相关的一些issue

（3）实践过的一个技巧：强制code review

强制code review，每个工程师在feature分支中开发好和单元测试好之后，他们本来是需要将feature合并到develop去做集成的

其实这个环节是需要进行code review，要求他们必须提交merge request到develop分支，让项目里的master权限的高工去review他们的代码

但是如果默认情况下，没有将develop分支设置为protected，那么普通人是可以绕过高工，直接在本地跟develop分支进行合并，然后push到远程的develop分支上去的

如果将develop分支保护起来之后，就是说，每个研发人员第一次写好feature分支的代码，都必须通过merge request往develop分支合并代码，此时项目里的高工会负责review他们的代码

review通过之后，可以合并到develop分支，做持续集成

后续是要在develop分支做持续集成测试的，可能需要修改bug，修复集成测试的bug，还是在feature分支上进行。每次修复好一批bug之后，push到feature分支，然后提交merge request合并到develop分支，高工继续review代码。

就是说卡在持续集成这个环节，将代码质量给严格把关，每次提交的代码，都必须高工过目，看一眼，不能写的太烂

通过develop持续集成之后，会从develop拉那个release分支，接下来，每个研发人员就可以在release分支直接进行bug的修复了