GitLab环境搭建及Git简单使用
GIT
什么是Git?
GIt是一个免费开源的分布式版本控制系统,具有闪电般的速度和及小的占用空间。他同Subversion,CVS,Perforce和ClearCase等SCM工具相比,具有更加轻便的本地分支,方便实现区域分段和多个工作流的操作。
GitLab和Git是什么关系?
All plans include Git repository management, code reviews, issue tracking, built-in GitLab CI for continuous integration and delivery.
总的来说,GitLab就是GitServer的集成环境包,并添加了GitWebServer、代码审查、CI、问题追踪等功能。
GitLab环境搭建
要求
操作系统
- Ubuntu
- Debian
- CenterOS
- Red Hat企业版
- Scientific Linux
- Oracle Linux
不支持的Unix发行版本
- Arch Linux
- Fedora
- FreeBSD
- Gentoo
- macOS
非Unix操作系统如Windows
GitLab是针对Unix操作系统开发的。
Ruby版本
Ruby(MRI)2.3。在GitLab 8.13版本中停止对低于Ruby2.3(2.1,2.2)的支持。
硬件要求
存储
存储器大小取决于GitLab对应的数据仓库的大小。如果系统可以灵活的扩展存储器的空间,推荐使用LVM进行安装,以便再需要的时候可以添加更多的硬盘存储器。
除了本地硬盘驱动器,您还可以挂在支持网络文件的存储系统NFS协议的卷。该卷可能位于服务器上或者网络连接存储器(NAS)等设备上。
GitLab的运行速度主要受硬盘寻道时间的限制。推荐使用更快的硬盘驱动(7200rpm及以上)或固态驱动器(SSD)来提高GitLab的响应能力。
中央处理器CPU
- 单核运行时支持多达100个用户,但考虑到后台所有的作业都运行在同一个内核上,应用程序运行速度将受到很大影响。
- 2核心是建议的核心数,并最多支持多达500个用户。
- 4核心最多支持2000个用户
- 8核心最多支持5000个用户
内存
- 1GB RAM + 3GB Swap交换空间,但强烈反对以该数值作为配置。
- 2GB RAM + 2GB Swap交换空间,支持多达100个用户,但运行时会非常缓慢。
- 4GB RAM 是安装推荐的内存大小,最多支持100个用户。
- 8GB RAM 最多支持1000个用户
GitLab Runner
强烈简易不要在计划安装GitLab的同一台服务器上安装GitLabRunner。GitLabRunner可能会根据决定如何配置GitLab Runner 以及在CI环境中使用哪些工具来构建应用程序上消耗大量的内存空间。
数据库
目前支持 PostgreSQL(推荐)和MySQL/MariaDB。
如果要单独运行数据库,则每个用户的大小约位1MB。
支持的Web浏览器
支持Firefox 、 Chrome/Chromeium 、Safari 和Microsoft浏览器(Microsoft Edge 和IE 11)。
测试环境配置
- Oracle VM VirtualBox
- Ubuntu Kylin 16.10
安装流程
Ubuntu系统安装及配置不做详细介绍。假设当前已经安装好Ubuntu并以管理员身份登录。安装流程参照GitLab官方Ubuntu集成文档。
一、安装GitLab-CE所需的依赖包
1 | sudo apt-get install curl openssh-server ca-certificates |
这里我们不安装SMTP服务器postfix
,而使用QQ企业邮箱的SMTP服务器,所以不需要安装 postfix
包。
- openssh-server : 用于创建Git SSH连接
- ca-certificates: 用于SSH 根证书认证
二、添加GitLab-CE包服务,并通过清华镜像源安装
1 | curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash |
1 | # 在文件中添加 |
1 | # 更新源列表 |
等待安装
1 | # 启动服务 |
浏览器输入 localhost 打开 GitLab Web主页 设置用户名为root的管理员密码,并登录
三、配置GitLab IP、域名供内网访问
默认安装完成后,地址为当前计算机用户名,需要修改为内网IP地址或绑定对应域名进行DNS解析。
更改GitLab根域名
1 | sudo gedit /etc/gitlab/gitlab.rb |
将
external_url
修改为想要绑定的域名地址,这里我修改为http://gitlab.itsuantou.com
。查看当前计算机内网IP地址
这里显示的当前IP地址为 10.0.2.15
,该地址是不存在在内网中的,只存在于当前虚拟机同当前服务机的内网环境(因为网络模式为NAT)。将网络连接设置为桥接即可。
再查看IP地址
配置DNS,添加A记录指向内网IP
重启GitLab服务配置
1
sudo gitlab-ctl reconfigure
内网环境访问 http://gitlab.itsuantou.com
四、配置SMTP服务器至QQ企业邮箱
1 | ### Email Settings 打开邮件设置 |
重新加载配置
1 | sudo gitlab-ctl reconfigure |
测试是否连接成功
个人中心 - > MainSettings - > Email 填写邮箱 - >保存更新资料
这时GitLab会执行邮箱验证任务,向 SMTP服务器推送邮箱验证的邮件,并投递到填写的目标邮箱中.
投递成功:
GitLab使用
创建用户(管理员权限)
因内网Git仓库为公司内部员工进行应用和管理,所以不开放注册功能。
打开管理员面板 - > Users - >New User
填写账户资料
一般填写完Account项即可,权限位默认权限。
点击Create User
则向Account项中填写的邮箱发送一封修改密码的验证邮件,由用户个人点击并重置密码即可.
- 接收重置密码邮件
- 设置密码并登录
创建组
约定:公司项目均需创建组(Group),并在小组中进行项目的创建。
创建项目
Import project from 项可选择导入的Git 仓库地址,可选项.
Git相关配置
Git安装
- Mac :
brew install git
- Windows: 访问 https://git-scm.com/ 点击下载并默认安装即可.
本地Git仓库通过SSH连接GitLab
在GitLab中,我们强制开启了SSH 认证方式进行对Git服务器的连接.所以我们需要在本地生成SSH Key,并将公钥配置到GitLab中.
- 打开GitLab,并登录.进入到个人配置页面 - > SSH Keys
- 查看当前用户的SSH 公钥
- Windows
type %userprofile%\.ssh\id_rsa.pub
- GNU/Linux/macOS /PowerShell
cat ~/.ssh/id_rsa.pub
- 如果不存在,则生成一个SSH公钥
- GNU/Linux/macOS:`ssh-keygen -t rsa -C “GitLab” -b 4096
- Windows 需要下载PuttyGen并且阅读文档创建SSH Key
生成密钥的过程可默认配置.
将公钥内容Copy 并粘贴到个人配置的SSH Keys - > Add Key即可完成配置
本地测试SSH 配置是否成功:
ssh -T git@gitlab.itsuantou.com
出现Welcome to GitLab, UserName
表示配置成功
通过上面的配置,我们就可以直接通过SSH地址访问远端的项目了.
AndroidStudio中的GitPlugin使用
- git clone 项目到文件夹中
1
➜ FeiDan git clone git@gitlab.itsuantou.com:Android-Developer/FeiDan.git
- 使用AndroidStudio 打开Clone下来的Android项目
- 点击设置 cmd + , 打开Version Control 面板. 设置当前项目版本控制由Git 控制
显示 git: master 表示配置成功.
GitPlugin的使用
- cmd + k : commit(本地提交)
- cmd + t : Update Project 可选择更新类型(推荐Rebase)
- cmd + shift + k : push 推送到Remote
也可对单个文件进行操作
在工作窗口中选择Version Contro 弹出 Git 管理面板
使用SourceTree管理Git
下载安装SourceTree
- 点击进入官网 , 选择下载Source Tree 安装
- 新仓库 -> 从Url克隆 ->填写 SSH URL ->设置本地Git路径 -> 克隆
Git Flow
就像代码需要代码规范一样,代码管理同样需要一个清晰的流程和规范
Vincent Driessen 同学为了解决这个问题提出了 A Successful Git Branching Model
下面是Git Flow的流程图
上面的图你理解不了? 没关系,这不是你的错,我觉得这张图本身有点问题,这张图应该左转90度,大家应该就很用以理解了。
Git Flow常用的分支
Production 分支
也就是我们经常使用的Master分支,这个分支最近发布到生产环境的代码,最近发布的Release, 这个分支只能从其他分支合并,不能在这个分支直接修改
Develop 分支
这个分支是我们是我们的主开发分支,包含所有要发布到下一个Release的代码,这个主要合并与其他分支,比如Feature分支
Feature 分支
这个分支主要是用来开发一个新的功能,一旦开发完成,我们合并回Develop分支进入下一个Release
Release分支
当你需要一个发布一个新Release的时候,我们基于Develop分支创建一个Release分支,完成Release后,我们合并到Master和Develop分支
Hotfix分支
当我们在Production发现新的Bug时候,我们需要创建一个Hotfix, 完成Hotfix后,我们合并回Master和Develop分支,所以Hotfix的改动会进入下一个Release
Git Flow如何工作
初始分支
所有在Master分支上的Commit应该Tag
Feature 分支
分支名 feature/*
Feature分支做完后,必须合并回Develop分支, 合并完分支后一般会删除这个Feature分支,但是我们也可以保留
Release分支
分支名 release/*
Release分支基于Develop分支创建,打完Release分之后,我们可以在这个Release分支上测试,修改Bug等。同时,其它开发人员可以基于开发新的Feature (记住:一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
发布Release分支时,合并Release到Master和Develop, 同时在Master分支上打个Tag记住Release版本号,然后可以删除Release分支了。
维护分支 Hotfix
分支名 hotfix/*
hotfix分支基于Master分支创建,开发完后需要合并回Master和Develop分支,同时在Master上打一个tag
推荐合并方式 ->Rebase
假设你现在基于远程分支”origin”,创建一个叫”mywork”的分支。
1 | $ git checkout -b mywork origin |
现在我们在这个分支做一些修改,然后生成两个提交(commit).
1 | $ vi file.txt |
但是与此同时,有些人也在”origin”分支上做了一些修改并且做了提交了. 这就意味着”origin”和”mywork”这两个分支各自”前进”了,它们之间”分叉”了。
在这里,你可以用”pull”命令把”origin”分支上的修改拉下来并且和你的修改合并; 结果看起来就像一个新的”合并的提交”(merge commit):
但是,如果你想让”mywork”分支历史看起来像没有经过任何合并一样,你也许可以用 git rebase:
1 | $ git checkout mywork |
这些命令会把你的”mywork”分支里的每个提交(commit)取消掉,并且把它们临时 保存为补丁(patch)(这些补丁放到”.git/rebase”目录中),然后把”mywork”分支更新 到最新的”origin”分支,最后把保存的这些补丁应用到”mywork”分支上。
当’mywork’分支更新之后,它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除. (请查看 git gc)
现在我们可以看一下用合并(merge)和用rebase所产生的历史的区别:
在rebase的过程中,也许会出现冲突(conflict). 在这种情况,Git会停止rebase并会让你去解决 冲突;在解决完冲突后,用”git-add”命令去更新这些内容的索引(index), 然后,你无需执行 git-commit,只要执行:
1 | $ git rebase --continue |
这样git会继续应用(apply)余下的补丁。
在任何时候,你可以用–abort参数来终止rebase的行动,并且”mywork” 分支会回到rebase开始前的状态。
1 | $ git rebase --abort |