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）上传安装包
安装包较大，建议下载好手动上传服务器。这里上传到/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上就自动化部署---跟这个差不多。 （哈哈哈，这个我只会用，暂时不太懂）