Git基础知识汇总（一）

Git使用教程一

Git使用教程二

第一章、Git概述

一、Git定义

Git 的全名是分布式版本控制系统 Git（英文全称为 "Git - Distributed Version Control System"）。

二、Git发展史

        Git 是一个分布式版本控制系统，由 Linus Torvalds 于2005年创建，用于管理 Linux 内核开发。它迅速成为最受欢迎的版本控制系统之一，得益于其速度，简单性和强大的分支支持。以下是 Git 的发展史要点：

1. 2005年：由 Linus Torvalds 创建了 Git，最初是为了管理 Linux 内核的开发。Git 的设计目标是速度、数据完整性以及对分布式、非线性工作流程的支持。

2. 2005年：Git 开始受到开发者社区的关注和采用，并迅速在开源社区中获得了认可。

3. 2008年：GitHub 成立，为基于 Git 的项目提供了一个托管平台。GitHub 的出现极大地推动了 Git 的普及和发展。

4. 2010年：Git 在开源社区中得到了更广泛的采用，许多知名的开源项目开始转向 Git 作为其主要的版本控制系统。

5. 2012年：Git 2.0 版本发布，这是一个里程碑式的版本更新，引入了许多重要的改进和功能增强。

6. 2016年：Git 推出了对子模块的支持，这使得在仓库中包含其他仓库成为可能，从而简化了复杂项目的管理。

7. 2018年：Git 推出了一些重要的性能优化和改进，包括更快的索引重建和更好的稳定性。

8. 除此之外，Git 在不断演进中也推出了一系列功能改进和修复，以适应日益复杂的软件开发需求和快速变化的技术环境。

        总体而言，Git 作为一个快速、强大的分布式版本控制系统，不断地改进和发展，成为了广大开发者在软件开发中不可或缺的工具之一。

        同生活中的许多伟大事件一样，Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众广的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。到 2002 年，整个项目组开始启用分布式版本控制系统 BitKeeper 来管理和维护代码。

        到 2005 年的时候，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux的缔造者 Linus Torvalds ）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。他们对新的系统订了若干目标：

• 速度
• 简单的设计
• 对非线性开发模式的强力支持（允许上千个并行开发的分支）
• 完全分布式
• 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

三、Git的去中心化思想

        Git 是一个分布式版本控制系统，其设计基于去中心化思想。它通过在每个参与者本地维护一个完整的代码仓库副本，以及通过相互之间的同步和数据交换，实现了去中心化的工作流程。这种去中心化的思想带来了以下几个重要的优势和特点：

1. 灵活性与自主性：每个参与者都可以独立工作，并且可以在没有网络连接的情况下进行提交、分支和合并操作，从而保证了工作的灵活性和自主性。

2. 可靠性与安全性：由于每个参与者都拥有完整的项目副本，因此即使某些节点出现故障或网络中断，项目的数据仍然可以得到保护和恢复，提高了数据的安全性和可靠性。

3. 高效的分支管理：Git 的去中心化特性使得分支管理变得更加简单和高效。每个参与者可以轻松地创建、合并和管理本地分支，而无需依赖中央服务器，从而促进了并行开发和实验性工作流程。

4. 开放的协作：去中心化思想鼓励了开放的协作方式，允许参与者自由地贡献和共享代码，而无需依赖于集中式的权限控制和审查机制。

        通过这些特点，Git 实现了开源软件开发中的协作和代码管理的自由度和灵活性，使得开发人员可以更加高效地合作，并且更容易应对分布式和复杂项目的管理挑战。这种去中心化的设计理念使得 Git 成为了开源社区中最受欢迎和广泛采用的版本控制系统之一。

四、Git与SVN对比

1、SVN：集中式版本控制系统

        SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器哪里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，带宽够大，速度够快，如果在互联网下，如果网速慢的话，就郁闷了。

下图就是标准的集中式版本控制工具管理方式：

集中管理方式在一定程度上看到其他开发人员在干什么，而管理员也可以很轻松掌握每个人的开发权限。

但是相较于其优点而言，集中式版本控制工具缺点很明显：

1. 服务器单点故障
2. 容错性差

2、Git：分布式版本控制系统

3、Git与SVN区别

• 1、Git是分布式的，SVN是集中式的，这是Git和其他非分布式的版本控制系统，例如SVN，CVS等，最核心的区别
• 2、Git把内容按元数据方式存储，而SVN是按文件：所有的资源控制系统都是把文件的元信息隐藏在一个类似 .svn  .cvs等的文件夹里
• 3、Git没有一个全局的版本号，而SVN有
• 4、Git的内容完整性要优于SVN，Git的内容存储使用的是SHA-1 哈希算法，这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏

       除了git还有svn、cvs这样的版本控制系统，它们的区别在于一个是分布式一个是集中式

       集中式就是svn和csv这样的版本控制系统，分布式是git

       区别在于集中式的版本控制系统每次在写代码时都需要从服务器中拉取一份下来，并且如果服务器丢失了，那么所有的就都丢失了，你本机客户端仅保存当前的版本信息，换句话说，集中式就是把代码放在一个服务器上集中管理，你的所有回滚等操作都需要服务器的支持。

       分布式的区别在于，每个人的电脑都是服务器，当你从主仓库拉取一份代码下来后，你的电脑就是服务器，无需担心主仓库被删或者找不到的情况，你可以自由在本地回滚，提交，当你想把自己的代码提交到主仓库时，只需要合并推送到主仓库就可以了，同时你可以把自己的代码新建一份仓库分享给其它人。

       像集中式它们都有一个主版本号，所有的版本迭代都以这个版本号为主，而分布式因为每个客户端都是服务器，git没有固定的版本号，但是有一个由哈希算法算出的id，用来回滚用的，同时也有一个master仓库，这个仓库是一切分支仓库的主仓库，我们可以推送提交到master并合并到主仓库上，主仓库的版本号会迭代一次，我们客户端上的git版本号无论迭代多少次，都跟master无关，只有合并时，master才会迭代一次。

五、Git工作模式

        Git是分布式版本控制系统，那么它就没有中央服务器的，每个人的电脑就是一个完整的版本库，这样，工作的时候就不需要联网了，因为版本都是在自己的电脑上。既然每个人的电脑都有一个完整的版本库，那多个人如何协作呢？比如说自己在电脑上改了文件A，其他人也在电脑上改了文件A，这时，你们两之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

下图就是分布式版本控制工具管理方式：

六、Git工作流程

一般工作流程如下：

1. 从远程仓库中克隆（clone） Git 资源作为本地仓库。
2. 从本地仓库中checkout代码然后进行代码修改
3. 在提交前先将代码提交（add）到暂存区。
4. 提交修改。提交（commit）到本地仓库。本地仓库中保存修改的各个历史版本。
5. 在修改完成后，需要和团队成员共享代码时，可以将代码push到远程仓库。

下图展示了 Git 的工作流程：

git pull命令实际上是将git fetch和git merge命令组合在一起使用的简化形式。git fetch用于从远程存储库获取最新的提交历史和对象，但并不会自动合并到您的当前分支中。而git merge用于将从git fetch获取的远程分支合并到当前分支中。

        因此，当您运行git pull时，Git会首先执行git fetch来获取远程分支的最新状态，然后自动尝试将这些变更合并到您当前所在的分支。如果有冲突发生，您可能需要手动解决这些冲突。

第二章、Git安装

一、概述

        最早Git是在Linux上开发的，很长一段时间内，Git也只能在Linux和Unix系统上跑。不过，慢慢地有人把它移植到了Windows上。现在，Git可以在Linux、Unix、Mac和Windows这几大平台上正常运行了。

二、Git下载

Git及TortoiseGit下载

Git - Downloads

三、软件安装

1、安装Git for Linux

yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel

yum -y install git-core

git --version  //git version 1.8.3.1

2、安装Git for Windows

Windows安装Git图文教程

3、安装TortoiseGit

完整完毕后在系统右键菜单中会出现git的菜单项。

4、安装中文语言包

第三章、Git配置

Git环境配置

一、注册GitHub账号

git安装好后，再去GitHub上注册一个账号：GitHub: Let’s build from here · GitHub
再点击桌面上的Git Bash快捷图标，我们要用账号进行环境配置了

二、Git配置

Git提供了一个叫做git config的工具，专门用来配置或读取相应的工作环境变量。这些环境变量，决定了Git在各个环境的具体工作方式和行为。

三、配置用户名和邮箱

在点击桌面上的Git Bash快捷图标中输入

1、配置用户名

git config --global user.name "username"    //（ "username"是自己的账户名，）

2、配置邮箱

git config --global user.email "username@email.com"     //("username@email.com"注册账号时用的邮箱)

四、查看配置信息

1、查看所有配置信息

以上命令执行结束后，可用如下命令查看配置是否OK

git config --global --list 

2、查看用户名配置

git config user.name

 

3、查看用户邮箱配置

git config user.email

 

五、ssh公钥和私钥配置

1、概述

Git公钥和私钥
SSH (Secure Shell) 密钥是用于身份验证和加密通信的一对加密密钥。它由两个部分组成：私钥（private key）和公钥（public key）。这对密钥是通过非对称加密算法生成的，其中刚开始连接时私钥用于加密数据，而公钥用于解密数据。进行文件传输时，公钥用于加密，私钥用于解密

        在 SSH 中，私钥应该保持在你的本地计算机上，并且必须保持安全和保密。公钥则可以被分享给其他人或服务器。当你连接到一个远程服务器时，你可以将你的公钥添加到服务器上，以便服务器可以使用该公钥对你的身份进行验证。

当你使用 SSH 协议连接到远程服务器时，身份验证过程如下：

• 你的本地计算机向服务器发送请求。
• 服务器要求提供身份验证凭据。
• 你的本地计算机将使用你的私钥对一个随机生成的数字进行加密，并将加密后的数字发送给服务器。
• 服务器使用你之前提供的公钥对加密后的数字进行解密。
• 如果解密后的数字与服务器生成的数字匹配，服务器将验证你的身份并允许你登录。

使用 SSH 密钥对身份验证具有以下优势：

• 安全性： SSH 密钥使用非对称加密算法，提供更高的安全性，比密码身份验证更难以被破解。
• 方便性：你不需要记住复杂的密码，只需要使用你的私钥来访问远程服务器。
• 可信任性 公钥可以在多个服务器之间共享，而不需要使用相同的密码。

通过生成 SSH 密钥对并将公钥添加到服务器上，你可以实现更安全和方便的远程访问。

2、生成ssh

继续刚才的操作，在命令框中输入命令：

ssh-keygen -t rsa

然后迅速连敲三次回车键

结束后去系统盘目录下（一般在 C:\Users\你的用户名.ssh）(mac: /Users/用户/.ssh）查看是否有.ssh文件夹生成，此文件夹中以下两个文件
如：在C:\Users\13476\.ssh目录下有

3、将ssh文件夹中的公钥（id_rsa.pub）添加到GitHub管理平台中

在GitHub的个人账户的设置中找到如下界面

title随便起一个，将公钥（id_rsa.pub）文件中内容复制粘贴到key中，然后点击Add SSH key就好了

六、验证配置

测试一下配置是否成功，在Git Bush命令框（就是刚才配置账号和邮箱的命令框）中继续输入以下命令，回车
输入命令：

ssh -T git@github.com

第四章、使用Git管理文件版本

一、创建本地版本库和工作区

        什么是版本库尼？版本库又名仓库，英文名 repository，可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改，删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”，由于Git是分布式版本管理工具，所以Git在不需要联网的情况下也具有完整的版本管理能力。

        创建一个版本库非常重要，可以使用git bash 也可以使用tortoiseGit。首先，选择一个合适的地方，创建一个空目录

1、版本库和工作区概念

版本库：“.git” 目录就是版本库，将来文件都需要保存到版本库中

工作区：又称工作目录，是指包含“.git”目录的目录，也就是“.git”目录的上一级目录就是工作目录，只 有工作目录中的文件才能保存到版本库中。

2、使用git bash创建：git init

创建一个空目录：C:\Users\13476\Desktop\Git\MyFirstRepository

 

3 、使用TortoiseGit创建

创建一个空目录：C:\Users\13476\Desktop\Git\MyRepository2

二、解决图标不显示方法

1、打开注册表，添加键值对

win + r ，输入regedit.exe，打开注册表，安装文件的层次关系，依次找到：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer

添加键值对：Max Cached Icons（最大缓存图标）的值为2000

2、在本地版本库中打开TortoiseGit设置

3、修改之后需要重新启动或注销后重新登录

修改之后需要重新启动或注销后重新登录

三、添加并提交文件

1、使用TortoiseGit添加并提交文件

在D:\git\repository目录下创建一个mytest.txt文件

文本文件变为带“+”号的图标：

提交文件：在mytest.txt上再次点击右键选择“提交”，此时将文件保存至版本库中。

2、使用git bash添加并提交文件

添加文件：git add  文件名 （必须是存在的文件）

提交文件：git commit 文件名

四、工作区和暂存区

Git和其他版本控制系统，如SVN的一个不同之处就是有暂存区的概念。

什么是工作区（Working Directory）？
工作区就是你在电脑里面能看到的目录，比如我的repository文件夹都是一个工作区。

有的同学可能会说repository不是版本库吗？怎么是工作区尼？其实repository目录是工作区，在这个目录中的“.git”隐藏文件夹才是版本库

Git的版本库里面存了很多东西，其中最重要的就是称为stage（或者叫做index）的暂存区（需要提交的文件修改都放到暂存区，然后一次性提交暂存区的所有修改），还有Git为我们自动创建了第一个分支master，以及指向master的一个指针HEAD

如下图所示：

分支和HEAD的概念我们稍后再讲，前面讲了我们把文件往Git版本库中添加的时候，是分想不执行的：

第一步：使用git add 命令将文件添加进暂存区

第二步：使用git commit 命令提交修改，实际上就是把暂存区的所有内容提交到当前分支

因为我们创建Git版本库时，Git自动为我们创建了唯一的一个master分支，所以，现在git commit就是往master分支上提交更改。

可以简单理解为：需要提交的文件修改通通都放到了暂存区，然后，一次性提交暂存区的所有修改

暂存区的存在就是为了提高效率

五、查看仓库当前的状态，显示有变更的文件

git status 命令用于查看在你上次提交之后是否有对文件进行再次修改。

通常我们使用 -s 参数来获得简短的输出结果

六、修改文件

1、使用TortoiseGit提交修改

被版本库管理的文件不可避免的要发生修改，此时只需要直接对文件修改即可。修改完毕后需要将文件的修改提交到版本库

先修改文件：

在mytest.txt文件上点击右键，然后选择“提交”

2、使用git bash提交修改

 使用git bash命名：git commit 文件名 -m 要添加的注释

七、查看修改历史

在开发过程中，可能会经常查看代码的修改历史，或者叫做修改日志，来查看某个版本是谁修改的，什么时间修改的，修改了哪些内容

1、使用TortoiseGit查看修改历史

可以在文件上点击右键选择“显示日志”来查看文件的修改历史。

2、使用git bash查看修改历史

git log 命令，在使用Git提交了若干更新之后，又或者克隆了某个项目，想回顾下提交历史，可以使用git log 命令

git log：显示工作区内所有文件的提交历史，按q退出

git log 文件路径/文件名：显示工作区内指定文件的提交历史

git log --oneline 文件路径/文件名：简洁显示提交历史

git log --reverse 文件路径/文件名：逆向显示日志

八、 差异比较

1、使用TortoiseGit差异比较

当文件内容修改后，需要和修改之前对比一下修改了哪些内容此时可以使用“比较差异功能”

2、使用git bash差异比较

git diff 文件路径/文件名

九、还原修改

当文件修改后不想把修改的内容提交，还想还原到未修改之前的状态。此时可以使用“还原”功能

先修改文件

还原修改之前的状态

注意：此操作会撤销所有未提交的修改，所以当做还原操作是需要慎重慎重！！！

十、删除文件

1、使用TortoiseGit删除文件

需要删除无用的文件时可以使用git提供的删除功能直接将文件从版本库中删除。

2、使用git bash删除文件

git rm 命令用于从Git版本控制中移除文件或目录。它有几种常见的用法和选项：

1. 移除文件

git rm <file_name>

这个命令会将指定的文件从Git中移除，并且在下一次提交中记录这个变化。它会从工作目录中删除文件，并将这个删除操作记录到暂存区。

2. 强制移除文件（包括已经跟踪的文件）

git rm -f <file_name>

        使用 -f（--force）选项可以强制移除文件，包括那些已经被修改并在暂存区的文件。这会立即从工作目录和Git的跟踪中删除文件。

3. 移除文件但保留在工作目录

git rm --cached <file_name>

使用 --cached 选项会将文件从暂存区移除，但会保留在工作目录中。这意味着文件不再被Git跟踪，但仍然存在于本地文件系统中。这个命令通常用于停止跟踪不再需要在版本控制中管理的文件，但仍希望在工作目录中保留它们。

4. 移除目录

git rm -r <directory_name>

使用 -r（-recursive）选项可以移除一个目录及其下所有文件和子目录。这个命令会删除目录中所有文件，并将这些删除操作记录到暂存区。

5. 移除文件并忽略错误

git rm -f --ignore-unmatch <file_name>

--ignore-unmatch 选项会忽略找不到的文件或目录的错误，即使文件不存在也不会报错。

这些命令的应用会直接影响工作目录和暂存区，因此在使用时要谨慎。记得在执行 git rm 命令前确认你真的想要移除这些文件，并且理解这些操作的影响。

十一、移动或重命名工作区文件

1、使用TortoiseGit移动或重命名工作区文件

2、使用git bash移动或重命名工作区文件

git mv 命令用于移动或重命名一个文件，目录或软连接

git mv [file] [new file]

13476@jzq MINGW64 ~/Desktop/Git/RepositoryTest01/test01 (master)
$ git mv d.txt  d20.txt

13476@jzq MINGW64 ~/Desktop/Git/RepositoryTest01/test01 (master)
$ git commit -m 重命名文件
[master e5d635c] 重命名文件
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename test01/{d.txt => d20.txt} (100%)

13476@jzq MINGW64 ~/Desktop/Git/RepositoryTest01/test01 (master)
$ git log d20.txt
commit e5d635c2a94d40e9094e1aec560d5c43adcfe4a8 (HEAD -> master)
Author: ZhuoqunJia <1347618115@qq.com>
Date:   Tue Nov 14 21:30:46 2023 +0800

    重命名文件

13476@jzq MINGW64 ~/Desktop/Git/RepositoryTest01/test01 (master)

十二、案例：将java工程提交到版本库

1、使用TortoiseGit

第一步：将参考资料中的java工程HelloProjet复制到工作目录中

第二步：将工程添加到暂存区

点击确定完成暂存区添加。

2、使用git bash

第五章、远程仓库 github

一、概述

        现在我们已经在本地创建了一个Git仓库，又想让其他人来协作开发，此时就可以把本地仓库同步到远程仓库，同时还增加了本地仓库的一个备份

常用的远程仓库就是github，https://github.com/

二、添加远程仓库

1、在github上创建仓库

2、连接远程仓库

        Github支持两种同步方式“https”和“ssh”。如果使用https很简单基本不需要配置就可以使用，但是每次提交代码和下载代码时都需要输入用户名和密码。如果使用ssh方式就需要客户端先生成一个密钥对，即一个公钥一个私钥。然后还需要把公钥放到githib的服务器上。这两种方式在实际开发中都用应用，所以我们都需要掌握。接下来我们先看ssh方式。

三、SSH协议

1、定义

SSH 为 Secure Shell（安全外壳协议）的缩写，由 IETF 的网络小组（Network Working Group）所制定。SSH 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。

2、基于秘钥的安全验证

        使用ssh协议通信时，推荐使用基于密钥的验证方式。你必须为自己创建一对密匙，并把公用密匙放在需要访问的服务器上。如果你要连接到SSH服务器上，客户端软件就会向服务器发出请求，请求用你的密匙进行安全验证。服务器收到请求之后，先在该服务器上你的主目录下寻找你的公用密匙，然后把它和你发送过来的公用密匙进行比较。如果两个密匙一致，服务器就用公用密匙加密“质询”（challenge）并把它发送给客户端软件。客户端软件收到“质询”之后就可以用你的私人密匙解密。

四、push：同步到远程仓库

只能在同一个本地仓库中向同一个远程仓库推送，不能使用不同的本地仓库向同一个远程仓库推送

同步到远程仓库可以使用git bash也可以使用tortoiseGit

1、使用git bash同步

在仓库所在的目录（D:\temp\git\repository）点击右键选择“Git Bash Here”，启动git bash程序。

git  remote  add origin git@github.com:ZhuoqunJia/GitRepositoryTest.git

origin：是远程仓库的别名，可以是任意名称。

git@github.com:ZhuoqunJia/GitRepositoryTest.git：是github中的仓库地址

git push -u origin master

origin：是远程仓库的别名，可以是任意名称。

在github的仓库中可以看到项目已经上传

2、使用TortoiseGit同步

由于TortoiseGit使用的ssh工具是“PuTTY”，git Bash使用的ssh工具是“openSSH”，如果想让TortoiseGit也使用刚才生成的密钥可以做如下配置：

• 同步。在本地仓库的文件夹中单击右键，选择“Git同步”

推送完成

五、clone：从远程仓库克隆

        克隆远程仓库也就是从远程把仓库复制一份到本地，克隆后会创建一个新的本地仓库。选择一个任意部署仓库的目录，然后克隆远程仓库。

1、使用git bash克隆

git clone 远程仓库SSH地址

2、使用TortoiseGit克隆

在任意目录点击右键：

六、pull：从远程仓库拉取代码

Git教程 git pull 和 git clone的区别_git clone git pull_Ann's Blog的博客-CSDN博客

Git中从远程的分支获取最新的版本到本地有这样2个命令：

git fetch：相当于是从远程获取最新版本到本地，不会自动merge（合并代码）

git pull：相当于是从远程获取最新版本并merge到本地

git pull命令其实相当于git fetch 和 git merge

在实际使用中，git fetch更安全一些

因为在merge前，我们可以查看更新情况，然后再决定是否合并

如果使用TortoiseGit的话可以从右键菜单中点击“拉取”（pull）或者“获取”（fetch）

1、git fetch

git fetch 命令用于从远程仓库获取最新的提交和数据，并将其下载到本地仓库，但不会自动合并到当前分支。这个命令主要用于获取远程仓库的最新更新，以便查看、比较和合并。
git fetch 命令的基本语法如下：

git fetch <remote_name> <branch_name>

• <remote_name> 是远程仓库的名称，通常是 origin。
• <branch_name> 是远程分支的名称。

用法示例：

获取远程仓库更新到本地：

git fetch origin

        这个命令将从远程仓库 origin 中获取最新的提交和数据，但并不会将这些更新合并到当前分支。它只会将这些更新下载到本地仓库，你可以通过其他命令查看或合并这些更新。

查看远程分支状态： 

git branch -r

 这个命令会列出所有远程分支，你可以查看远程仓库上的所有分支状态。

合并远程更新到本地分支：

git merge origin/main

这个命令将远程仓库 origin 上的 main 分支的更新合并到你的本地分支中。

git fetch 命令用于获取远程仓库的更新，并在本地仓库中创建或更新相应的远程分支引用。这个命令通常在拉取更新前用于了解远程仓库的状态和更新情况。

2、git merge

git merge 命令用于将一个分支的更改合并到另一个分支。它将指定分支的更改应用到当前分支，并创建一个新的合并提交。
基本的 git merge 命令语法如下：

git merge <branch_name>

<branch_name> 是要合并到当前分支的目标分支名称。

用法示例：

合并指定分支到当前分支：

git merge feature_branch

这个命令会将名为 feature_branch 的分支的更改合并到你当前所在的分支。

合并远程分支到当前分支：

git merge origin/main

这个命令会将远程仓库 origin 上的 main 分支的更改合并到你当前所在的分支。

合并远程分支并保留历史记录：

git merge --no-ff origin/main

        使用 --no-ff 选项可以保留合并提交的历史记录，即使是快进合并（fast-forward merge）也会创建一个新的合并提交。

在执行 git merge 前，请确保你在合并时理解你当前分支的状态以及你想要合并的目标分支的状态。这有助于避免不必要的冲突和错误。

3、git pull

git pull 命令用于从远程仓库获取最新的更改并将其合并到当前分支。它实际上是 git fetch 和 git merge 两个命令的组合。
基本的 git pull 命令语法如下：

git pull <remote_name> <branch_name>

• <remote_name> 是远程仓库的名称，通常是 origin。
• <branch_name> 是要拉取更新的分支名称。

用法示例：

从远程仓库拉取更新到当前分支：

git pull origin main

这个命令会从远程仓库 origin 的 main 分支获取最新的更改并合并到当前所在的分支。

拉取远程分支的更新并合并到当前分支：

git pull origin feature_branch

这个命令会从远程仓库 origin 的 feature_branch 分支获取最新更改并合并到当前所在的分支。

git pull 命令通常用于获取远程更新并将其合并到你当前所在的分支，以确保你的本地分支与远程仓库保持同步。要注意，在执行 git pull 前，请确保你的本地分支没有未提交的更改，以避免冲突。

4、使用git bash 拉取文件

5、使用TortoiseGit拉取文件

七、删除远程仓库

 

第六章、分支管理

一、概述

        在Git中，分支管理是版本控制的重要部分，它使得团队能够并行开发、试验新功能、修复错误，并在不同的版本之间切换。

1、什么是分支

        在Git中，分支是指在项目开发中，基于某个特定提交（或称为提交点、提交快照）的可移动指针，它指向了项目的不同开发状态。每个分支都代表了项目代码的一个不同状态，可以包含新功能、修复、实验性特性等。
理解分支的关键点：

1. 指向提交： 分支其实就是一个指向某个提交（commit）的引用。这个提交包含了项目在某个时间点的快照。分支随着新的提交不断向前移动，即指向最新的提交。
2. 并行开发： 分支允许团队成员在相同的代码库中并行开发不同的功能或修复不同的问题，而不会互相影响彼此的工作。
3. 独立工作环境： 每个分支都提供了一个独立的工作环境，允许开发人员在不影响主要代码的情况下进行实验、开发新特性、修复问题等。
4. 易于管理和回溯： 使用分支可以更容易地管理代码的变化，并且可以随时切换回不同的分支来回溯不同开发阶段的代码状态。
5. 合并和冲突： 分支允许你将一个分支的更改合并到另一个分支。在合并过程中，如果两个分支对同一部分代码做了不同的更改，可能会发生冲突，需要手动解决。

        在理解分支的概念时，可以将其视为项目的不同状态、开发线或实验性功能的容器。每个分支都代表了项目在某个时间点的特定状态，允许团队并行开发并有效地管理代码变更。

2、主分支：master

        在Git中，master 分支是默认的主要分支名称。它是Git版本控制系统中的一个重要分支，通常在初始化新的Git仓库时自动创建。master 分支包含项目的初始版本或主要开发线的提交记录。
随着时间的推移，有些团队和项目已经开始考虑使用其他术语来代替 master 分支的命名，以避免与历史和特定含义有关的一些问题。一些常见的替代名称包括 main、mainline、default 等。
在理解 master 分支时，可以将其视为项目的主要分支，它可能具有以下特征：

1. 初始分支: 在创建Git仓库时自动创建，通常作为项目的起点。它包含最初的提交，并是项目的基础版本。
2. 主要开发线: 大多数开发工作通常在 master 分支上进行，新功能和改进会合并到此分支，以形成项目的主要代码线。
3. 稳定版本: master 分支可能表示项目的稳定状态，通过合并经过测试的代码和功能，以确保代码的稳健性和可靠性。
4. 默认分支: 在一些情况下，master 被视为默认的操作分支，新的本地分支通常是基于 master 分支创建的。

        理解 master 分支的作用和意义有助于团队更好地管理和组织代码，但随着时间的推移，一些组织已经开始考虑采用更具包容性和无歧义性的术语来命名主要分支，以反映更开放和多元的价值观。

3、分支所记录的版本信息是针对整个项目的状态，而不是针对单个文件

master分支记录的版本信息是针对一个文件记录的吗，还是多个文件

在Git中，master 分支所记录的版本信息是针对整个项目的状态，而不是针对单个文件。每个提交（commit）都包含了整个项目文件状态的快照，而不仅仅是单个文件的变化。
当你在master分支上进行提交时，你记录的是整个项目文件的变化。Git会记录所有文件的当前状态，并在提交时生成一个快照。这个提交包含了所有被修改、添加或删除的文件，以及它们的状态信息。
当你查看提交历史时，你会看到每个提交都包含了对整个项目状态的更改。你可以查看每个提交的文件变化，但Git保存的是项目整体状态的快照。
因此，master 分支的版本信息是关于整个项目的，而不是单个文件的变化。

那我指定文件提交，还会记录整个项目状态吗

当你使用 git commit 文件名 提交指定文件时，Git仍然会创建一个提交，但是这个提交只包含你指定文件的更改，而不是整个项目的状态。
这个提交将仅记录被指定文件的更改，并在版本历史中显示这些更改。其他未指定的文件在这次提交中不会被包含。
如果你只提交了部分文件而不是整个项目，那么这个提交将只是部分地记录了项目的状态。未提交的其他文件在这个提交中的状态将保持不变。
总之，git commit 文件名 命令将会创建一个提交，但只记录了指定文件的更改，而不是整个项目的状态。

4、分支上记录每个文件的版本信息

版本信息包括提交的时间和当前文件的状态

5、子分支是基于主分支创建的

子分支是基于主分支创建的，创建时会自带主分支的版本信息

6、分支合并时必须至少有一个有相同的版本，来定位合并基点

分支合并时必须要有相同的版本信息，两种情况满足要求：

1、有一个分支为空分支

2、两个分支上至少有一个相同的版本（包括时间和当前文件的状态都得相同）

否则需要 --allow-unrelated-histories 来强制合并

二、分支原理

        在我们每次的提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD指针严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

        一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

        当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

        你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

        不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

        以上操作属于项目的发布版本的执行顺序，因为最终发布的是master分支，但是对于其它开发者，不应该在master分支上进行，应该建立子分支，而子分支最起码建立时应是当前的master分支的状态，而子分支一旦创建后，HEAD指针就会发生变化。

        如果有新的提交，则master分支不会改变，只有dev分支会改变。但不管子分支怎么开发，也不是最新的发布版本，所有的发布版本都保存在master分支上，则必须将子分支与master分支进行合并。

使用TortoiseGit管理分支就很简单了。

分支有Bug分支、Feature分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

软件开发中，总有无穷无尽的新的功能要不断添加进来。

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

三、创建分支

1、使用git bash

• 创建新分支： 使用 git branch <branch_name> 命令创建新的分支，例如：git branch new_feature。
• 创建并切换到新分支： 使用 git checkout -b <branch_name> 或 git switch -c <branch_name> 命令创建并直接切换到新分支，例如：git checkout -b new_feature。

2、使用TortoiseGit

在本地仓库文件夹中点击右键，然后从菜单中选择“创建分支”

 

四、查看和切换分支

1、使用git bash

• 查看所有分支： 使用 git branch 命令查看所有本地分支，git branch -a 查看所有分支（包括远程分支）。
• 切换分支： 使用 git checkout <branch_name> 或 git switch <branch_name> 命令切换到另一个分支，例如：git checkout main。

2、使用TortoiseGit

 如果想创建完毕后直接切换到新分支可以勾选“切换到新分支”选项或者从菜单中选择“切换/检出”来切换分支：

五、合并和处理冲突

1、使用git bash

• 合并分支： 使用 git merge <branch_name> 将另一个分支的更改合并到当前分支，例如：git merge new_feature。
• 解决冲突： 在合并过程中，如果出现冲突，需要手动解决冲突并提交合并结果。

2、使用TortoiseGit

分支切换到dev后就可以对工作区的文件进行修改，然后提交到dev分支，master分支不受影响。

例如我们修改at.txt中的内容，然后提交到dev分支。

切换到master分支后还是原来的内容：

将dev分支的内容合并到master分支，当前分支为master。从右键菜单中选择“合并”

再看master分支中的文件已经更新了

六、删除和重命名分支

• 删除分支： 使用 git branch -d <branch_name> 命令删除本地分支，例如：git branch -d new_feature。
• 重命名分支： 使用 git branch -m <old_branch_name> <new_branch_name> 命令重命名分支，例如：git branch -m feature new_feature。

七、远程分支操作

• 推送分支到远程： 使用 git push <remote_name> <branch_name> 命令将本地分支推送到远程仓库，例如：git push origin new_feature。
• 拉取远程分支： 使用 git fetch <remote_name> 和 git merge 或 git pull 从远程拉取分支。

分支管理让团队能够在不同的功能和修复任务上并行工作，同时保持代码的稳定性。它也提供了一个实验性的环境，可以进行新功能的开发和测试，而不影响主要的生产代码。

【精选】Git恢复之前版本的两种方法reset、revert（图文详解）【学习】_git还原到上一个版本_薇远镖局的博客-CSDN博客

 

第六章、Git冲突

一、概述

        在Git中，冲突（conflict）指的是当合并分支或拉取远程更新时，发生了无法自动解决的冲突情况。这种情况通常发生在两个不同的分支对同一文件的同一部分进行了不同的更改，并且Git无法自动决定如何合并这些更改时。
        例如，假设有两个开发者在不同的分支上修改了相同的文件的同一行或同一段代码。当尝试合并这些分支时，Git会尝试自动合并这些更改。但是如果两处修改冲突了，Git 将无法自动决定以哪一处修改为准。
这时候，Git 会标记这些冲突，并在受影响的文件中使用特殊的标记（如 <<<<<<<、=======、>>>>>>>）来表示冲突的部分。例如：

<<<<<<< HEAD
这是本地分支的修改
=======
这是远程分支的修改
>>>>>>> branch_name

        在这个示例中，<<<<<<< 到 ======= 之间的部分表示本地分支的修改，而 ======= 到 >>>>>>> 之间的部分表示远程分支的修改。这些标记表明冲突出现在哪里以及两个不同版本之间的区别。
        要解决冲突，你需要手动编辑有冲突的文件，选择保留哪些更改、移除冲突标记，并创建一个新的合适版本。完成解决冲突后，你需要使用 git add 将文件标记为已解决冲突，然后进行提交以完成合并操作。
        解决冲突需要仔细审查不同版本之间的更改，并确保最终合并的版本符合预期。冲突的出现是正常的，尤其是在团队协作时，经常会出现不同人修改同一文件的情况。解决冲突需要一些技巧和谨慎，但它也是Git协作中的一部分。

【Git】制造冲突以及解决冲突的详细方法_git解决冲突-CSDN博客

二、本地与远程分支冲突

1、使用git bash解决冲突

在本地创建空的git仓库，并拉取远程仓库代码

 在github中编辑文件并提交修改

在本地仓库修改和远程仓库修改的同一个文件

git与svn不同的是，svn自动会对比哪里出现了冲突，而git是要自己手动pull拉取更新之后才会进行对比并显示发生冲突的提示

2、使用TortoiseGit解决冲突

新建两个文件夹，模拟两个用户

在ConflictTest02文件夹中也对同一文件进行修改，提交，推送

当最下方那个框中没有红色的行，便代表没有冲突，进行保存

冲突符号变更为已编辑的表示，进行提交，并推送到远程仓库

三、本地与本地分支冲突

本地与本地分支冲突后不用pull冲突文件，直接就会在工作区中

两个分支中编辑的内容都是相互独立互不干扰的，那么如果在两个分支中都对同一个文件进行编辑，然后再合并，就有可能会出现冲突。

1、使用git bash解决冲突

2、使用TortoiseGit解决冲突

然后提交到版本库。

 切换到dev分支，对a.txt进行编辑：

最后进行分支合并，例如将dev分支合并到master分支。需要先切换到master分支然后进行分支合并。

出现版本冲突

冲突需要手动解决。

在冲突文件上单机右键选择“解决冲突”菜单项：

把冲突解决完毕的文件提交到master版本库就可以了。

四、冲突解决原理

第七章、Git标签

一、概述

        当谈到 Git 标签时，我们通常指的是用于标识特定提交的指针。标签在 Git 中非常有用，因为它们可以帮助你标记发布版本、重要的提交或者任何你认为值得注明的点。

        在 Git 中，标签是指向特定提交的易于记忆的别名，它们类似于一个永久性的指针，用来标记某个重要的提交或版本。标签可以用于多种情况，例如标记软件的发布版本、重要的里程碑或者任何你认为值得标记的提交。

        如果你达到一个重要的阶段，并希望永远记住那个特别的提交快照，你可以使用git tag给它打上标签。比如说，我们想为我们的runoob项目发布一个“1.0”。我们可以使用git tag -a v1.0命令给最新一次提交（HEAD）打上“v1.0”的标签。

1、两种主要类型的标签

1. 轻量级标签（Lightweight Tags）

        轻量级标签仅仅是指向特定提交的引用，类似于一个分支的指针，不包含额外的元数据。它们是一种更加简单的标记方式。

2. 注释标签（Annotated Tags）

        注释标签是一个完整的 Git 对象，包含了标签的名字、创建者的信息、日期时间和标签信息。这种标签更为详细，并且更适合用于发布版本或者需要更多元数据的情况。

2、标签的优点

• 版本标记：方便标识软件的不同版本或发布。
• 里程碑标记：标记重要的开发节点或版本发布。
• 易于共享：标签可以轻松地在开发团队中共享和传播。
• 便于查找：简化特定提交的查找和回溯。

3、标签的意义

Git有commit，为什么还要引入tag？

“请把上周一的那个版本打包发布，commit号是6a5819e......”

“一串乱七八糟的数字不好找”

如果换一个办法

“请把上周一的那个版本打包发布，版本号是v1.2”

“好的，按照tag v1.2查找commit就行”

所以，tag就是一个让人容易记住的有意义的名字，它根某个commit绑定在一起

二、标签的创建

都是基于当前分支当前所指的提交打的标签

轻量级标签的创建：

git tag <tag_name>

这将在当前提交上创建一个轻量级标签。

注释标签的创建：

git tag -a <tag_name> -m "Tag message"

这将创建一个注释标签，并在其中包含一条信息。

-a选项意为“创建一个带注解的标签”。不用-a选项也可以执行的，但它不会记录这标签是啥时候打的，谁打的，也不会让你添加标签的注解。推荐一直创建带注解的标签。git tag -a v1.0

当你执行git tag -a v1.0命令时，Git会打开你的编辑器，让你写一句标签注解，就像你给提交写注解一样。

三、查看标签

查看所有标签：

git tag

这会列出所有的标签。

查看特定标签信息：

git show <tag_name>

这会显示指定标签的详细信息，包括提交信息和元数据。

四、删除标签

删除本地标签：

git tag -d <tag_name>

删除远程仓库上的标签：

git push --delete origin <tag_name>

第八章、在IntelliJ IDEA中使用git

IDEA使用Git教程

一、在Idea中配置git

想要在 IDEA 中使用 Git，首先就需要在 IDEA 工具中对 Git 进行相关的配置。

        打开 IDEA 设置，之后按照下面图片中的步骤进行操作即可。需要注意的是，在 Path Git executable 中，也就是设置 Git 可执行路径中，找到本机电脑上 Git 的安装位置，根据情况进行路径选择。例如，我这里的路径是 F:\git\Git\cmd\git.exe，而在 IDEA 中这里默认是 C 盘路径下的目录，这里要根据个人情况而定，不可忽视。

二、创建项目远程仓库

        这里使用代码托管平台 GitHub 为例，进行创建远程仓库。如下图所示，新建仓库，仓库名称为 Java-Chinese-Chess（自定义），仓库介绍自定义没有影响，其他都按照默认设置即可，最后点击创建。

这样一个远程仓库的项目就创建完成了。

三、初始化本地仓库

        创建完远程仓库之后，还要通过 IDEA 开发工具来初始化一个本地仓库，相比于 Git Bash 这样的命令行来说，IDEA 非常方便可以进行可视化的 Git 管理。

        如下图所示，在工具栏中的 VCS，鼠标光标移动到 Create Git Repository，点击 Create Git Repository。

        点击 Create Git Repository 之后，弹出一个小窗口，选择要初始化的本地项目。这里就以打开的项目 chinese-chess 为例，对 chinese-chess 进行 Git 本地初始化。 

四、连接远程仓库

        初始化本地仓库，并且创建完远程仓库项目之后，下一步就需要将本地和远程进行对接交互了。那么在交互之前，肯定是要进行建立连接的，就像打电话之前先呼号建立通话连接一样，之后再进行信息交换。

工具栏 Git -> Manage Remotes，点击 Remotes 添加远程仓库连接信息。

        添加 Remote，输入 Name 和 URL，这里的 Name 如果没有特殊设置就是按照默认的 origin 来，也是 IDEA 自动补全的，建议在创建远程项目的时候不要轻易修改，这里的 URL 就是在远程项目信息中可以看到，我就不放出来了。

五、提交到本地仓库

在工具栏中，点击绿色的图标，表示 commit 到本地仓库。

• 弹出一个 Commit Changes 窗口，然后，选择我们的项目 redis-demo，会自动选中项目中的有变化的文件，第一次 commit 整个项目，会把所有项目文件进行 commit.
• 一般地，在 commit 操作之前，需要仔细查看每个文件细节内容，避免因为鼠标键盘无意按压动作导致对代码文件带来非本意的修改，这是要养成的习惯。
• 在 commit Message 中填入提交记录说明，最后点击右下角的 commit，提交项目 redis-demo 到本地仓库。

如果项目存在 warnings，即使项目没有错误可以正常运行，IDEA 还是会给出提示，这里我直接忽略，直接 Commit 提交即可。

提交完成之后，在 IDEA 界面下边信息提示栏中，可以看到提交记录，表示提交成功。

六、推送到远程仓库

        推送项目到远程仓库，按照下图操作即可。在 push 之前需要对每个文件内容进行检查，避免因为鼠标键盘无意按压动作导致对代码文件带来非本意的修改。推送成功之后，可以在 IDEA 中看到提示信息，也可以在远程仓库中查看结果。

由于IDEA默认是提交到远程仓库的master分支，但是目前远程仓库中是main分支，且main分支上已经有提交的版本信息，因此需要先在拉取远程分支更新本地分支

七、克隆远程仓库到本地

八、分支操作

1、新建分支

        在实际项目开发过程中，当遇到一个需求时，我们并不会直接就在主分支(master)上面进行开发，而是在主分支的基础上单独创建一个新的分支进行开发，当新建分支的代码经过代码评审以及测试验证通过，确认准确无误之后才会将新增的代码合并到主分支master，这才是一个规范的git操作流程。

因此，必须要掌握新建分支的过程，那么创建一个分支的过程如下图所示：

1、首先，单击 右下角 分支，单击选择 “New Branch from Selected…”

2、其次，弹出对话框，输入你要新建的分支名称。例如，feature-1.1.0，单击“Checkout”，表示创建该分支同时切换到 feature-1.1.0 分支。

3、然后，创建分支 feature-1.1.0 成功之后，可以在 “Local Branches” 下看到此时有两个分支分别为feature-1.1.0 和 master，这表明本地仓库中已经有了新建的分支了。

4、但是 “Remote Branches” 下依然只有一个 main 分支，表明在我们的远程仓库依然只有一个master 分支，因此我们还需要把在本地仓库新建的分支推送到远程仓库中，这样就可以在远程仓库中看到新建的分支了。

        单击 feature-1.1.0 ，然后在左边单击 “Push” ，弹出推送对话框。单击 “Push” 推送到远程仓库，这样分支新建操作彻底完成，可以看到在"Remote Branches"分支下面出现了“feature-1.1.0”，我们可以在该分支进行编码并进行拉取和推送操作。

2、删除分支

        在删除分支之前，建议先切换到(Checkout)其他分支，例如，Checkout到master分支，当然这并不强制，只是为了方便删除分支而已。

在 “Local Branches” 下单击分支 feature-1.1.0，左边弹出选项选中 “Delete”.

3、比较分支

        分支比较就是对比不同分支之间的差异。例如，需要比较当前所在分支与 master 分支之间的差异，可以选择需要对比的 master 分支，然后单击 “Compare with Current”，在弹出的窗口可以看到具体的差异。

4、合并分支

合并分支是将 A 分支合并到 B 分支，A 分支称为源分支，B 分支称为目标分支。

注意事项：master 分支是我们部署在生产环境服务器的分支，master 分支的代码往往是最新的代码。通常我们有一个新的需求时不会直接在 master 分支进行实施编码，而是基于 master 分支拉出一个新的分支，在拉出来的新分支进行实施编码。只有当新分支的代码经过 code review 以及测试联调通过之后，才会将代码合并到 master 分支等待部署上线。合并分支的流程务必规范：先将 master 分支合并到新分支，之后再将新分支合并到 master 分支。 这样做的原因是因为一个项目通常由多个人负责，可能在你开发的过程中，有新的代码已经合并到 master 分支并且部署上线了，但是你拉的新分支上的代码依旧是 master 分支的老代码。所以需要先更新你拉的新分支上的代码，将其他人更新的代码合并过来，保证你拉的新分支代码与最新的 master 分支代码一致（以免因为丢失最新修改的代码而造成线上事故）之后再将你的新拉的分支代码合并到 master 分支上面。

以 feature-1.1.0 分支和 master 分支为例，将 feature-1.1.0 分支合并到 master 分支中。

1、首先，切换到 feature-1.1.0 分支，将 master 分支合并到 feature-1.1.0 分支中。单击 “Local Branches” 下的 master，选择 “Merge into Current”，这里的 Current 是指目标（feature-1.1.0）分支 ，也就是将 master 分支合并到 feature-1.1.0 分支中，合并成功之后可以看到提示。

2、然后，切换到 master 分支下，将 feature-1.1.0 分支合并到 master 分支。

3、最后，我们可以看到在 “Local Branches” 下的 master 分支有个绿色的小箭头，这是因为我们刚才的分支合并在本地仓库操作的，并没有将远程的 feature-1.1.0 分支合并到 master 分支中。因此，我们还需要将 master 分支推送到远程仓库，点击 Push 或者使用快捷键 Ctrl+Shift+K 推送到远程仓库即可，推送成功之后绿色提示小箭头也会消失。

九、IDEA中取消git对项目的控制

1、右键项目，选择打开资源目录

2、删除 .git 目录

把目录下的.git文件删掉

3、删除idea中的git管理

删除完.git文件后，进入idea，右下角会有这样的提示，点击configure

或者在setting里面找到该位置

4、选中项目，点击删除，选择apply，ok

做完上述操作之后，项目就不会被Git管理了

十、常见问题

git push报错：Updates were rejected because the remote contains work that you do ! refs/heads/master:refs/heads/main [rejected] (fetch first)

        这个错误通常发生在尝试将本地更改推送到远程分支时，而远程分支已经包含了本地分支缺少的提交。这个问题通常是由于远程仓库与本地仓库不同步引起的。
要解决这个问题，可以按照以下步骤操作：

获取远程更新：

git pull origin main

这个命令会从远程仓库的 main 分支拉取最新的更改到你的本地仓库。
解决任何冲突：
如果在拉取远程更新后出现冲突，需要手动解决冲突，然后执行以下步骤：

• 解决冲突：编辑冲突文件，移除冲突标记，并保存文件。
• git add <file_name>：将解决冲突的文件标记为已解决。
• git commit：提交解决冲突的更改。

再次尝试推送：

git push origin main

这个命令将你的本地 main 分支的更改推送到远程的 main 分支。

如果你使用的是其他分支而不是 main 分支，需要相应地修改命令中的分支名。如果你经常遇到这个问题，可能是因为在多人协作时没有及时同步远程仓库的更新导致的，及时拉取远程更新可以避免这类问题的发生。

fatal: refusing to merge unrelated histories

        这个错误通常发生在尝试合并两个不相关的历史（unrelated histories）时，例如，当尝试合并两个不同源的项目或两个项目的历史分支时。
        如果你确信要合并这两个不相关的历史，可以在执行合并命令时添加 --allow-unrelated-histories 选项来强制合并：

git merge <branch_name> --allow-unrelated-histories

        这个选项会告诉Git，允许合并两个不相关的历史。执行这个命令后，Git将尝试合并这两个不同历史的分支。
        但请注意，在合并不相关历史时，可能会引入混乱或冲突，因为这些历史线索并没有共同的起点。在执行这个操作前，请确保你知道自己在做什么，并且要小心处理可能的冲突和意外情况。
如果这个错误是在尝试合并本地分支时出现的，而且你不希望合并两个不相关的历史，那么可以考虑重新评估你的目标，并确保你正在处理正确的分支和历史。