git&gitlab生产使用案例

一、入门Gitlab

1、Git&Gitlab介绍

Git是一种非常流行的分布式版本控制系统,它和其他版本控制系统的主要差别在于Git只关心文件数据的整体是否发生变化,而大多数版本其他系统只关心文件内容的具体差异,这类系统(CVS,Subversion,Perforce,Bazaar 等等)每次记录有哪些文件作了更新,以及都更新了哪些行的什么内容。Git另一个比较好的地方在于绝大多数操作都可以在本地执行,而每个本地都可以从服务器获取一份完整的仓库代码,而且在没网的时候仍然可以修改和使用大部分命令,在方便的时候再跟服务器进行同步,这样可以更好的实现多人联合编程。
gitlab是利用 Ruby on Rails 一个开源的版本管理系统,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释。可以管理团队对仓库的访问,它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用,便于日后有需要的时候进行查找

2、选择Git的9大优势

  • 稳定安全:没有中央服务器,不存在单点故障
  • 社区活跃:强大的社区支撑,丰富又强大的功能
  • 工作独立:模块化提交代码,避免代码干扰
  • 开发随意:同时和多个远程代码库连接,也可以像svn一样
  • 颗粒提交:支持选择部分有用代码提交
  • web支持: git有后台gitlab支持,很方便权限管理,人员管理
  • 离线操作:可在本地做所有操作,提交代码,查看历史,合并和创建分支等
  • 支持回退:undo几乎所有的命令,非常方便快速
  • 数据完整:不需要担心数据丢失,任何一个人机器上的版本都是一个完整的备份

3、gitlab快速部署

3.1安装gitlab

3.1.1 系统配置

  • 系统版本:Centos7.2
  • 主机名:zqcode.idc.52devops.com
  • ip地址:10.0.190.50

3.1.2 rpm安装

  1. rpm -i gitlab-ce-8.0.0-ce.0.el7.x86_64.rpm
  • 修改配置即可访问:
  1. sed -i '6s/localhost/https://zqcode.idc.52devops.com/g' /etc/gitlab/gitlab.rb
  • 浏览器访问(初始账户: root 密码: 5iveL!fe)
  • 也支持其他安装方式,例如docker run和源码安装
  • gitlab架构
    gitlab内置了6个组件,都是已封装好的了,提供使用。如下
    ** 前端:Nginx,用于页面及Git tool走http或https协议
    **后端
    :Gitlab服务,采用Ruby on Rails框架,通过unicorn实现后台服务及多进程
    SSHD:开启sshd服务,用于用户上传ssh key进行版本克隆及上传。注:用户上传的ssh key是保存到git账户中
    数据库:目前仅支持MySQL和PostgreSQL
    Redis:用于存储用户session和任务,任务包括新建仓库、发送邮件等等
    Sidekiq:Rails框架自带的,订阅redis中的任务并执行
  • gitlab架构图如下

4、git和gitlab的简单使用

在本章对gitlab日常的代码管理进行解释,方便开发人员的日常使用

4.1 git必备名词

  • Fetch(获取),从远程代码库更新数据到本地代码库。注意:Fetch 只是将代码更新到本地代码库,你需要检出(check out)或与当前工作分支合并(merge)才能在你的工作目录中看到代码的改变。
  • Pull(拉取),从远程代码库更新数据到本地代码库,并与当前工作分支合并,等同于 Fetch + Merge。
  • Push(推送),将本地代码库中已提交(commit)的数据推送到指定的 remote,没有 commit 的数据,不会push
  • HEAD,指向你正在工作中的本地分支的指针
  • Master 分支:主分支,所有提供给用户使用的正式版本,都在这个主分支上发布。
  • Tags(标签):用来记录重要的版本历史,例如里程碑版本
  • Origin:默认的 remote的名称
  • Git clone(克隆版本库):从服务端将项目的版本库克隆下来
  • Git init(在本地初始化版本库):在本地创建版本库的时候使用

4.2 git常用操作

4.2.1安装git图形操作界面工具

windows请移步:https://git-scm.com/https://tortoisegit.org/download/,需要安装git for windows和tortoisegit。

4.2.2配置个人信息

运行刚刚安装的git bash\

  1. git config --global user.name "chuck"
  2. git config --global user.email "chuck@gmail.com"

4.2.3git代码管理

下面以财道社区的代码为例做演示:

  • 注册用户,拉取代码
    gitlab提供了用户管理的功能,使用git下载远程代码之前需要在gitlab上注册用户,gitlab提供了方便切安全的用户管理功能功能,下一章会详细说明。和svn不同的是,git下载远程代码不仅仅是下载所有代码,也会将git仓库的代码和历史更新记录拉取下来,这里要明确git库和svn的目录分离开来。

    添加完用户即可在本地git bash中使用git shell拉取远程代码了,git shell中提供了git clone实现克隆仓库代码,克隆不仅仅是checkout哦!

    要搭配之前使用在gitlab注册的账号和密码,到现在就拥有了全部内容
  • 修改代码并push到远程仓库
    git提供了一个分支的功能,开发人员可以随意创建分支,用来本地开发,当我们创建完一个项目(权限管理会提到)时,必须将master分支设置为protected,此时只有项目所有者或者master权限的人才可以meger代码到mater分支,生产使用时只有master分支使用。
    创建maling分支,修改Readme文件

    meger到master,切换到master查看已经修改了

    在以上操作,我使用的是root账户,拥有master分支管理权限,所以可以直接meger,普通开发人员需要组长或者代码审计人员进行meger,合理规范代码,当然了此处可能涉及meger冲突,第七章会有说明。
  • 将代码push到远程仓库
    代码修改完了,并且在master分支存在了,此刻就需要push到远程仓库,认证仍是user:password,通过git log可以查看更改记录

    这样就完成了一个基本的代码文件的分支,编辑,上传的操作,如想学习更多更详细的,可以参考廖雪峰的教程:http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/
    关于一些git的官方教程:https://git-scm.com/book/zh/v2

5、gitlab权限管理

git提供了方便的命令行的代码管理工具,同时也有强大的gitlab支持,方便管理员和普通开发人员对代码管理,用户管理,项目管理,集成工具,权限管理等功能。下面针对gitlab的权限管理进行说明

5.1group和project

gitlab提供了项目组(group的概念),例如咱们的直播室,培训平台,财道等;每个group都是一个项目的集合,里边包含了具体的每个项目。下面开始创建一个group和三个project

组权限管理,yuanyue为master,maliang为onwer,直接可以对用户在组的层面上进行权限管理。给予不同用户不同的角色

关于组和项目的访问权限也有不同的控制,在创建项目时可以指定,也可以后期更改此选项,建议不要使用public

  • Private – 私有,只有属于该项目成员才有原先查看
  • Internal – 内部,用个Gitlab账号的人都可以clone
  • Public – 公开,任何人可以clone

5.2角色配置

对于项目和组来说,每个用户分别拥有不用的角色,每种角色用户不用的权限,用户可以跨越组,方便对不同项目的管理和维护,具体区别如下:

在这里的建议是,普通开发人员给予developer,项目的小组长给予master用于审计和meger代码,owner是运维这边管理。guest可以给予其他部门使用,reporter可以给予下载代码的测试和安全工程师。

5.3其他权限管理

5.3.1 关闭开放注册

前期可以开放注册,后期要关闭注册功能

5.3.2锁定用户

对于离职或者工作交接的人员,及时锁定账户,长期不使用定期删除账户

5.3.3ssh配置

配置ssh时注意密码或者key的管理,做好安全防护

5.3.4用户登录

不可多个用户使用同一个账号,更不可每个人都给与meger到master权限,合理配置用户权限

6、svn迁移gitlab

在这里你一定质疑svn已经用的很成熟了,为什么还要使用git来管理代码呢,前面提到了九大功能,这里在只对比分布式功能。git是分布式的,但是大多数公司的开发模式还是用客户端-共享服务端模式,也就是在中央服务器上放一个git库作为共享,大家不断往上push最新的代码,用来做个备份。以前也有公司搞过创新,比如所有的组员只需要把代码推给组长即可,大项目的几个组长再负责把整理后的代码统一推到一个大组长那,统一做处理,类似于linux内核的开发模式。先不说这种开发模式是好还是坏,但是svn之类的工具是根本无法有这样的功能的。同理,linux内核几万人,几十万人同时一起开发,如果用svn之类的工具,那管理起来就要爆炸了。

6.1在现有svn环境下迁移git的方式

  • svn现有项目如下:

在这里以直播室项目为例,图中看到src目录里有两个大项目,每个项目里有n个小项目,那么问题来了,我应该将此svn库转成1个git库,还是2个git库,还是n个小项目的库?答案是取决于你自己,之前公司只是给了每个组一个svn目录,而目录里你根据项目需要分了n多个小项目,那现在是你重新组织项目结构的好时机。假如整个svn目录都导成一个git库:那跟之前的用法一样,兼容性也比较好。假如根据zhibo-project和px-operation-project导成两个项目,好处就是两个项目可以分别开分支,打tag,也更灵活。缺点是你之前的编译,部署脚本可能需要相应的修改以下。假如你想把其中每个子项目都导成一个库,那样不太好,因为维护起来太麻烦,毕竟整个大项目只有几个人维护;假如类似这样的目录结构是几十人,甚至百人来维护的,那肯定细分一下更好。假如其中某个目录有特殊的权限,比如只允许某些人提交,那需要将相应的目录导成一个git项目,本例中将整个项目转换为一个group,目录为group下的一个project。

  • 开始迁移
    和之前一样,使用git bash来管理代码库,配置个人信息等。通过通过git shell来实现将原有的svn代码下载到git本地,此时git和svn密码一一对应
  1. git svn clone svn://svn.tool.52devops.com/wlfw/Java/Zhibo2.00/src/zhibo-project

到现在为止本地已经有了原有代码,需要push到远程仓库

  • gitlab仓库管理
    创建zhibo的group和相应的两个project


    在zhibo-project目录中加入远程库并push:
  1. git remote add origin
  2. git push --set-upstream origin master


到此,代码的导入就结束了,这时我们去gitlab服务端确认,的确导入成功了

7、git使用常见问题

7.1 怎样在每次 Push 时不用重复输入密码?

如果使用 SSH 方式进行推送,您需要配置 SSH 公钥后进行操作,详情请阅读 SSH 公钥配置文档

7.2 如何设置分支的提交权限,让部分人可以提交?

你可以用保护分支功能来划分不同成员对不同分支的操作权限, 参见 分支管理 的保护分支章节

7.4 Push一直提示 “Permission denied (publickey)

  • 确认您的 push 方式,如果是 SSH 方式请检查你的 SSH 公钥是否正确(如果您有多个私钥,请使用 ssh-add 命令来指定默认使用的私钥); HTTPS 方式请检查密码及用户名是否正确。
  • 对目标分支是否有写权限。

7.5 什么叫rebase?它和merge有什么不同?

技术上的解释在:http://gitbook.liuhui998.com/4_2.html 官方解释:https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA 最后,建议只有在完全理解rebase的概念的时候才允许执行这个命令,否则团队应该禁用rebase。我个人的建议是,假如你认为自己稍微懂得什么是rebase,那么就不要用rebase;如果你认为你rebase了解的还可以了,差不多70%~80%吧,那么就不要用rebase;如果你认为rebase你了解到了100%,那么就可以用了。所以,大部分的团队应该禁用rebase

7.6 很多远程分支明明已经被删除了,可是本地还是显示存在,如何清理这样的分支?

git remote prune origin

7.7 如何在merge request(pull request)的过程解决冲突?

在修复完一个bug或者开发完一个需求的时候,将代码合入主干之前需要merge request,但是这个时候很容易出现冲突,原因在于,在你开发这个需求的过程中,已经有其他的小伙伴把代码合入了主干,而恰巧他的代码和你的冲突,导致你merge request不成功。
问题发现了,解决方案也很简单:在准备发起merge request之前,将主干的最新代码更新到你本地的分支,并解决冲突,然后再发起merge request。具体操作在下面修复bug的流程中有详细解释。

7.8 如何修复bug的流程?

修复bug的流程简单来说,先pull最新的代码到本地,然后在本地建一个bug分支,在bug分支上开发并提交,随时push保证本地的工作保存到服务器上。开发结束后,在gitlab上发起一个merge request,相关人员就会给你审核代码。审核通过之后,项目相关负责人会把你的代码合入主干,从而开始下一步的测试,部署,上线等流程。
注意 1,假如二人合作开发解决bug,那第二个人不需要新建bug分支,等第一个人建分支并push后,pull最新的代码并切换到第一个人建立的分支即可。
注意 2,项目管理者应该建立具体的分支命名规则,比如使用类似bug-{jiraID}-{描述} 或者feature-{jiraID}-{描述}类似的命名规则,
例1 修改bug: bug-NEWZHIBO-11-直播室不能发言(git的分支名允许中文,但是建议不要使用中文)。
例2 开发新需求: feature-NEWZHIBO-11-直播室新外部接口提供
例3 其他任务: task-修改系统设置

上图中我们修好了bug,并push到了服务端,这时候gitlab会提示我们如何发起merge request请求,于是访问gitlab里的merge request,创建merge request。
相关人员会给你代码审核,如果不通过你需要重新改代码并重新发起请求;如果通过了相关人员会通过,这样你的代码就会自动合并到主干里。

假如此页面提示有代码冲突,则需要将主干的代码更新到分支上,进行解决冲突,然后重新push
上图中,先切换到本地master分支,pull更新到最新
然后切换到本地开发分支,将master的代码合并过来,出现冲突提示后,解决冲突。

1
未经许可,不得转载,否则将受到作者追究,博主联系方式见首页右上角

该文章由 发布

这货来去如风,什么鬼都没留下!!!
发表我的评论
取消评论
代码 贴图 加粗 链接 删除线 签到