【Git】一文读懂，我说的（未完结）

本文使用一个windows下的git用户，两个Linux下的git用户来演示相关操作。

一、梗概

这一节全是文字描述，但你不应该跳过。

1.1 git概述

Git是一款优秀的分布式版本控制工具，是由Linux社区的开发者Linus Torvalds所开发的。Git已成为程序员们必备的工具之一，许多大型的软件项目都在使用Git进行版本管理。

Git的核心就是一个版本控制系统，可以实现多人在同一份代码的基础上进行开发，避免了因代码版本不同而导致的冲突问题。直接在README或代码的某个位置留下修改的时间和内容的日志，并提交到中央仓库，以便其他人可以通过下载相应的版本来获得你的工作成果。当多人修改代码时，可以使用Git来解决版本冲突，为了更好地保留项目的历史记录，以便日后的查看和追踪。并在需要时，可以返回到任何一个历史版本。

Git的速度非常快，因为Git管理的是一组文件的快照。关于Git分支的一个优点是，如果你发现自己的项目中某一块出毛病了或者是需要某些新的特性，你可以同时有多个代码分支在开发不同的功能。

1.2 什么是版本控制

版本控制是一种记录和管理文件或代码变更历史的系统，它允许开发团队或个人开发者跟踪文件的每个修改、恢复到任意历史版本，以及协同合作开发。版本控制系统的主要目的是解决文件的并发编辑和多人协作过程中可能出现的冲突、错误以及代码管理等问题。

为什么需要版本控制呢？

1. 历史追溯与恢复：版本控制系统可以记录文件或代码的完整修改历史，包括每次提交的详细信息、作者、时间等，因此可以方便地追溯到任意历史状态，并能够恢复到之前的任意版本。这对于错误修复、功能回退或者回滚到某个稳定版本都非常重要。
2. 并发协作与团队协作：在多人协同开发的情况下，每个开发者都可以独立地在本地进行修改和测试，而版本控制系统可以很好地管理并合并这些修改，避免不同人之间的冲突。开发者可以轻松地在不同分支上并行开发，然后将它们合并到主干分支上。
3. 错误修复与回退：当出现错误或者bug时，版本控制系统可以快速定位问题，查找导致问题的特定提交或修改，并进行修复。如果修复引入了新的问题，还可以方便地回退到之前的正确版本。
4. 版本迭代与特性管理：版本控制系统允许开发者在不同的分支上同时进行不同特性的开发，而不会相互干扰。通过分支的合并和切换，可以轻松管理不同特性的开发进度和版本迭代。
5. 备份与灾难恢复：版本控制系统可以作为重要文件和代码的备份工具，确保数据的安全性。在灾难性事件发生时，可以通过版本控制系统轻松地恢复到之前的状态。

版本控制是一种必不可少的工具，它提供了对文件或代码修改历史的追踪、管理和协作能力，提高了开发效率、减少了错误、便于团队协作，并为错误修复、版本迭代等提供了强大的支持。

1.3 Git相对于集中式版本控制系统的优势

Git相对于集中式版本控制系统（如SVN）有以下几个主要的优势：

1. 分布式架构：Git是一款分布式版本控制系统，每个开发者都可以拥有完整的代码仓库副本。这意味着每个开发者都可以在本地进行完整的版本控制操作，而不依赖于中央服务器的可用性。这样的架构提供了更好的灵活性和可靠性，即使在没有网络连接的情况下，开发者仍然可以进行提交、分支切换等操作(推送这些肯定就不行了哈)。
2. 强大的分支管理：Git的分支管理是其最大的特点之一。与集中式系统不同，Git鼓励开发者频繁地创建和合并分支，因此每个特性或修复都可以在独立的分支上进行开发和测试，而不会干扰主干代码。这样可以更好地支持并行开发、快速迭代和团队协作。
3. 快速而高效：Git采用了先进的数据结构和算法，使得它在处理大型代码库和大量历史记录时表现出色。Git的提交历史是基于快照而非差异存储的，这样使得查找和恢复历史版本非常快速。此外，Git通过压缩和存储差异来减小存储空间的需求，使得仓库的体积相对较小。
4. 本地操作：Git的本地操作特性是非常强大的。开发者可以在本地进行提交、分支切换、合并等操作，而无需与中央服务器频繁交互。这不仅提高了操作的速度，还减少了对网络的依赖性，使得开发者可以在离线状态下继续工作。
5. 强大的分布式协作：由于每个开发者都有完整的仓库副本，Git使得分布式团队协作更加简单和灵活。开发者可以通过推送和拉取操作轻松共享和同步代码，合并分支的过程也相对简单。此外，Git提供了更丰富的协作工具和特性，如分支管理、代码审查等，有助于团队更好地协同工作。

Git相对于集中式版本控制系统具有分布式架构、强大的分支管理、快速高效、本地操作和强大的分布式协作等优势。这些特点使得Git成为当今软件开发领域最流行和广泛使用的版本控制系统之一。

1.4 git和github

Git和GitHub是两个相关但不同的概念和工具。

Git是一款分布式版本控制系统，它专注于管理和跟踪文件或代码的修改历史。Git通过记录每次提交、创建分支和合并等操作来追踪代码的演变，并提供了强大的分支管理和版本控制功能。

GitHub是一个基于Git的代码托管平台和社交开发平台。它提供了一个集中式的、云端的仓库托管服务，使开发者能够将自己的代码仓库存储在云端，并进行版本控制和协作开发。GitHub提供了一个图形化的界面，方便用户进行代码管理、版本控制、代码审查、问题跟踪和团队协作等操作。

Git和GitHub之间的关系可以理解为Git是版本控制系统的核心工具，而GitHub则是基于Git的代码托管和协作平台。

开发者可以使用Git在本地进行版本控制操作，如创建仓库、添加文件、提交更改等。

然后，可以使用GitHub将本地仓库与远程仓库进行同步，即将代码推送（Push）到GitHub上的仓库或从GitHub上的仓库拉取（Pull）最新的代码。GitHub还提供了许多额外的功能，如问题追踪、代码审查、团队协作和持续集成等，使得开发者可以更方便地进行协作和项目管理。

既然github是使用git的，使用最广泛的，代码托管平台，那肯定不止它一个，使用git的代码托管平台还有（常用）：

1.41 GitLab

gitlab应该是大家都听过，但很多人都没有实际使用过的平台。

GitLab是一个基于Git的开源的代码托管和协作平台。它提供了强大的版本控制功能、代码管理工具和协作功能，可用于个人开发、团队协作和企业级项目管理。

以下是GitLab的主要特点和功能：

1. 代码托管：GitLab提供了Git仓库托管服务，开发者可以轻松地创建、克隆、推送和拉取Git仓库。它支持分支管理、标签管理和合并请求等功能，使得团队能够方便地进行代码版本控制和协作开发。
2. 持续集成与持续交付：GitLab集成了强大的持续集成和持续交付功能。它允许开发者配置自动化的构建、测试和部署流程，以确保代码质量和快速交付。通过与Docker等容器技术的集成，GitLab还能够实现高效的容器化部署。
3. 项目管理：GitLab提供了项目管理工具，如问题跟踪、看板、里程碑和活动流。开发者可以创建任务、分配责任人、跟踪问题状态，并与代码托管和协作功能紧密集成，实现全面的项目管理。
4. 代码审查：GitLab内置了代码审查功能，团队成员可以在提交合并请求时进行代码评审和讨论。这有助于提高代码质量、发现潜在问题，并促进团队间的知识共享和协作。
5. 安全性和权限控制：GitLab重视代码和数据的安全性。它提供了访问控制、权限管理和用户身份验证等功能，以确保只有授权人员可以访问和修改代码。此外，GitLab还提供了强大的安全扫描和漏洞检测工具，帮助开发者及时发现和修复安全漏洞。
6. 自托管和部署：除了GitLab.com提供的云端托管服务，GitLab还允许用户自行部署和管理GitLab实例。这意味着企业可以在自己的服务器或云平台上搭建和管理GitLab，实现更高的数据安全和自定义配置。

GitLab以其开源性质、丰富的功能和灵活的部署选项，在开发者社区和企业中受到广泛使用。它提供了一个全面的代码托管、协作和项目管理平台，为团队提供了高效、安全和可靠的软件开发和交付环境。

和github相比：

1. 托管模式：GitLab提供了自托管选项，用户可以在自己的服务器上部署和管理GitLab实例，以获得更高的数据安全性和自定义性。而GitHub则是一个云端托管服务，所有的仓库和数据都存储在GitHub的服务器上。这意味着用户无需关心服务器的管理和维护，可以专注于代码开发和协作。
2. 许可方式：GitLab是开源的，用户可以自由地访问、修改和分发GitLab的源代码。这使得用户可以根据自己的需求进行自定义配置和扩展功能。而GitHub则是闭源的，用户无法访问和修改其核心代码。
3. 定价模式：GitLab提供了免费的开源版本和商业版本，商业版本提供了更多高级功能和支持服务。相比之下，GitHub在2019年改变了其定价策略，将一些高级功能（如私有仓库）从免费计划中移除，并提供了更多的高级功能和团队协作工具作为付费服务。
4. 功能差异：GitLab和GitHub在功能上有一些细微差异。例如，GitLab内置了持续集成和持续交付功能，而GitHub则与其子公司Actions合作提供了类似的功能。此外，GitLab提供了强大的项目管理工具，如看板、里程碑和活动流，而GitHub则更专注于代码托管和协作功能。
5. 社区和生态系统：由于GitHub的较早推出和广泛使用，它拥有更大的用户社区和更广泛的生态系统。这使得GitHub成为开源项目托管和协作的首选平台，并且许多开源项目和开发者社区都集中在GitHub上。

1.42 Gitee（码云）

俗称国内版github。是开源中国社区推出的基于Git的代码托管服务，目前已经成为国内知名的代码托管平台，致力于为国内开发者提供优质稳定的托管服务 。今年已经十周年了。

国内很多巨头的项目都托管在上面，比如OpenHarmony：

很多国外开发者的项目并不会发布到gitee，有些国内开源项目也不会发布到github，所以，至少应当熟悉这2个平台。

和github相比：

1. 用户定位：Gitee主要面向中国用户，提供了更多的针对中国用户的服务和功能。相比之下，GitHub是全球范围内使用最广泛的代码托管平台，具有更大的国际用户社区。
2. 服务器位置和访问速度：Gitee在中国设有服务器，提供了国内加速服务，以确保用户能够更快地访问和下载代码。而GitHub的服务器位于全球各地，对国内用户可能存在访问速度上的差异（这个我反正没感觉）。
3. 开源社区和生态系统：GitHub是全球最大的开源社区之一，聚集了大量的开源项目和开发者。许多知名的开源项目都托管在GitHub上，并且在开源社区中享有很高的声誉。相比之下，Gitee虽然也有一定规模的开源社区，但在国际开源社区中的影响力相对较小。
4. 功能和工具：Gitee和GitHub在基本的代码托管、版本控制和协作功能上非常相似。然而，两者在一些高级功能和工具方面可能存在差异。例如，GitHub在持续集成、代码审查和团队协作方面提供了更多的内置工具和集成选项。而Gitee则提供了一些特定于中国用户的功能和服务，如国内部署选项、企业版服务和国内社交媒体集成等。
5. 商业模式和定价：GitHub提供了免费和付费的服务计划，免费计划包含了许多基本功能，而付费计划则提供了更多高级功能和支持服务。Gitee也提供了免费和付费服务，但具体的功能和定价模式可能与GitHub有所不同。

1.43 其他

腾讯、华为、阿里等都有各自的代码托管平台，有的也支持git，有的则是自家的工具。

另外，csdn的gitcode也支持git，入口就在本页面的左上方。

二、git配置及git仓库概念

本文使用的代码托管平台是github。

2.1 安装和配置

2.11 windows 下配置git

▶ 安装和更新

安装不讲了，环境变量什么的都老生常谈了。

不会的看我以前的文章：https://blog.csdn.net/weixin_43764974/article/details/122258533

推荐使用git bash，可以用一些Linux下的命令，你喜欢cmd、powershell也可以。

查看版本：git --version

更新一下：去官网下载windows版的，重新安装（不用卸载之前安装的，安装的时候会自动卸载，并且安装在原来的位置）：https://git-scm.com/download/win

已经更新到最新版：

▶ 配置文件与凭据

windows下git的配置文件位于用户主目录下（注意打开“显示隐藏文件”）：

这是一个文本文件，随便用编辑器打开就能编辑了，配置git即修改该文件的一些参数值，不过推荐使用命令行命令配置。

一下是一个基本的.gitconfig文件的内容：

[core]
	editor = \"E:\\VS Code\\bin\\code\" --wait
[filter "lfs"]
	smudge = git-lfs smudge -- %f
	process = git-lfs filter-process
	required = true
	clean = git-lfs clean -- %f
[user]
	name = xxxxx
	email = xxxxxx
[credential "https://gitee.com"]
	provider = generic
[http]
	sslVerify = true

各个配置项的含义：

• [core]：可选项，一般不用手动配置，上面的配置中，指定了Visual Studio Code作为默认的文本编辑器，你在安装git的时候就会让你选择默认编辑器。这个选项主要指定需要编辑git相关文件时默认打开哪个编辑器，比如你双击.gitconfig，就会默认打开vs code来编辑（你右键选择其他编辑器也是一样的）。
• [filter "lfs"]：可选项，这是Git LFS过滤器的配置部分，其中 “lfs” 是过滤器的名称，即Large File Storage，用于管理大型文件的存储和版本控制。上面的配置文件中：
  • smudge = git-lfs smudge – %f：这个配置定义了Git LFS的"smudge"操作。当从远程仓库拉取文件时，Git LFS会使用smudge命令对文件进行转换。具体地，git-lfs smudge – %f将应用于从远程仓库拉取的文件（%f 是文件的占位符）。这个命令会将存储在Git LFS中的文件还原为其原始形式，使其在本地工作区可用。
  • process = git-lfs filter-process：这个配置定义了Git LFS的"filter-process"操作。它在Git操作期间作为过滤器应用于文件。git-lfs filter-process命令会在Git操作期间处理文件，以确保它们符合Git LFS的要求。
  • required = true：这个配置指定Git LFS是必需的，即要求仓库中的大型文件必须使用Git LFS进行管理。
  • clean = git-lfs clean – %f：这个配置定义了Git LFS的"clean"操作。当执行Git提交操作时，Git LFS会使用clean命令对文件进行处理。具体地，git-lfs clean – %f将应用于要提交的文件（%f 是文件的占位符）。该命令会将大型文件替换为Git LFS所需的占位符，以便将其存储在远程Git LFS服务器上。
• [user]：用户信息。自定义即可，这个用于标识你的身份，即你提交时的身份信息。（不是一定要设置为github账户的用户名和邮件）
  • name：用户名
  • email：邮件。
• [credential xxx]：用于配置与特定主机相关的凭据提供程序。
  • [credential “https://gitee.com”]
    provider = generic ，在这个配置中，[credential “https://gitee.com”]指定了针对https://gitee.com主机（gitee）的凭据提供程序为"generic"。这意味着当Git需要在与https://gitee.com进行交互的操作（例如克隆、推送等）中进行身份验证时，它将使用"generic"凭据提供程序来获取必要的凭据。
• [http]：[http]部分的sslVerify选项用于控制对HTTPS连接的SSL证书验证。

上面的.gitconfig文件中的配置是全局配置，如果项目没有进行特殊配置，则默认使用上面的配置。单独某个项目的配置，后面讲。

上面配置中的凭据含义：

“凭据”（Credentials）是用于进行身份验证和访问受保护资源的信息，通常包括用户名和密码、访问令牌或SSH密钥等。与远程仓库进行交互时，例如克隆、推送或拉取操作，Git可能需要验证身份以获得访问权限。

凭据用来证明自己是合法用户，并获得对特定资源的访问权限。这样，Git可以识别用户的身份，并根据用户的权限级别来控制对仓库和其他资源的操作。

---

常见的凭据类型包括：

1. 用户名和密码：这是最常见的凭据类型，用于验证用户身份。用户名和密码将用于与远程仓库进行身份验证。这里的用户名和密码是你代码托管平台账户的用户名和密码。
2. 访问令牌：访问令牌是一种特殊的凭据，通常是生成的字符串。可以使用访问令牌来代替密码进行身份验证，以增加安全性。访问令牌具有特定的权限范围，可以在需要访问受保护资源时提供给Git。
3. SSH密钥：SSH密钥是一对加密密钥，包括私钥和公钥。私钥存储在你的计算机上，而公钥则存储在远程仓库上。Git使用SSH密钥来进行身份验证和安全通信，而无需每次交互时输入密码。
   
   建议使用令牌或者SSH秘钥。

在命令行设置git用户名和邮箱：

git config --global user.name "your name"
git config --global user.email "[email protected]"

设置SSH秘钥作为凭据：

（1）生成ssh密钥对

使用更安全的 ED25519 密钥， 在git bash中输入：

ssh-keygen -t ed25519 -C "[email protected]"

不要使用老版本的rsa加密算法了，否则push、clone可能会出现permission denied 的错误。

你可以其github的帮助页面（help）看更多信息：https://docs.github.com/zh/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

生成的秘钥对在用户主目录的.ssh目录下面：

.pub是公钥，另一个是私钥。私钥自己保存，公钥部署到github。

ssh公私钥不仅仅可以用于git，其他使用ssh协议的地方也可以使用，比如ssh远程登录。

（2）部署公钥到github

在github点击自己的头像，settings, 选择SSH and GPG keys，添加新的，然后吧公钥内容复制进去就行了。

gitee也是一样的，都是中文，不用讲了。

验证OK：

GPG（GNU Privacy Guard）是一个免费、开源的加密软件套件，用于进行数据加密、签名和认证。它是对OpenPGP标准的实现，OpenPGP是一种公钥加密和电子签名协议。github和gitee都支持的。

2.12 Linux

▶ 安装和更新

一般都默认安装的，没有的拿包管理器安装一下就行了。

apt install git

查看已安装的版本：

root@CQUPTLEI:~# git --version
git version 2.25.1

更新一下：

# 添加PPA源
add-apt-repository ppa:git-core/ppa
# 更新软件版本信息
apt update
# 升级git
apt upgrade git

▶ 配置文件与凭据

Linux下的git配置文件同样在用户主目录下。普通用户就是对应的home目录，root用户就是root目录下。下面的示例中，我是用root用户身份操作的。

如果没有使用过git，是默认没有配置文件的。可以使用：

git config --global user.name "your name"
git config --global user.email "[email protected]"

配置用户名和邮箱，这样会自动创建.gitconfig文件；也可以手动创建。

这里就配置一个用户名和邮箱吧。需要其他配置的可以参考上面windows的配置文件进行设置。

同样使用SSH秘钥来进行身份验证。

生成密钥对已经密钥对的存储位置和windows是一样的，把公钥复制到github即可。如图，我添加了3台设备的公钥：

2.2 git 仓库与工作区

先看一些简单概念，具体的要和命令结合起来介绍。

仓库（Repository）是用于存储和管理项目代码的地方。仓库包含了项目的所有版本历史、分支、标签以及与远程仓库的连接。它是Git的核心概念之一，提供了版本控制和协作开发的功能。

Git仓库可以分为两种类型：本地仓库和远程仓库。

• 本地仓库（Local Repository）：本地仓库是存储在本地计算机上的Git仓库副本。它是开发者在开发过程中与之交互的主要仓库。通过在本地仓库中保存所有版本的代码，可以随时回溯到以前的提交并进行修改。可以在本地仓库中执行各种Git操作，例如提交代码、创建分支、合并分支等。本地仓库通常位于项目根目录下的.git文件夹中。
• 远程仓库（Remote Repository）：远程仓库是位于远程服务器上的Git仓库。它充当了代码的中央存储库，用于团队成员之间的协作和代码共享。远程仓库可以托管在各种Git托管平台（如GitHub、GitLab、Bitbucket等）或自己搭建的服务器上。可以将本地仓库中的代码推送（push）到远程仓库，或者从远程仓库拉取（pull）最新的代码到本地仓库。

使用Git开发时，本地工作区由3部分组成：

可能有的叫法不一样，比如暂存区有的人也叫index或者HEAD，理解即可。

1. 工作目录（Working Directory）：工作目录是在本地计算机上存储项目文件的目录。它是进行实际代码编辑和开发的地方。工作目录中包含项目的源代码、配置文件、图像文件等。可以在工作目录中创建、修改和删除文件，以进行项目开发。
2. 暂存区（Staging Area）：暂存区是位于本地仓库中的一个缓冲区域。它用于暂时存放将要提交的文件修改。在工作目录中对文件进行修改后，可以使用git add命令将修改的文件添加到暂存区。通过暂存区，可以选择性地准备要提交的文件。（注意，文件本身还是存储在工作目录的，暂存区只是存储文件快照，后面会结合命令仔细讲解）
3. 本地仓库（Local Repository）：本地仓库是存储在本地计算机上的Git仓库，它包含了项目的完整版本历史和元数据。本地仓库通常是一个隐藏的.git目录，位于项目的根目录下。它存储了Git的版本历史、分支、标签等信息。您可以在本地仓库中查看提交历史、创建和切换分支、合并分支等操作。（同样的，它也不存储实际的项目文件）

三、Git 单分支

只有一个分支时的简单操作。

3.1 从本地到远程

本小节，我将在Linux上创建git本地仓库，并提交到远程。windows下的命令都是一样的。

3.11 创建本地git仓库：git init

这是还没有创建本地git仓库时的工作目录：LinuxC

使用命令：git init 创建本地git仓库。

会多出一个.git目录：

它的内容如下：

来详细看看每一项都是什么东东：

1. branches目录：此目录保存了每个分支的具体信息，每个分支都对应一个文件，文件名就是分支的名称。这些文件记录了分支的最新提交（commit）的哈希值。
2. config文件：此文件包含了Git仓库的配置信息，例如远程仓库的URL、分支的跟踪配置、用户信息等。通过修改此文件，可以自定义Git的行为。
3. description文件：此文件包含了对仓库的描述信息。通常情况下，该文件内容为空，但在一些Git服务商（如GitLab）中，可以使用此文件为仓库添加描述。
4. HEAD文件：此文件指示当前活动的分支。它包含一个引用，指向当前所在分支或者直接指向某个具体的提交（commit）。
5. hooks目录：此目录包含了Git的钩子脚本。钩子是在特定Git事件发生时执行的脚本，可以用于自定义和控制Git的行为。
6. info目录：此目录包含了一些包含Git仓库信息的文件，例如exclude文件，用于指定应该被忽略的文件和目录。
7. objects目录：此目录保存了Git仓库中的所有对象，包括提交（commit）、树（tree）和文件的内容。Git使用哈希算法来对这些对象进行索引和存储。
8. refs目录：此目录保存了Git仓库中的引用（references），包括分支、标签和远程跟踪分支的信息。这些引用文件存储了指向具体提交（commit）的哈希值。

OK，这就是 git init后创建的文件。再返回来看看git init：

他还给出了这些提示信息：

1. git init使用master作为本地初始分支的名称，这是这个默认分支的默认名称；
2. master这个默认名称并不是固定不变的；
3. 通过运行git config --global init.defaultBranch ，你可以将替换为你想要的默认分支名称，当然了，不配置的话，就是默认的master。
4. 建议一些常用于替代’master’的分支名称，包括’main’、'trunk’和’development’等。
5. 通过运行git branch -m ，你可以将替换为你想要的新分支名称，从而更改当前分支的名称。

执行git init后，Git会开始跟踪当前目录下的文件变化。你可以使用git add命令将文件添加到暂存区，然后使用git commit命令将文件提交到版本历史记录中。

继续来看下一个命令：git add

3.12 将文件添加到暂存区：git add

git add用于将文件或目录添加到Git的暂存区（staging area）。它是将文件纳入版本控制的第一步。

常用的命令格式有：

（注意命令中的<>表示这是个参数，并不是要把参数放在<>里面，不要误会了）

① 添加单个文件：

git add <文件名>

② 添加多个文件：使用空格分隔多个文件名

git add <文件名1> <文件名2> ...

③ 添加所有文件：使用点号（.）来表示当前目录下的所有文件，并将它们添加到暂存区：

git add .

注意：点号后面的空格是必需的。

④ 添加目录：

git add <目录名>

这将递归地将目录下的所有文件和子目录都添加到暂存区。

⑤ 添加文件内容的部分更改：如果只想将文件的部分更改添加到暂存区，可以使用交互式模式（git add -p）或分段添加模式（git add --patch）。这样可以逐个检查文件的更改，并选择性地将更改添加到暂存区。（会一个一个地问你是否要将修改过的文件添加到暂存区，，更精细）

git add -p

⑥ 添加文件模式的更改：除了文件内容的更改，Git还跟踪文件的模式更改（例如，添加新文件、删除文件等）。可以使用以下命令将文件模式更改添加到暂存区：

git add -A

这会添加所有文件内容和模式的更改。

如果文件没有发生修改，执行git add命令时，Git会忽略该文件，并保持其未跟踪状态，不会将其添加到暂存区。只有修改过的文件才需要通过git add命令将其添加到暂存区，以便将这些更改提交到版本控制。

Git使用文件的状态来判断是否需要将文件添加到暂存区。当你执行git status命令时，会显示文件的状态信息，主要包括以下几种状态：

1. 未跟踪（Untracked）：表示文件尚未被Git跟踪。这些文件不会被自动添加到暂存区，需要使用git add命令将其添加进去。
2. 已修改（Modified）：表示文件已经被修改过，但尚未添加到暂存区。只有执行了git add命令后，修改过的文件才会被添加到暂存区。
3. 已暂存（Staged）：表示文件已经被添加到暂存区，等待下一次提交。这些文件的更改会在执行git commit命令时被纳入版本历史。

如图所示，还没有提交过：

添加到暂存区后：

前面讲了.git目录，我们再来看看git add后，该目录下文件的变化：

• index: 这是 Git 的索引文件，也称为暂存区。当你执行 git add 命令后，该文件会记录被添加到暂存区的文件信息和状态的更改。（里面的内容是二进制，打开应该是乱码）
• HEAD: 这个文件指向当前所在的分支（或其他提交对象），它会随着提交的变化而更新。
  
• objects/: 这个目录是 Git 用来存储对象（例如提交对象、树对象和文件对象）的地方。当你执行 git add 命令后，新的文件对象会被创建，并存储在这个目录中。

当然了，这些东西，一般你无需关心，这里只是展示一下。

取消已经执行的 git add 操作（通常不用，但是看一下）：

git reset

执行 git reset 命令后，暂存区中的所有更改将被移除，但工作目录中的文件更改将保持不变。这意味着之前通过 git add 添加到暂存区的文件将回到未暂存的状态。

如果你只想取消某个特定文件的 git add 操作，可以指定该文件的路径：

git reset <文件名>

请注意，执行 git reset 命令后，之前添加到暂存区的更改将不会被保留，你需要重新添加文件到暂存区以进行提交。

另外，如果你已经执行了 git commit 提交操作，并且想要撤销最近的提交并取消暂存区的更改，可以使用 git reset 命令的 --soft 选项：

git reset --soft HEAD^

该命令会将分支的指针移动到上一个提交，同时保留暂存区的更改。这样你可以进行新的提交，或者对之前的更改进行修改后再次提交。

注意，在使用 git reset 命令时要小心，特别是在与远程仓库共享代码的情况下。如果已经将提交推送到远程仓库，撤销提交后可能需要进行协调和沟通以避免代码冲突或数据丢失。

3.13 提交：git commit

git commit 用于将更改保存到代码仓库中（local repository）。当你在 Git 项目中做出修改后，你需要使用 commit 命令将这些修改提交到代码仓库，以便它们成为项目历史的一部分。

git commit 包含了以下几个关键要素：

1. 代码快照（Snapshot）：每次提交都会创建一个代码库的快照。这个快照包含了你在提交时项目中所有文件的当前状态。因此，每次提交都会记录整个项目的状态，而不仅仅是更改的文件或行。

2. 提交对象（Commit Object）：每个提交都被视为一个独立的对象，包含了与提交相关的元数据和指向前一个提交的指针。这些提交对象形成了一个有向无环图（DAG），它展示了项目历史的演化。
   

3. 唯一标识符（SHA-1 Hash）：每个提交都有一个唯一的标识符，称为 SHA-1 哈希值。该哈希值由提交对象的内容计算而来，因此每次提交都有不同的哈希值。这个哈希值可以用于引用提交，例如回滚到特定的提交或者在分支之间进行合并。

4. 作者和提交者信息：每个提交都包含了作者和提交者的信息，包括姓名和电子邮件地址。这些信息可以帮助你追踪代码的贡献者。

5. 提交消息（Commit Message）：每个提交都应该包含一个相关的提交消息，用于描述提交所做的更改。提交消息是一个文本块，可以提供有关提交的详细信息，例如为什么进行了更改、更改的目的等。良好的提交消息可以帮助项目成员理解和回顾更改的原因。

Git commit 命令的基本格式如下：

git commit -m "Commit message"

其中，-m 参数用于指定提交消息。你可以在双引号内提供有关提交的简短描述。请注意，提交消息应该清晰、简洁，并且能够准确描述你所做的更改。

除了 -m 参数外，git commit 命令还支持其他选项和参数，可以根据需要进行使用。以下是一些常用选项：

-a：自动将所有已修改或已删除的文件添加到暂存区后执行提交。这个选项可以简化提交流程，但不会包括新添加的文件。

-am：组合使用 -a 和 -m 选项，可以直接在命令中指定提交消息，并自动添加已修改或已删除的文件。

-v：在提交消息前显示更改的差异信息，用于检查即将提交的内容。

-p：逐个提示你确认是否要将每个已修改的文件添加到提交中。

3.14 关联本地仓库和远程仓库：git remote add

要将本地仓库的内容推送到远程仓库，还需要将本地仓库与远程仓库关联起来。

（1）创建远程仓库

在远程代码托管平台（如GitHub、GitLab或Bitbucket）上创建一个新的空仓库（不是空的也行，留在后面的分支部分说，这里先选public）。获取远程仓库的URL，它通常以 https:// 或 git:// 开头（比如我使用ssh）。

（2）在本地仓库中添加远程仓库

打开终端或命令提示符，导航到你的本地仓库所在的目录。运行以下命令将远程仓库添加到本地仓库：

git remote add origin <远程仓库的URL>

这里的 origin 是一个远程仓库的别名，你可以根据需要自定义。该命令将远程仓库的URL与别名关联起来。

（3）验证远程仓库的关联

运行以下命令验证是否成功将远程仓库关联到本地仓库：

git remote -v

这会显示与本地仓库关联的远程仓库列表和对应的URL。确认远程仓库正确关联后，你就可以继续进行其他 Git 操作，例如推送代码到远程仓库或拉取远程仓库的更新。

3.15 推送：git push

git push 的基本语法为：

git push <远程仓库名称> <本地分支名称>:<远程分支名称>

其中，<远程仓库名称> 是远程仓库的别名，可以使用 git remote -v 命令查看已经关联的远程仓库名称。<本地分支名称> 是你想要推送的本地分支的名称，<远程分支名称> 是你想要将本地分支推送到的远程分支的名称。

如果你在推送时想要将本地分支与远程分支关联起来，可以使用以下语法：

git push -u <远程仓库名称> <本地分支名称>:<远程分支名称>

-u 参数会将本地分支设置为远程分支的上游（upstream）分支，这样你之后可以使用 git push 命令推送更改，而不需要指定远程和分支名称。

上游分支（upstream branch）是指在当前分支的版本控制历史中，与当前分支存在直接关系的、位于更高级别的分支。通常情况下，上游分支是指当前分支的源分支或追踪的远程分支。

在一个分支关系图中，每个分支都可以有一个或多个直接上游分支。上游分支可以是当前分支的父分支，也可以是当前分支追踪的远程分支。上游分支对于协同开发和分支管理非常重要，它们用于合并、拉取最新的更改以及在多个分支之间同步代码。

举个例子，假设你在本地创建了一个特性分支（feature branch）feature，而这个特性分支是基于远程仓库的 develop分支创建的。在这种情况下，develop 分支就是 feature 分支的上游分支。

在进行版本控制操作时，可以使用上游分支来进行合并、拉取最新更改或者与其他分支同步代码。

除了基本的语法，git push 还支持其他一些选项和参数：

-f：强制推送，即使远程仓库中有更新，也会覆盖远程分支的内容。

--tags：推送本地仓库中的标签（tags）到远程仓库。

--set-upstream：设置本地分支与远程分支的关联，相当于 -u 参数的别名。

--all：推送所有分支到远程仓库。

--mirror：镜像推送，将本地仓库完全复制到远程仓库，包括所有分支和标签。

请注意，在执行 git push 之前，你需要确保先执行了 git commit 将更改提交到本地仓库。否则，git push 将不会有新的更改可以推送。

推送完成：

之后推送到远程的main分支，使用git push就可以了，本地和远程分支名称相同才行，否则使用：git push Remote HEAD:main

出错？
可以使用http，或者在github帮助页面寻求帮助。（如SSH agent 未启动）

如果你新建仓库时，添加了license或者readme文件，需要先pull 才能push:

git pull --allow-unrelated-histories Remote main

(其中Remote是我的远程仓库的别名，main是远程仓库的默认分支)

---

至此，从新建本地仓库，到成功推送到远程，已经完成了。

这是最最最基本的操作，但是实际使用中远不止这些操作。

3.2 从远程到本地

3.21 克隆：git clone

git clone 用于从远程仓库克隆（复制）一个完整的仓库到本地。它的使用格式如下：

git clone <remote_repository_url> <local_directory>

其中， 是远程仓库的 URL，可以是 HTTP、HTTPS 或 SSH 协议的地址，指向你想要克隆的仓库。 是要将仓库克隆到的本地目录的路径。（直接去仓库那里复制就行了）

使用 git clone 命令会创建一个与远程仓库相同的副本，并自动设置远程仓库的别名为 origin。它会下载仓库的所有历史记录、分支和标签，并在本地创建一个与远程仓库相对应的默认分支（通常是 main 或 master 分支）。通过克隆仓库，你可以开始在本地进行开发和版本控制。

注意：

默认情况下，git clone 命令只会克隆远程仓库的默认分支（通常是 main 或 master分支）。它不会克隆远程仓库中的所有分支。但是，克隆仓库时会下载整个仓库的历史记录，包括所有的分支和标签信息。

使用这里的url即可：

这里有个下载压缩包选项，他和git clone是不一样的：

• 直接下载 ZIP 压缩包是从远程仓库下载代码的一种简单方式，不涉及 Git 工具或版本控制。
• ZIP 压缩包只包含了当前的代码快照，没有版本控制历史记录、分支和标签等元数据。
• 下载的 ZIP 压缩包可以用于浏览代码、查看文件内容，但无法进行版本控制或分支管理。
• 如果需要更新代码，必须重新下载 ZIP 压缩包，而不能像使用 Git 那样轻松地获取最新更新。

如果你只是向抄个代码，下载压缩包是可以的。

我这里在Linux上克隆前面创建并且推送后的远程仓库：

来看看克隆后的仓库的名称：

• * main：表示当前所在的分支是 main 分支。* 符号表示当前活动分支。
• remotes/origin/HEAD -> origin/main：表示远程仓库的 HEAD 引用指向的是 origin/main 分支。这是远程仓库中默认分支的别名。
• remotes/origin/main：表示远程仓库的 main 分支。
• 而远程仓库的别名默认设置成了origin

3.22 拉取：git pull

git pull 命令用于从远程仓库拉取最新的代码，并将其合并到当前分支中。它实际上是两个操作的组合：git fetch 和 git merge。

使用 git pull 命令的基本语法是：

git pull <remote> <branch>

 表示远程仓库的名称，通常是 origin，表示默认的远程仓库。
 表示要拉取的远程分支的名称。

例如，如果你想从远程仓库的 origin 中拉取 master 分支的最新代码，可以运行以下命令：

git pull origin master

git pull 命令的执行过程如下：

• 首先，git fetch 命令会从远程仓库下载最新的提交和分支信息，但不会将其合并到当前分支。

• 然后，git merge 命令会将远程分支的更改与当前分支进行合并。如果存在冲突，你需要解决冲突后再进行提交。

注意，git pull 命令默认会尝试将远程分支与当前分支进行合并。如果你想拉取远程分支的内容而不进行合并，可以使用 git fetch 命令。

另外，你还可以使用 git pull --rebase 命令来在拉取远程代码之前先将当前分支的提交应用到拉取的代码之上，这将使提交历史更加线性。这个过程称为变基（rebase），但请注意，在进行变基操作时可能会产生冲突，需要解决冲突后再进行提交。

现在我删除了远程仓库中的2个目录。并且提交到.gitignore文件中（5.1节），并且在Windows上重新推送。

在Linux进行git pull操作：

拉取后，会删除我之前克隆的2个文件夹，因为我在Windows侧已经为远程删除并且添加了 .gitignore文件。后面还有详细解决这部分。

四、多分支

4.1

4.2

4.3

五、其他

5.1 .gitignore

.gitignore 是一个用于指定要忽略的文件和目录的 Git 配置文件。它的作用是告诉 Git 哪些文件和目录在版本控制中应该被忽略，不加入到 Git 仓库中。

当你在项目中创建一个 .gitignore 文件并定义了要忽略的文件和目录后，Git 在执行相关操作时会自动忽略这些文件和目录，不会将它们添加到暂存区和提交历史中。这对于排除一些不必要的或敏感的文件、编译生成的文件、临时文件、日志文件等非项目必需的文件非常有用。

以下是一些关键点和使用方法来详细介绍 .gitignore：

1. 文件格式：.gitignore 是一个文本文件，每行包含一个规则。每个规则描述了要忽略的文件或目录的模式。规则可以使用通配符和模式匹配规则。

2. 模式匹配规则：.gitignore 支持三种模式匹配规则：

   • *：匹配任意数量的字符，但不包括目录分隔符 /。
   • ?：匹配单个字符。
   • /：用于指定目录路径。

3. 注释：.gitignore 文件支持使用 # 进行注释。在 # 之后的内容会被视为注释，不会被 Git 解析。
   规则示例：下面是一些 .gitignore 规则的示例：

   build/：忽略名为 build 的目录。
   *.log：忽略所有以 .log 结尾的文件。
   secret.txt：忽略名为 secret.txt 的文件。
   /docs/*.pdf：忽略 docs 目录下的所有以 .pdf 结尾的文件。

4. 全局和局部的 .gitignore：可以在项目根目录下创建一个 .gitignore 文件来针对该项目设置忽略规则。此外，还可以在全局范围内创建一个名为 ~/.gitignore_global 的文件，其中的规则将应用于所有 Git 仓库。你可以使用 git config 命令将全局的 .gitignore 文件与 Git 关联起来。

5. 生效时机：.gitignore 文件的规则仅在它所在的目录及其子目录下生效。如果你想要忽略整个仓库中的某个文件或目录，你需要在相应的根目录下创建 .gitignore 文件。

一般可以使用你使用的IDE来生成gitignore文件，他会忽略掉IDE 相关的不必要文件，你只需要在里面添加额外的你想忽略的文件即可。

比如Visual Studio的：

## Ignore Visual Studio temporary files, build results, and
## files generated by popular Visual Studio add-ons.

# User-specific files
*.suo
*.user
*.sln.docstates

# Build results
[Dd]ebug/
[Rr]elease/
x64/
build/
[Bb]in/
[Oo]bj/

# Visual Studio 2015/2017/2019 cache/options directory
.vs/

# Visual Studio 2017/2019 auto generated files
Generated\ Files/

# MSTest test Results
[Tt]est[Rr]esult*/
[Bb]uild[Ll]og.*

# NUnit
*.VisualState.xml
TestResult.xml

# Build Results of an ATL Project
[Dd]ebugPS/
[Rr]eleasePS/
dlldata.c

# Benchmark Results
BenchmarkDotNet.Artifacts/

# .NET Core
project.lock.json
project.fragment.lock.json
artifacts/

# StyleCop
StyleCopReport.xml

# Files built by Visual Studio
*_i.c
*_p.c
*_h.h
*.ilk
*.meta
*.obj
*.iobj
*.pch
*.pdb
*.ipdb
*.pgc
*.pgd
*.rsp
*.sbr
*.tlb
*.tli
*.tlh
*.tmp
*.tmp_proj
*_wpftmp.csproj
*.log
*.vspscc
*.vssscc
.builds
*.pidb
*.svclog
*.scc

# Chutzpah Test files
_Chutzpah*

# Visual C++ cache files
ipch/
*.aps
*.ncb
*.opendb
*.opensdf
*.sdf
*.cachefile
*.VC.db
*.VC.VC.opendb

# ReSharper is a .NET coding add-in
_ReSharper*/
*.[Rr]e[Ss]harper
*.DotSettings.user

# JustCode is a .NET coding add-in
.JustCode

# TeamCity is a build add-in
_TeamCity*

# DotCover is a Code Coverage Tool
*.dotCover

# AxoCover is a Code Coverage Tool
.axoCover/*
!.axoCover/settings.json

# Coverlet is a free, cross platform Code Coverage Tool
coverage/
*.csproj.dotCover

# NCrunch
_NCrunch_*
.*crunch*.local.xml

# MightyMoose
*.mm.*
AutoTest.Net/

# Web workbench (sass)
.sass-cache/

# Installshield output folder
[Ee]xpress/

# DocProject is a documentation generator add-in
DocProject/buildhelp/
DocProject/Help/*.HxT
DocProject/Help/*.HxC
DocProject/Help/*.hhc
DocProject/Help/*.hhk
DocProject/Help/*.hhp
DocProject/Help/Html2
DocProject/Help/html

# Click-Once directory
publish/

# Publish Web Output
*.[Pp]ublish.xml
*.azurePubxml
# Publish profiles
*.pubxml
*.publishproj

# NuGet Packages Directory
## TODO: If you have NuGet Package Restore enabled, uncomment the next line
#

5.2

tag

issue

六、Github