文章目录
一、介绍
1、Git
Git 是一个免费的、开源的分布式版本控制系统，可以快速高效地处理从小型到大型的各种 项目。
Git 易于学习，占地面积小，性能极快。 它具有廉价的本地库，方便的暂存区域和多个工作
流分支等特性。其性能优于 Subversion、CVS、Perforce 和 ClearCase 等版本控制工具。
版本控制是一种记录文件内容变化，以便将来查阅特定版本修订情况的系统。
版本控制其实最重要的是可以记录文件修改历史记录，从而让用户能够查看历史版本，
方便版本切换。
Git介绍 分布式版本控制工具VS集中式版本控制工具
Git安装 基于官网发布的最新版本2.31.1安装讲解
Git命令 基于开发案例 详细讲解git的常用命令
Git分支 分支特性 分支创建 分支转换 分支合并 代码合并冲突解决
Idea 集成Git
2、GitHub
创建远程库
代码推送 Push
代码拉取 Pull
代码克隆 Clone
SSH免密登录
Idea集成GitHub
3、Gitee码云
码云创建远程库
Idea集成Gitee码云
码云连接GitHub 进行代码的复制和迁移
4、GitLab
基于局域网的代码托管中心
GitLab服务器的搭建和部署
Idea集成GitLab
5、团队协作
用多副本来控制是不行的，小红修改为bbb222之后，小蓝再修改为ddd444就会使得小红的被覆盖。
所以需要使用到git这样专业的版本控制工具，将两次修改合并。如下：
6、集中式版本控制
CVS、SVN(Subversion)、VSS......
不论是团队中的哪个成员来修改代码，都需要去服务器中修改。
保证同一个团队修改的是同一份代码。
比如，
现在服务器上面有一份代码V，程序员小A从服务器上取出该代码并且修改为了V1版本，然后放到服务器中；
若是小B想对代码进行修改，需要等小A将V1提交完成之后，才能基于V1版本进行修改，假设此时修改为了V2版本，然后放到服务器中，此时服务器中就有V1和V2两个版本了。
如下：
好处：大家看到的是同一份代码，同一个项目。每个人都可以看到项目中的其他人做了什么工作。坏处：中央服务器的单点故障。每个人修改好的代码需要立即提交到中央服务器上，如果服务器宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。如果把服务器中的代码下载到本地，然后进行修改，再上传到服务器。这样的话版本修改的历史记录就不会被提交。
7、分布式版本控制
Git、Mercurial、Bazaar、Darcs......
不再有中央服务器。
每一台程序员的电脑就是一个自己的代码库，就可以在自己的电脑上做版本控制。
比如，程序员小A和小B对代码进行了修改，那么可以在自己电脑的本地库里面进行版本的控制。
Q：如何保证代码的统一性？
A：上图还少了一个远程库，分布式版本工具都有一个主键叫做代码托管中心，俗称为远程库。
比如此时小A做了一个版本V1，然后将其推送到远程库中；
小B在写代码之前，先用客户端即个人电脑连接上唯一的远程库，从远程库将代码克隆一份到本地库，然后基于自己的本地库再做版本的控制。比如基于V1修改为了V2，然后将其推送到远程库中。
远程库中的代码永远是最新的。
如下：
分布式版本控制不再有单点故障。
远程库比如GitHub，码云。这些远程库一般不会宕机，就算宕机了，我们也可以在自己的个人电脑中做自己的版本控制工具，只不过在远程服务器中没有代码的推送。本地还是有版本控制的。
分布式的版本控制系统出现之后，解决了集中式版本控制系统的缺陷：
-
服务器断网的情况下也可以进行开发（因为版本控制是在本地进行的）
-
每个客户端保存的也都是整个完整的项目（包含历史记录，更加安全，不会再存在服务器的单点故障问题）
8、Git简史
9、Git工作机制
①工作区：不是Idea这样的开发工具，工作区是指代码存放的磁盘位置。
②暂存区：在工作区写完代码之后，让Git知道有这样一个代码文件，需要将工作区的代码添加 到暂存区。对应Git里面的命令是Add。将代码从工作区添加到暂存区。暂存区的代码是临时存储，可以被删掉。
工作区的代码也可以被删掉，比如在本地写了几行代码，删除了一行代码。在工作区，代码被删除之后，就真的没有了。这个代码没有历史记录，也没有历史版本。
③本地库：若此时代码不仅写在了工作区，还添加到了Git的暂存区（暂存区的代码也可以被删掉，此时还没有生成历史版本）。
将暂存区的代码提交 到本地库，使用commit。一旦代码被提交到了本地库，就会生成对应的历史版本 ，此时代码删不掉了。
10、Git 和代码托管中心
代码托管中心是基于网络服务器的远程代码仓库 ，一般我们简单称为远程库。
➢ 局域网
✓ GitLab ->公司自己搭建的服务器，作为自己的代码托管中心
➢ 互联网
✓ GitHub（外网）-> Git官网代理的托管中心
✓ Gitee 码云（国内网站）
比如将本地库 的代码推送 到了远程库如github里面，而此代码又是开源的，那么全世界的人都可以看到这个代码了。
二、Git安装
官网地址： https://git-scm.com/
查看 GNU 协议，可以直接点击下一步。
双击：
下一步：
选择 Git 安装位置，要求是非中文并且没有空格的目录，然后一直下一步即可。
下一步：
Git 选项配置，推荐默认设置，然后下一步：
选择默认编辑器：
默认分支名设置，选择让 Git 决定，分支名默认为 master，下一步。
修改 Git 的环境变量，选第一个，不修改环境变量，只在 Git Bash 里使用 Git。
选择后台客户端连接协议，选默认值 OpenSSL，然后下一步。
配置 Git 文件的行末换行符，Windows 使用 CRLF，Linux 使用 LF，选择第一个自动
转换，然后继续下一步。
选择 Git 终端类型，选择默认的 Git Bash 终端，然后继续下一步。
选择 Git pull 合并的模式，选择默认，然后下一步。
选择 Git 的凭据管理器，将来要使用Git客户端往远程库去做代码的推送和拉取，总不能每次都去登录一下。这里的凭据管理器会记录登录的行为，这样的话，登录第一次，第二次就不用登录了。
选择默认的，然后下一步。（注意新版没有了跨平台的凭据管理器）
其他配置，选择默认设置，然后下一步。
实验室功能，技术还不成熟，有已知的 bug，不要勾选，然后点击右下角的 Install
按钮，开始安装 Git。
点击 Finsh 按钮，Git 安装成功！
在桌面，右键任意位置，显示更多选项（Win11）。
Git GUI很丑，不用它：
在右键菜单里选择Git Bash Here ，即可打开 Git Bash 命令行终端。
在 Git Bash 终端里输入 git --version查看 git 版本，如图所示，说明 Git 安装成功。
本地Git目录：
三、Git常用命令
（1）设置用户签名
🔔基本语法
git config --global user.name用户名
git config --global user.email邮箱
签名的作用是区分不同操作者身份。
用户的签名信息在每一个版本的提交信息中能够看到，以此确认本次提交是谁做的。
Git 首次安装必须设置一下用户签名，否则无法提交代码。 如果不设置自己的用户签名，将来提交代码的时候会报错。
※注意： 这里设置用户签名和将来登录 GitHub（或其他代码托管中心）的账号没有任何关系。这个用户签名只是代表了Windows本地的客户端，和将来要登录的账号没有关系。
🍉操作
小Tips：输入命令的前几个字母，按两下tab键，就可以补全代码。
设置用户名：（设置完按一下回车即可）
设置邮箱：
可以验证一下用户签名是否设置成功。
在Windows家目录下面，查看一个.gitconfig配置文件：
用notepad++打开此文件，可以看到设置的用户签名：
（2）初始化本地库
🔔基本语法
git init
使用Git管理目录，首先要让Git获取目录的管理权，也就是要初始化一下。
🍉操作
新建一个文件。
需要初始化本地库。
输入git init，然后回车：
生成了一个库在这个目录下：
Windows默认隐藏了：
这些文件看一下就好，不要人为修改这些文件，否则可能导致Git无法运行：
查看隐藏文件：
注意，Git Bash客户端里面使用的命令，与Linux里面的通用的。比如：
（3）查看本地库状态
本地库初始化好之后，就可以查看本地库的状态了。
🔔语法
git status
1、首次查看（工作区没有任何文件）
使用git status命令：
回车之后：
2、新增文件
刚才是查看初始状态，还没有建立任何文件。
现在使用vim新建一个文件：
回车之后：
现在输入一些文字，比如：
在vim里面，复制的快捷键是yy，粘贴的快捷键是p。
我们将上面的那句话复制粘贴几行（只需要将光标放在第一行，按yy就可以将该行复制下来了，然后按一下p就可以在下一行粘贴上去），这里写了20行，如下：
按shift+;，然后输入wq就可以保存了：
回车之后：
输出ll命令查看当前目录下（git-demo目录下）的文件，已经有这个文件了：
使用cat命令查看文件内容：
使用tail -n 1命令查看文件末尾的第一行：
在Git Bash客户端里面，可以使用Linux命令。
3、再次查看（检测到未追踪的文件）
新增文件之后，使用git status命令再次查看：
（4）添加暂存区
1、将工作区的文件添加到暂存区
刚才添加文件之后，可以查看到有这个文件了，但是并未被追踪。
现在将本地文件添加到暂存区，也就是git追踪文件的过程。
🔔语法
git add 文件名
🍉示例
使用git add命令然后接上文件名：
回车：
提交到暂存区之后 ，使用git status命令，再次查看本地库状态：
2、将暂存区的文件删除
绿色表示文件已经到了暂存区，暂存区的文件是可以被删掉的。
如果此时不想让hello.txt文件保存一个历史版本，是可以将它删掉的。
比如此时使用双引号提示的这个命令将它删掉：
如下：
rm是removed的缩写，cache是暂存缓存的意思。
注意只是暂存区的文件被删除了，工作区中的文件还存在 ，比如此时使用ll命令查看文件：
那是什么被删掉了？
是暂存区的文件被删掉了！用git status查看状态：
刚才只是演示将文件从暂存区删除，现在还是将文件添加到暂存区：
（5）提交本地库
文件添加到暂存区之后，还没有形成历史版本，需要添加到本地库。
1、将暂存区的文件提交到本地库
将暂存区的文件提交到本地库形成历史版本。
🔔语法
git commit -m"日志信息" 文件名
这个- 是告诉git，后面的东西是参数（可变的数据）。
-m 需要写一个版本日志信息，如果不加-m，会打开一个文件框让你输入日志信息。所以在提交的时候，一般会手动添加-m将此次提交的版本信息写一下。
🍉示例
首次提交版本提交成功：
文件一旦被提交到本地库之后，再次用git status命令查看一下本地库状态：
上图可以看到提交本地库成功了。
2、查看版本信息
有两种方式。
<1> 方式一
这里补充一个查看版本信息 的命令：git reflog查看引用日志信息
<2> 方式二
查看版本信息 的命令：git log查看详细日志信息
（6）修改文件
1、案例1
使用cat命令查看文件内容：
vim打开文件：
回车：
按键盘的↑将光标移动至第一行：
按一下i，再按一下键盘的→，将光标移动到最后：
比如输入22222：
然后按Esc退出编辑模式：（退出编辑模式之后，光标是出现在倒数第二个位置的，无法往后挪动光标）
按shift+;（按完之后，这里会出现一个冒号）：
输入wq保存文件：
回车之后：
Esc退出编辑模式，:w写入 ，:q退出 ，:wq写入并退出（保存文件并且退出）
使用git status命令查看状态：
既然是红色，文件没有被追踪，现在使用git add命令来将这个被修改的文件添加到暂存区：
查看状态，变为了绿色，添加到暂存区成功：
然后用git commit命令将文件提交到本地库：
回车之后：
提交到本地库之后，再次用git status命令查看本地库状态：
使用git reflog命令查看版本信息：
指针指向了哪里，就可以使用cat命令查看什么版本的文件：
2、案例2
修改文件为版本3，并且添加到暂存区：
提交到本地库，并且记录版本信息：
注意，虽然有很多个版本，但是在本地电脑中，git-demo文件夹里面只会显示一个文件：
（7）历史版本
1、查看历史版本
🔔语法
git reflog 查看精简的版本信息
git log 查看版本详细信息
🍉示例1
前面已经演示过了，这里再次演示一下。
git reflog 查看精简的版本信息
输入命令：
回车之后可以看到这个文件经历了多少次版本的更替：
可以看到版本号还有指针指向的版本：
🍉示例2
git log 查看版本详细信息
2、版本穿梭
🔔语法
git reset --hard 版本号
🍉示例1
先用git reflog命令来查看版本信息：
现在指针指向的是第三个版本，加入现在想要回到第二个版本，将第二个版本的版本号复制下来：
有个小技巧，输入完命令，然后将需要的版本号选中（光标滑动），最后按一下鼠标中间的滚轮（注意不是滑动，是按动），就可以直接完成复制粘贴。如下：
回车之后就完成了穿越，穿越回了第二个版本：
用git reflog命令查看版本信息：
补充：ctrl+insert 复制，shift+insert粘贴
指针变动之后，就可以用cat查看当前版本的内容了（不是第三版本的33333，而是第二个版本的22222）：
⛳补充
打开git-demo文件，并且显示隐藏的项目：
双击打开.git文件夹：
用notepad++打开HEAD配置文件：
可以看到当前是在master分支上：
打开refs文件夹：
然后双击打开heads文件夹：
用notepad++打开master文件：
可以看到里面记录的是第二个版本的版本号：
因此，现在的指针指向了master分支，master分支又指向了第二个版本。
🍉示例2
假设现在觉得第二个版本也不好，想回到第一个版本。
用git reflog查看版本信息：
用git reset --hard命令穿梭至想要的版本（鼠标光标选中想要的版本号，然后按击鼠标滚轮就可以粘贴）：
回车之后就可以穿梭成功：
再次查看日志：
再打开master文件，分支已经发生了变化，指向了第一个版本：
我们也可以打开hello.txt文件，可以看到显示的是第一个版本的信息：
🍉示例3
不仅可以往前穿越，还可以往后穿越。
用git reflog命令查看日志信息：
用git reset --hard命令回到想要的版本（假设是第三个版本）：
回车：
再次查看版本信息，指针指向了第三个版本：
打开文件hello.txt：
⛳补充
Git 切换版本，底层其实是移动的 HEAD 指针，具体原理如下图所示。
head是目前看到的，头指针head指向master分支，master分支指向first版本。
若此时来了一个second版本，那么指针就会指向second版本：
Git控制版本，并不是ctrl+c/ctrl+v造了多个副本，而是在本地库的内存里面记录了很多个版本信息，
它通过调用指针来指向不同的版本。
四、Git分支
（1）概述
1、介绍
下图，从右往左看。
公司里面会有很多个服务器 ，因为会有好几个环境（开发环境、测试环境、生产环境）。
2、什么是分支
在版本控制过程中，同时推进多个任务，为每个任务，我们就可以创建每个任务的单独分支。
使用分支意味着程序员可以把自己的工作从开发主线上分离开来，开发自己分支的时候，不会影响主线分支的运行。就算把自己的分支开发错误，也不会影响别的分支运行。
对于初学者而言，分支可以简单理解为副本，一个分支就是一个单独的副本 。（分支底层其实也是指针的引用）
比如现在有一个主线分支master：
然后开发了一个feature-blue分支，给它加一个蓝色背景，在分支开发之后，合并到用户使用的主线分支：
又比如此时出现了卡顿，可以再搞一个分支来解决这个问题，然后合并到master分支：
3、分支的好处及操作
【分支好处】
同时并行推进多个功能开发，提高开发效率。
各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响（直接将失败的分支删除即可）。
失败的分支删除重新开始即可。
【分支操作】
（2）查看分支
🔔语法
git branch -v
🍉示例
输入命令查看当前的分支：
回车之后可以看到，只有一个master分支，没有其他分支；这个master分支有三个版本：
*代表当前所在的分区
（3）创建分支
🔔语法
git branch分支名
🍉示例
比如现在的代码出现了一点问题，想要给它创建一个热修hot-fix分支来解决这个问题。
回车之后发现没有反应：
再次用git branch -v命令查看分支，发现有两个了：
hot-fix是刚创建的新的分支，并将主分支 master 的内容复制了一份
（4）修改分支
上面演示之后，可以看到现在在master分支上：
现在在master分支上，但我们想在hot-fix分支上修改hello.txt文件。
可以使用git checkout命令来切换分支：
回车之后就切换到了hot-fix分支：
使用git branch -v查看分支：
使用vim命令进入文件：
回车：
现在光标在这里：
按一下键盘上面的i之后就可以编辑了，假如修改成下面的样子：
按Esc退出编辑模式，光标会到这里来：
按Shift+;会出现一个冒号：
输入wq，回车之后就保存了：
在hot-fix分支上修改了文件之后，我们使用git status命令查看本地库状态：
使用git add命令添加暂存区：
使用git status命令查看本地库状态：
使用git commit命令提交本地库：
回车之后：
此时用cat查看文件内容，可以发现变为了修改之后的三个2和三个3：
查看HEAD文件可以看到此时的分支是hot-fix了：
使用git reflog命令查看版本信息：
看一下hot-fix文件：
这是修改之前的分支信息：
这是修改之后的：
（5）切换分支
🔔语法
git checkout分支名
🍉示例
上面我们已经将hot-fix分支修改好了，现在切换回master分支：
在master分支下查看文件：
（6）合并分支
🔔语法
git merge 分支名 将指定的分支合并到当前分支上
🍉示例
假设现在要将刚才的hot-fix分支合并到master分支上，需要保证当前的分支是在master上面，站在master分支上面，如下：
使用git merge命令合并分支：
回车之后：
查看master分支的内容，发现不再是之前的五个2和五个3，而是变为了hot-fix分支修改之后的三个2和三个3了。
如下：
查看master分支的状态：
上面演示的分支合并，是一个正常的合并。
master分支并没有修改，仅仅只是修改了hot-fix分支，然后将修改了的hot-fix分支合并到master分支上。此时并不会产生冲突。
（7）冲突问题
1、产生冲突
【冲突产生的原因】
合并分支时，两个分支在同一个文件的同一个位置 有两套完全不同的修改。Git 无法替我们决定使用哪一个。必须人为决定新代码内容。
冲突产生的表现：后面状态为 MERGING
【示例】
<1> 修改master分支上的hello.txt文件
现在在master分支上修改hello.txt文件：
在倒数第二行加上几个字母：
然后Esc退出，wq保存一下：
光是修改肯定不够，我们将它添加暂存区，提交本地库：
用cat看一下文件确实已经修改了：
<2> 修改hot-fix分支上的hello.txt文件
用git checkout命令将分支切换到hot-fix分支上：
修改hello.txt：
可以看到这里并没有刚才在master分支下面修改的几个字母：
此时我们在倒数第一行进行修改，如下：
保存一下：
然后添加暂存区，提交本地库：
<3> 分支合并
经过上面两步操作，master和hot-fix分支的同一个文件都被修改了。
现在切换回master分支：
站在master分支上，将hot-fix分支合并过来，发现报了一个冲突：
这里的竖线也表示没有合并成功：
查看一下本地库状态：
此时Git不敢帮我们合并了，需要手动进行合并。
2、解决冲突
手动打开文件：
<1> 编辑有冲突的文件，删除特殊符号，决定要使用的内容
特殊符号：
<<<<<<< HEAD 当前分支的代码
======= 合并过来的代码
>>>>>>>> hot-fix
回车，可以看到Git已经帮我们标注出来了：
将不需要的删除：
这一行也不需要：
Git的特殊符号也不需要，都删掉：
修改完之后：
wq保存一下：
<2> 添加到暂存区
查看本地库状态：
所以修改完之后，还需要将hello.txt文件添加到暂存区：
回车之后：
<3> 提交到本地库 （注意：此时使用 git commit 命令时不能带文件名）
添加完暂存区之后，还要提交本地库。
两个文件都修改了hello.txt，如果带文件名会报错。比如：
回车之后会报错，致命错误：合并期间无法进行部分提交。如下：
需要将hello.txt去掉，不能带有文件名：
回车之后，可以正确提交：
可以看到，正确提交之后，后面括号里面是master，而没有merging合并中了。
也就是说，master已经完整的将hot-fix合并起来了，手动解决了代码的冲突。
使用cat查看hello.txt文件，发现刚才两个分支做的修改都有了：
注意，我们合并的是，将hot-fix分支的内容合并到master分支上面，hot-fix分支上面的内容还是只是添加了hot-fix test的，并没有master test：（合并分支，只会修改合并的那个分支，不会修改合并过来的那个分支）
（8）创建分支和切换分支图解
最开始master分支，它有四个版本：
现在在third下面再次创建了一个hot-fix分支：
在hot-fix分支上，又进行了修改：
现在合并分支，分支切换，其实就是将head指向了hot-fix：
master、hot-fix 其实都是指向具体版本记录的指针。
当前所在的分支，其实是由HEAD决定的。所以创建分支的本质就是多创建一个指针。
HEAD 如果指向 master，那么我们现在就在 master 分支上。
HEAD 如果执行 hot-fix，那么我们现在就在 hotfix 分支上。
所以切换分支 的本质就是移动 HEAD 指针。
【补充】
在本地文件夹，可以看到有几个分支：
还可以看到目前HEAD指针指向的是哪一个分支：
目前HEAD指针指向的是hot-fix分支，我们还可以查看当前hot-fix分支指向的是哪一个版本：
HEAD指针指向分支，比如指向master分支，master又指向具体的版本。