Git就业实战篇

第一章 版本控制系统

1.1 SVN 集中式版本控制系统

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

image-20240704122615774

1.2 GIT 分布式版本控制系统

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

image-20240704122855453

第二章 Git的基本内容回顾

2.1本地与远端仓库通信

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

image-20240704124147331

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

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

image-20240704124547376

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

image-20240704124848195

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

image-20240704125314832

2.2 回忆Git的命令

image-20240704181853873

2.2.1 git clone

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

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

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

image-20240704130442019

image-20240704131117611

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

image-20240704181350099

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

image-20240704184626941

2.3 冲突解决

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

image-20240728235216995

image-20240728235316419

2.3.1 修改的不同位置的代码

​ git 会智能合并

image-20240729002350577

2.3.2 修改相同位置的代码

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

image-20240729000027714

[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 MergeAuto Merge failed两种,后者需要手动进行更改。

image-20240729224239107

​ 下面是整个的流程,经常从远端 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

image-20240729224428163

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

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

// 这是一个启动类
@SpringBootApplication

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

image-20240729224509204

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分支,如此循环往复,确保每个版本的迭代都有条不紊。

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

image-20240801001851021

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更改语言选项

image-20240801005806238

4.1.1 创建和管理用户

主页 -> 配置GitLab -> 用户

​ 常用的用户角色有

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

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

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

image-20240801172358961

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

image-20240801234444750

4.1.2 创建和管理群组

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

群组的可见性级别有:

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

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

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

image-20240801234800312

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

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

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

Maintainer:(管理员-只是具备sudo权限的用户)管理员一般是给小组的组长,或者是给产品线的总监设定。

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

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

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

image-20240801171602711

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

image-20240801235249393

4.1.3 使用IDEA兼容GitLab

生成ssh密钥并添加

image-20240802000033396

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

image-20240802000241986

image-20240802004532828

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

image-20240802004852486

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

1. GitFlow工作流介绍

在项目开发过程中使用 Git 的方式常见的有:

1.1 集中式工作流

所有修改都提交到 Master 这个分支。比较适合极小团队或单人维护的项目,不建议使用这种方式。

image-20240802163033006

1.2 功能开发工作流

功能开发应该在一个专门的分支,而不是在 master 分支上。适用于小团队开发。

image-20240802163052638

1.3 GitFlow工作流

公司中最常用于管理大型项目。为功能开发、发布准备和维护设立了独立的分支,让发布迭代过程更流畅。

image-20240802163105647

1.4 Forking工作流

在 GitFlow 基础上,充分利用了 Git 的 Fork 和 pull request 的功能以达到代码审核的目的。一般用于跨团队协作、网上开源项目。

image-20240802163124197

2. 各分支功能介绍

image-20240802163156865

2.1 主干分支 master

主要负责管理正在运行的生产环境代码,永远保持与正在运行的生产环境完全一致。为了保持稳定性一般不会直接在这个分支上修改代码,都是通过其他分支合并过来的。

2.2 开发分支 develop

主要负责管理正在开发过程中的代码。一般情况下应该是最新的代码。

2.3 功能分支 feature

为了不影响较短周期的开发工作,一般把中长期开发模块,会从开发分支中独立出来。 开发完成后会合并到开发分支。

2.4 准生产分支(预发布分支) release

较大的版本上线前,会从开发分支中分出准生产分支,进行最后阶段的集成测试。该版本上线后,会合并到主干分支。生产环境运行一段阶段较稳定后可以视情况删除。

2.5 bug 修理分支 hotfix

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

第六章 GitLab的拓展功能

7.1 Code Review

image-20240802163321806

7.2 CICD部署程序

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

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

posted @ 2024-08-02 16:39  Purearc  阅读(5)  评论(0编辑  收藏  举报