Git与GitLab的企业实战
第1章 Git概述
Git是一个免费的、开源的分布式版本控制系统,可以快速高效地处理从小型到大型的各种项目。
Git易于学习,占地面积小,性能极快。 它具有廉价的本地库,方便的暂存区域和多个工作流分支等特性。其性能优于Subversion(svn)、CVS、Perforce和ClearCase等版本控制工具。
1. 何为版本控制
版本控制是一种记录文件内容变化,以便将来查阅特定版本修订情况的系统。
版本控制其实最重要的是可以记录文件修改历史记录,从而让用户能够查看历史版本,方便版本切换。
2. 为什么需要版本控制
1.管理代码,可以控制到每一个代码是谁写的--方便后期排除问题
2.统计工作流,记录开发的流程,方便回退
3.从个人开发到团队开发,可以创建不同分支并行开发,统一进行管理
第2章 Git安装
官网地址: https://git-scm.com/或Releases · git-for-windows/git · GitHub
查看GNU协议,可以直接点击下一步。
Standalone Installer和Portable (“thumbdrive edition”)区别
Standalone Installer:
这是最常见的安装方式,会将 Git 安装到 Windows 系统目录中,同时添加 Git Bash、Git GUI、Git CMD 等工具。
安装后,你可以在命令行或 Git Bash 中直接使用 Git 命令。
适用于大多数用户,特别是在本地机器上进行日常开发时。
Portable (“thumbdrive edition”):
这个版本是可便携的,适合在 USB 驱动器等可移动媒体上携带。
安装过程不会将 Git 添加到系统目录中,而是将所有文件都放在安装目录中。
适用于需要在不同计算机之间移动的情况,你可以将整个 Git 工具和仓库都放在一个移动设备上,方便在不同机器上使用相同的 Git 版本。
选择哪个版本主要取决于你的使用场景:
如果你只在自己的机器上进行开发,并且不需要在不同的机器上携带 Git,那么 “Standalone Installer” 是一个不错的选择。
如果你经常在不同的计算机上工作,或者需要在移动设备上携带 Git,那么 “Portable (“thumbdrive edition”)” 可能更适合你。
无论你选择哪个版本,它们都提供了相同的 Git 功能,只是安装方式和一些配置略有不同。
选择Git安装位置,要求是非中文并且没有空格的目录,然后下一步。
Git选项配置,推荐默认设置,然后一直下一步。
点击Finsh按钮,Git安装成功!
右键任意位置,在右键菜单里选择Git Bash Here即可打开Git Bash命令行终端。
在Git Bash终端里输入git --version查看git版本,如图所示,说明Git安装成功。
第3章 Git常用命令
命令名称 | 作用 |
---|---|
git config --global user.name 用户名 | 设置用户签名 |
git config --global user.email 邮箱 | 设置用户邮箱 |
git init | 初始化本地库 |
git status | 查看本地库状态 |
git add 文件名 | 添加到暂存区 |
git commit -m "日志信息" 文件名 | 提交到本地库,添加备注 |
git reflog | 查看历史记录 |
git reset --hard 版本号 | 版本穿梭 |
第4章 Git集成IDEA常用操作
这里使用Gitee操作 其他GitHub基本一致
1 将代码提交到远程仓库
自己写了一段代码后,想要将自己的代码提交到远程仓库中进行管理
1)创建一个项目
如果不显示的化,就初始化一些git工程
2)安装gitee插件
3)添加gitee的账户
邮箱可以在gitee中设置
4) 将代码提交到远程仓库
提交成功
2 将其他人代码拉取下来
拉取其他人在远程仓库写好的代码
1)创建一个文件夹然后打开命令窗口
2)找到项目复制地址
输入命令
git clone 地址
3.IDEA右下角常用按钮
第5章 GitLab的部署与使用
1.为什么使用GitLab-开发运维一体化
①开源
②可以自己本地部署,安全性高
③功能强大,包含自动部署流水线功能
2. 部署安装GitLab
使用git,还需要一个远程代码仓库。常见的github、gitee这种远程代码仓库,公司中一般不会使用,因为他们是使用外网的,不够安全。一般企业都会搭建一个仅内网使用的远程代码仓库,最常见就是 GitLab。
2.1 安装部署
GitLab一般由公司的运维人员安装部署,开发人员只需要申请账号和相应权限即可,在这里我们在虚拟机上自己安装GitLab社区版体验一下。
2.1.1 安装准备
1)需要开启ssh:(已开启可跳过)
sudo systemctl status sshd sudo systemctl enable sshd sudo systemctl start sshd
2)关闭防火墙
sudo systemctl stop firewalld sudo systemctl status firewalld
2.1.2 rpm 包安装
1)上传安装包
下载地址:Nexus Repository Manager
安装包较大,建议下载好手动上传服务器。这里上传到/software下
百度网盘:
链接:https://pan.baidu.com/s/1dwFH5DtSbG7-VQwZKI_RxA?pwd=duo1
提取码:duo1
2)编写安装脚本
cd /sofwin 利用文件工具将rpm安装包拉进去
脚本内容如下:
sudo yum install -y curl policycoreutils-python openssh-server perl
sudo rpm -ivh gitlab-jh-16.6.1-jh.0.el7.x86_64.rpm
安装完毕后是这样
3)修改external_url
sudo vim /etc/gitlab/gitlab.rb
进入编辑器后
输入/external_url 回车 然后输入n下一个一直找(N是上一个)
找到标红的改成自己虚拟机地址然后保存退出
4)修改host(可选 如果不想使用80)
编辑gitlab.yml
[atguigu@hadoop104 ~]$ sudo vim /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml.example
找到gitlab.host修改为如下内容
gitlab: \## Web server settings (**note:** host is the FQDN, do not include http://) host: hadoop104 port: 80 https: false
保存退出
修改文件名称
[atguigu@hadoop104 ~]$ sudo mv /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml.example /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml
5)启动初始化
执行过程大概需要3分钟
sudo gitlab-ctl reconfigure
6)重装需要彻底卸载
1 卸载gitlab
[atguigu@hadoop104 opt]$ sudo rpm -e gitlab-jh-16.6.1
2 删除gitlab文件
[atguigu@hadoop104 opt]$ sudo rm -rf /etc/gitlab [atguigu@hadoop104 opt]$ sudo rm -rf /var/opt/gitlab [atguigu@hadoop104 opt]$ sudo rm -rf /opt/gitlab
3 重装如果卡在sudo gitlab-ctl reconfigure配置命令上,可以使用另外一个窗口执行
sudo systemctl restart gitlab-runsvdir
2.1.3 启停命令
当出现这个子后代表初始化成功了,然后进行启动
1)启动命令
sudo gitlab-ctl start
2)停止命令
sudo gitlab-ctl stop
2.1.5 修改 root 密码
1)访问Web页面
默认使用80端口,直接浏览器输入安装服务器的hostname或ip:http://192.168.110.210/
2)查看root密码
账号root,密码将随机生成并在 /etc/gitlab/initial_root_password 中保存24 小时:
sudo cat /etc/gitlab/initial_root_password
修改密码:
2.1.6 设置简体中文
保存后刷新一下,就变成中文了
3. 使用GitLab完成团队管理
去到一家公司,应该是已经有了GitLab平台,运维人员拥有root管理员账号。而作为一名普通的开发人员,你的leader和同事都拥有各自的GitLab账号和不同权限。入职后,你只需要申请开通GitLab账号和对应权限,不需要你来操作。
3.1 创建用户
为了更符合公司实际,我们假设有一个研发组,研发人员 zhangsan,项目组组长wangwu
申请一个wangwu的管理员账号
创建一个zhangsan 普通员工的账号:
设置密码同上
3.2 创建群组
在gitlab里,可以创建出组、组下的子组。在小公司里可以看见gitlab里边会创建出后端,大数据等等一系列组。尽量不要使用中文创建组名, 可以在组信息中的备注编写中文描述以及中文组名, 组内人员名称也尽量用全拼命名。
对于人员权限以及角色的控制也比较简单,有如下五种:
Ø Owner:最高权限,谁去创建组,这个组就被谁拥有,它可以开除管理员,但管理员无法操作owner的角色。
Ø Maintainer:(管理员-只是具备sudo权限的用户)管理员一般是给小组的组长,或者是给产品线的总监设定。
Ø Developer:是干活的人,就是写代码的程序员,可以进行代码的上传以及代码的下载,不能下载其他的组内的代码,只能下载它们组的代码。
Ø Repoter:比如现在有需求,其他组的大牛到我们组过来指导工作,要审视我们的代码,人家就提出需要一个权限,我不能给它developer因为它会改你代码,其他组的人不能改我们组的代码,所以就给一个repoter权限,他只能看,只读权限。
Ø guest:不用看,匿名,直接去掉。一般出现在从ldap中把离职人员的信息删掉,再去gitlab查这个人的时候,它就是一个guest用户(匿名)需要再到gitlab把它删掉(不删也没事)。
下面,我们假设研发部群组是rdc,下属后端组、前端组、大数据组等子群组:
1)创建研发中心群组rdc
使用wangwu管理员创建群组
2)创建大数据组
在研发中心组下,再创建一个大数据组(当然,其他还会有后端组、前端组等):
当然,根据公司情况还可以进一步在数据组下面细分子组(比如:离线、实时、湖等),这里我们就不再细分。
创建大数据组:
将zhangsan添加为普通的开发人员:
现在我们就有一个顶级群组rdc,其下有一个子群组bigdata,组内有管理员wangwu,开发人员zhangsan。
4.使用IDEA兼容GitLab
1)安装 GitLab 插件
2) 添加用户
3)获取 GitLab 个人令牌
创建后,可以查看和复制生成的token:
4)设置ssh免密登录
ssh-keygen -t rsa -C zhangsan@163.com
输入后一直点回车就可以 当出现我模糊那种框框就可以了
找到秘钥 在c盘用户下的ssh文件夹
将ssh秘钥添加到用户上
5)修改默认分支的保护策略(必须是root的用户)
6)推送
成功:
注意:如果之前是git项目后没有vcs,变成git了可以进行恢复
5 在GitLab上创建项目
1)新建项目
2)选择一个适合的创建方式
创建完毕后,该组下的成员自动都在这个项目里
第6章 企业项目构建与开发分支
1. GitFlow工作流介绍
在项目开发过程中使用 Git 的方式常见的有:
1.1 集中式工作流
所有修改都提交到 Master 这个分支。比较适合极小团队或单人维护的项目,不建议使用这种方式。
1.2 功能开发工作流
功能开发应该在一个专门的分支,而不是在 master 分支上。适用于小团队开发。
1.3 GitFlow工作流
公司中最常用于管理大型项目。为功能开发、发布准备和维护设立了独立的分支,让发布迭代过程更流畅。
1.4 Forking工作流
在 GitFlow 基础上,充分利用了 Git 的 Fork 和 pull request 的功能以达到代码审核的目的。一般用于跨团队协作、网上开源项目。
2. 各分支功能介绍
2.1 主干分支 master
主要负责管理正在运行的生产环境代码,永远保持与正在运行的生产环境完全一致。为了保持稳定性一般不会直接在这个分支上修改代码,都是通过其他分支合并过来的。
2.2 开发分支 develop
主要负责管理正在开发过程中的代码。一般情况下应该是最新的代码。
2.3 功能分支 feature
为了不影响较短周期的开发工作,一般把中长期开发模块,会从开发分支中独立出来。 开发完成后会合并到开发分支。
2.4 准生产分支(预发布分支) release
较大的版本上线前,会从开发分支中分出准生产分支,进行最后阶段的集成测试。该版本上线后,会合并到主干分支。生产环境运行一段阶段较稳定后可以视情况删除。
2.5 bug 修理分支 hotfix
主要负责管理生产环境下出现的紧急修复的代码。 从主干分支分出,修复完毕并测试上线后,并回主干分支和开发分支。并回后,视情况可以删除该分支。
3. 分支管理
3.1 不同分支的提交与合并
(1)新建分支和切换分支
创建一个feature分支
方案1:使用idea直接创建分支然后提交
方案2:在GitLab中创建分支
切换到feature分支
(2)不同分支提交代码与合并
首先在feature分支编写第一个模块的模拟代码,并提交
(3)合并feature到feature2分支
将分支改一下
审查测试通过之后,完成合并
第7章 冲突提交
实际单个模块的开发往往不是单独一个人来进行操作,当多个人协同开发相同的一个项目时,就会涉及到提交冲突的问题。
1. 不同人修改不同文件
先pull
Git会智能识别,采用merge合并命令,拉取远端文件到本地进行合并。
然后commit
然后push
2. 不同人修改同文件的不同区域
先pull
Git会智能识别,采用merge合并命令,拉取远端文件到本地进行合并。
然后commit
然后push
3. 不同人修改同文件的相同区域
先pull
无法直接采用merge命令,需要人为判断哪些作为最终的结果来保留
然后回弹出框
中间是处理后的代码
4. 同时变更文件名和文件内容
先pull
然后commit
然后push
5. 不同人把同一文件改成不同的文件名
先pull
会导致报错,之后需要用户自己解决保留哪些文件。
(5)使用命令解决最终的冲突
C:\mybigdata\project\gitlab_demo>git status #删除掉报红找不到的文件 C:\mybigdata\project\gitlab_demo>git rm src/main/java/com/atguigu/Module1Plus.java
然后commit
最后重新选择正确的代码push到仓库
6.自己工作中常用命令提交
1.创建分支
git checkout -b 分支名
2.切换分支
git checkout 分支名
3.合并 将dev的内容合并到dev-wt中 (这里不涉及审核什么的时候用)
git checkout dev-wt
git pull
git merge dev
4.一个分支dev的一次提交合并到另一个分支dev-wt中
git checkout dev
//先将dev-wt的最新代码拉取
git pull origin dev-wt
//解决冲突后进行提交
记录下提交的标识
//切换到要提交的复制 dev-wt
git checkout dev-wt
//输入dev提交分支的标识
git cherry-pick c7cca26d48c52583efa75a673970a6e87ad7d6d6
//提交
git push
3和4区别?
3是全部进行合并
4是对一小部分进行合并
第8章 GitLab功能拓展
这块没进行测试 有兴趣的可以试试
流水线,这个我们一般都是公司自己封装好了
前端,后端提交到git上就自动化部署---跟这个差不多。 (哈哈哈,这个我只会用,暂时不太懂)