标签：实战篇 git 代码 就业 Arc Git TestRepo main 分支

第一章 版本控制系统

1.1 SVN 集中式版本控制系统

​ 所有的代码版本都存放在 SVN Server 上，网络有问题就访问不了，所有内柔都在SVN Server上进行，Client只负责请求，协作必须在本地局域网开发。

1.2 GIT 分布式版本控制系统

​ 每个客户端都有一个仓库，独立开发。

第二章 Git的基本内容回顾

2.1本地与远端仓库通信

​ 以GitHub为例实现本地仓库与远程仓库的通信，随便创建一个远程仓库：

​ 安装Git设置提交代码的签名（用户名密码）和SSH密钥

git config --global user.name "" 
git config --global user.email ""
ssh-keygen -t rsa -C "注册账号的邮箱名字"

​ 生成的密钥的正常情况（全部默认）生成在C:\Users\用户名\.ssh下，复制id_rsa.pub（公钥）中的内容，

​ 测试是否和GitHub联通，如果有报错$ ssh: Could not resolve hostname github.com: Name or service not known请检查自己的网络代理设置。

2.2 回忆Git的命令

2.2.1 git clone

​ 使用git clone 仓库地址将远程分支 Clone 到本地

​ 在拉取到本地之后默认会将远程仓库的名称设置为origin

​ 生成本地默认一个主干分支master追踪origin/master（或main分支）

2.2.2 向远程仓库推送代码的流程

2.2.3 git 各个阶段修改回退撤销操作

2.3 冲突解决

​ 当本地分支与远端分支不同步（提前或者落后n个提交），在进行 push 的时候就回无法推送。

2.3.1 修改的不同位置的代码

​ git 会智能合并

2.3.2 修改相同位置的代码

​ 需要手动进行修改，修改之后需要在进行 commit ，以便让 git 保存完整的提交更改。

[root@localhost TestRepo]# cat README.md 
<<<<<<< HEAD
B更改了Readme
=======
This is A
>>>>>>> c9d153de333f310ba9af1945c64026de42238b73
    
// 去掉Git生成的提示，手动更改代码，在前人的基础上修改内容

This is A ，B也干了，还解决了冲突

[root@localhost TestRepo]# vim README.md 
[root@localhost TestRepo]# gitstatus
bash: gitstatus: 未找到命令...
[root@localhost TestRepo]# git status 
# 位于分支 main
# 您的分支和 'origin/main' 出现了偏离，
# 并且分别有 1 和 1 处不同的提交。
#   （使用 "git pull" 来合并远程分支）
#
# 您有尚未合并的路径。
#   （解决冲突并运行 "git commit"）
#
# 未合并的路径：
#   （使用 "git add <file>..." 标记解决方案）
#
#	双方修改：     README.md
#
修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）
[root@localhost TestRepo]# git add .
[root@localhost TestRepo]# git status 
# 位于分支 main
# 您的分支和 'origin/main' 出现了偏离，
# 并且分别有 1 和 1 处不同的提交。
#   （使用 "git pull" 来合并远程分支）
#
# 所有冲突已解决但您仍处于合并中。
#   （使用 "git commit" 结束合并）
#
# 要提交的变更：
#
#	修改：      README.md
#
[root@localhost TestRepo]# git commit -m "B解决冲突"
[main 742e7a4] B解决冲突
[root@localhost TestRepo]# git push

2.4 本地分支管理

2.4.1 本地分支创建和合并

​ 列出大致拉取代码到本地 -> 创建本地分支 -> 合并分支 -> 完成推送这一流程的时间线。下面的示例中是将dev分支合并到mian分支上在进行推送的，如果想直接将dev分支的内容推送到mian上面，则需要指定远端的分支（因为本地签出的分支并不追踪远端）即git push origin dev:master；若创建的本地分支有内容未合并，在删除时需要进行强制操作，即git branch -D devBranchA。

// 1、创建本地分支
Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (main)
$ git checkout -b devBranchA
Switched to a new branch 'devBranchA'
// 2、进行开发
Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (devBranchA)
$ vim README.md
// 3、提交更改到本地
Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (devBranchA)
$ git status
On branch devBranchA
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (devBranchA)
$ git add .

Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (devBranchA)
$ git commit -m "A在自己分支上写的"
[devBranchA a4efd3b] A在自己分支上写的
 1 file changed, 3 insertions(+)
// 4、返回main分支合并更改
Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (devBranchA)
$ git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.

Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (main)
$ git merge devBranchA
Updating 71591b3..a4efd3b
Fast-forward
 README.md | 3 +++
 1 file changed, 3 insertions(+)
 // 5、推送更改到远端
 Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (main)
$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 379 bytes | 379.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To github.com:Purearc/TestRepo.git
   71591b3..a4efd3b  main -> main
// 6、删除不再需要的分支
Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (main)
$ git branch -d devBranchA
Deleted branch devBranchA (was a4efd3b).

2.4.2 本地分支合并冲突解决方案

分支的冲突同样也是分为Auto Merge和Auto Merge failed两种，后者需要手动进行更改。

​ 下面是整个的流程，经常从远端 pull 同步代码是个好习惯。

B：
git pull
// 获得V1版本的代码
// 进行开发并推送自己的更新到远端
git push

A：
git pull
// 1、获得V1版本的代码
git checkout -b dev
// 2、完成功能开发合并代码 
git merge
git push
remote: Enumerating objects: 18, done.
remote: Counting objects: 100% (17/17), done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 11 (delta 0), reused 11 (delta 0), pack-reused 0
Unpacking objects: 100% (11/11), 1.37 KiB | 31.00 KiB/s, done.
From github.com:Purearc/TestRepo
   f27b0ea..9e255a3  main       -> origin/main
Auto-merging Application.java
CONFLICT (content): Merge conflict in Application.java
Automatic merge failed; fix conflicts and then commit the result.
// 3、手动解决冲突
git add
git commit->git push

​ 需要手动解决冲突的示例：

// 这是一个启动类
@SpringBootApplication()
@Aspect

// 这是一个启动类
@SpringBootApplication

// 这是一个启动类
<<<<<<< HEAD
@SpringApplication()
@Aspect
=======
@SpringBootApplication
>>>>>>> 9e255a33b02fff50131758f7bb9101ae997eafa0

2.5 远程分支管理

在远端创建一个新的分支之后 pull 一下就可以看到远端分支已经更新，但是本地没有分支跟踪，通过git checkout -b 本地分支 origin/远端分支就可以完成创建并跟踪，也可以在本地的某个分支使用git checkout -u origin/本地分支进行后期追加跟踪。

Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (main)
$ git pull
From github.com:Purearc/TestRepo
 * [new branch]      dev        -> origin/dev
Already up to date.

Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (main)
$ git checkout -b dev origin/dev
Switched to a new branch 'dev'
branch 'dev' set up to track 'origin/dev'.

Arc@Arc MINGW64 /d/GitLocalRepo/TestRepo (dev)
$ git branch -vv
* dev    aad1a91 [origin/dev] B更改了Application
  devEnv c501fc0 A的更改落后于B
  main   8d170a9 [origin/main: ahead 2] A解决冲突

2.6在IDEA或Github Desktop上使用Git

第三章 Git的工作流

​ 在我们的开发流程中，我们采用了一种结构化的Git工作流，以确保代码的稳定性和可持续性。首先，我们从稳定的master分支创建一个dev分支，用于日常开发。开发完成后，从dev分支中拉出一个release分支，用于准备和测试新版本。在所有测试通过后，将release分支的代码合并回master分支，标志着版本的发布。之后，我们开始新一轮的开发，再次从master分支创建dev分支，如此循环往复，确保每个版本的迭代都有条不紊。

​ 以下图为例，大体流程为

1、创建个人本地开发分支：git checkout-b feature/add_new_line origin/dev
2、个人本地分支推送到远程分支：git push origin feature/.add_new_line:feature/add_new_line
3、提交个人远程代码分支和目标代码合入分支的MR,相关负责人进行CR
4、相关负责人提出意见，本地修改相应的代码，推送到对应的远程代码分支上
5、代码CR意见处理完，相关负责人进行代码merge,代码修改从feature/add_new_Line合入dev分支完成
5、删除个人远程代码分支

第四章 使用极狐GitLab

4.1 安装部署

​ 关于安装官网上有详细的教程，园子上也有很多大佬写的很全面，跑起来之后默认会给一个root用户，密码会存在 /etc/gitlab/initial_root_password，更改密码登入进入主页面：

注：个人头像->Preferences->Localzation更改语言选项

4.1.1 创建和管理用户

主页 -> 配置GitLab -> 用户

​ 常用的用户角色有

Root 用户：Root 用户是 GitLab 实例的超级管理员，拥有最高权限，可以进行任何操作，包括管理其他用户、组和项目设置。

管理员用户：管理员用户也有很高的权限，可以管理整个 GitLab 实例，但权限略低于 Root 用户。管理员可以创建和管理组、项目，并管理用户的权限。

普通用户：普通用户的权限是最基本的，他们通常只对自己参与的项目和组有访问和操作权限。普通用户可以在他们有权限的项目中进行代码提交、代码审核和创建合并请求等操作。

​ 创建的用户时密码会发送到注册时填写的邮箱。

4.1.2 创建和管理群组

主页边栏 -> 项目 -> 创建群组

群组的可见性级别有：

​ 私有：群组及其项目只能由成员查看。

​ 内部：除外部用户外，任何登录用户均可查看该群组和任何内部项目。

​ 公开：群组和任何公开项目可以在没有任何身份验证的情况下查看。

​ 在gitlab里，可以创建出组、组下的子组。在小公司里可以看见gitlab里边会创建出后端，大数据等等一系列组。尽量不要使用中文创建组名, 可以在组信息中的备注编写中文描述以及中文组名, 组内人员名称也尽量用全拼命名。

​ 对于人员权限以及角色的控制也比较简单，有如下五种：

Owner：最高权限，谁去创建组，这个组就被谁拥有，它可以开除管理员，但管理员无法操作owner的角色。

Maintainer：（管理员-只是具备sudo权限的用户）管理员一般是给小组的组长，或者是给产品线的总监设定。

Developer：是干活的人，就是写代码的程序员，可以进行代码的上传以及代码的下载，不能下载其他的组内的代码，只能下载它们组的代码。

Repoter：比如现在有需求，其他组的大牛到我们组过来指导工作，要审视我们的代码，人家就提出需要一个权限，我不能给它developer因为它会改你代码，其他组的人不能改我们组的代码，所以就给一个repoter权限，他只能看，只读权限。

guest：不用看，匿名，直接去掉。一般出现在从ldap中把离职人员的信息删掉，再去gitlab查这个人的时候，它就是一个guest用户（匿名）需要再到gitlab把它删掉（不删也没事）。

​ Owner 可以拉人进来，为拉进入群组的人分配角色：

4.1.3 使用IDEA兼容GitLab

生成ssh密钥并添加

​ 创建个人访问令牌用于在idea中登录gitlab

​ 在管理员权限修改默认分支保护（默认是不允许合并到master上的）

第五章 企业项目构建与开发分支

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

主要负责管理生产环境下出现的紧急修复的代码。 从主干分支分出，修复完毕并测试上线后，并回主干分支和开发分支。并回后，视情况可以删除该分支。

第六章 GitLab的拓展功能

7.1 Code Review

7.2 CICD部署程序

Gitlab-CICD最简单明了的入门教程 - 狮子挽歌丿 - 博客园 (cnblogs.com)

GitLab-CI/CD入门实操 - 莱布尼茨 - 博客园 (cnblogs.com)

标签：实战篇,git,代码,就业,Arc,Git,TestRepo,main,分支
From： https://www.cnblogs.com/purearc/p/18339072