文章

Git教程

Git基础教程

发表于
Preview Image
作者 ILoveScratch
39 分钟阅读
Git教程

Git 简介

Git 是一个分布式版本控制系统，能够高效地处理从小型到大型的各种项目版本管理。它的设计注重速度、数据完整性和对分布式、非线性工作流的支持。

安装 Git

Windows 安装

  1. 访问 Git for Windows 官网 下载最新安装包。
  2. 运行安装程序，建议使用默认选项，尤其是在选择 “PATH 环境变量” 时建议选择“推荐”。
  3. 可选：
    1. 在安装过程中可以设置默认编辑器（如 Vim、Notepad++、VSCode（或者开源构建VSCodium） 等）。
    2. 选择Git使用方式（只能Git Bash ，Git在CMD中使用（不包括Unix-Like工具），Git和Unix-Like工具在CMD中使用）。 我一般选择 “Git和Unix-Like工具在CMD中使用”。（因为这样可以在CMD中使用一些工具，但是会影响一些重名的Windows工具），一般选择CMD或Bash都可以。
    3. 选择 HTTPS 传输后端（推荐使用 “Use the OpenSSL library”）。
    4. 选择行结束符转换方式（推荐使用 “Checkout Windows-style, commit Unix-style line endings”）。
  4. 安装完成后，在“开始菜单”找到 Git Bash，用它作为命令行环境。

macOS 安装

  • Homebrew 推荐安装方式：

    1

      brew install git

  • 也可以从 Git 官网 下载并安装。

  • 安装完成后，在“终端”输入 git --version 检查安装。

Linux 安装

  • Debian/Ubuntu:

    1
2

      sudo apt update
  sudo apt install git

  • Fedora:

    1

      sudo dnf install git

  • Arch Linux:

    1

      sudo pacman -S git

  • 检查安装：

    1

      git --version

Git 配置

Git 根据配置文件的应用范围，将配置文件分为不同的等级，其中较常用的有两个级别1：

适用于当前用户的全局配置文件，该用户操作本系统上的所有仓库时都会查询该配置文件。 适用于当前仓库的配置文件。 当多个配置文件对同一个选项作出设置的时候，局部设置会自动覆盖全局设置。因此如果需要在某个仓库应用特定的设置的话，只需更改该仓库下的特定设置即可，不会对全局设置造成影响。

修改配置文件需要用到 git config 命令。

设置用户信息 安装 Git 后，第一件事情就是设置你的用户名和邮箱。这些信息在每次提交时都会用到。

如：

1
2

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

给出的用户名和邮箱仅供演示。根据本页面的内容配置时，需要将这里的用户名和邮箱改成自己的信息。

这里的 –global 表示修改的是全局配置，即该设置对当前用户下的所有仓库均有效。如果不添加 –global 选项，则会默认修改当前仓库下的配置文件。

如果想要修改某个仓库的特定设置，只需在该仓库下执行不带 –global 的命令即可。

配置编辑器

还有其他常见可修改信息:

  1. 默认编辑器：

    1

     git config --global core.editor

    可以使用命令行参数指定编辑器，例如：

    1

     git config --global core.editor "code.exe --wait"

    也可以指定路径

    1

     git config --global core.editor "C:/Program Files/Visual Studio Code/code.exe --wait"

  2. 默认合并工具：

    1

     git config --global merge.tool

    合并工具可以帮助你解决合并冲突。（下文将会详细介绍）

  3. 默认diff工具：

    1

     git config --global diff.tool

    diff工具可以帮助你查看文件更改的具体内容，通常情况下使用命令diff即可查看文件更改内容

  4. GPG签名：

    1

     git config --global user.signingkey

    可以设置GPG密钥用于签名提交，增加提交的可信度。 也可以设置自动签名：

    1

     git config --global commit.gpgsign true

    将会在另一篇文章详细介绍

  5. Pull行为：

    1

     git config --global pull.rebase

    可以设置为true, false, 或者merges，分别表示使用rebase, merge, 或者保留合并提交。

    也可以在安装的时候配置，推荐使用Rebase，否则每次Pull到不同内容都会生成一个合并提交。

  6. 默认分支名称：

    1

     git config --global init.defaultBranch main

    可以设置新建仓库时的默认分支名称，通常情况下默认是master。

仓库操作基础

新建 Git 仓库 新建一个 Git 仓库非常简单，只需在想要建立仓库的文件夹输入如下命令：

1

git init

Git 就会在当前文件夹新建一个 .git 文件夹，一个仓库就这样建好了。

也可以指定路径

1

git init <path>

这样会在指定路径下新建一个 Git 仓库。

如果想把一个仓库克隆到自己的电脑上（比如将 leachim6/hello-world（一个所有语言的Hello World） 的代码拷贝到本地上），用 git clone 命令即可。

1

git clone https://github.com/leachim6/hello-world

注意，这样仅会克隆仓库内容，不会克隆Git信息，历史记录等，克隆下来的也不是一个Git仓库。

如果想要克隆出Git仓库（带有Git信息和历史），需要克隆Git地址（即结尾为.git的地址）。

1

git clone https://github.com/leachim6/hello-world.git

这里给出仓库链接是 HTTP(S) 链接.

也支持使用SSH链接：

1

git clone [email protected]:leachim6/hello-world.git

通常情况下，SSH会更方便。但是需要先配置SSH密钥。HTTP(S)则在知道目标地址的情况下比较方便（少打一些字符）

这样，被克隆的仓库的内容就会被储存到当前文件夹下一个与仓库同名的新文件夹。在本例中，当前文件夹下会出现一个名为 hello-world.git 的新文件夹。

跟踪文件

在对仓库的文件做出了一些更改后，这些更改需要被纳入到版本管理当中去。

使用 git status 命令可以查看当前仓库文件的状态。

举个例子，在一个空仓库中新增了一个 README.md。

1

touch README.md # 新建一个 README.md 文件 （Touch工具仅在GNU/Linux(和一些类Unix系统)下，Git Bash下或选择Unix-Like工具的Git安装下可用）

效果如下:

1
2
3
4
5
6
7
8
9
10
11
12

git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        README.md

nothing added to commit but untracked files present (use "git add" to track)

暂存区

这里的 Untracked files 意味着 Git 之前没有加入版本跟踪的文件（新仓库一个都没有）。如果文件没有加入版本跟踪，对那个文件的更改不会被 Git 记录。

执行 git add <文件名称> 命令可以将指定的文件纳入到版本跟踪中。

1
2
3
4
5
6
7
8
9
10

git add README.md # 将文件加入到版本跟踪中
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md

这时 README.md 已经纳入了版本跟踪，放入了暂存区。接下来只需执行 git commit 命令就可以提交这次更改了。

1

notepad.exe README.md # 编辑 README.md 文件

1

vim README.md # 编辑 README.md 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md

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

README.md 同时处于暂存区和非暂存区？？？

实际上，是否处于暂存区是对于更改而言的，而不是对于文件而言的，所以对 README.md 的前一次更改在暂存区里，而第二次更改还没有。如果这时候执行 git commit 命令，只有处于暂存区的更改会被提交，而非暂存区的更改，则不会被提交。

Git 给了一条提示，执行 git add README.md 就可以将非暂存区的更改放入暂存区了。

在大多数情况下，用户更期望一次性将所有更改都放入暂存区中，这时候可以应用 git add -A 或 git add . 命令。该命令会将所有更改（包括未被纳入版本跟踪的文件，不包括被忽略的文件）放入暂存区。

如果只需更新已被纳入版本跟踪的文件，而不将未纳入版本跟踪的文件加入暂存区，可以使用 git add -u。

Git Ignore

有些时候并不希望将一些文件（比如 编译结果，.vscode .idea .DS_Store 等）纳入到版本跟踪中。这时候可以在仓库根目录下创建 .gitignore 文件，在该文件里写下想要忽略的文件。Git 将不会将这些文件纳入到版本跟踪中。

1

notepad.exe .gitignore # 创建 .gitignore 文件

1

vim .gitignore # 创建 .gitignore 文件

支持通配符（wildcard），例如，*.exe 将自动忽略仓库里的所有扩展名为 .exe 的文件。

例子：

1
2
3
4
5
6
7
8

# 忽略所有 .exe 文件
*.exe
# 忽略 .vscode 文件夹
.vscode/
# 忽略所有 .log 文件
*.log
# 忽略 hello.txt 文件
hello.txt

Commit!

现在将非暂存区的文件加入暂存区，将所有更改一并提交（commit）。

1
2
3
4
5
6

git add README.md
$ git commit # 然后会弹出一个编辑器页面，要在里面写下 commit 信息
[master (root-commit) a996761] initial commit
 1 file changed, 2 insertions(+)
 create mode 100644 README.md

解释一下:

[master (root-commit) a996761] 代表这次提交的信息。master 代表当前分支名称，root-commit 代表这是该分支的第一次提交，a996761 是这次提交的 SHA-1 校验码的前七位。 1 file changed, 2 insertions(+) 代表这次提交涉及了 1 个文件的更改，共有 2 行被插入。 create mode 100644 README.md 代表这次提交创建了一个名为 README.md 的新文件，文件权限为 100644。

需要特别关注的是这里的 SHA-1 校验码，每个校验码都与某个时刻仓库的一个快照相对应。利用这一特性我们可以访问历史某个时刻的仓库快照，并在该快照上进行更改。

接下来两行则详细说明了本次更新涉及的文件更改。

另外，commit 过程中可以利用几个参数来简化提交过程：

-a：在提交前将所有已跟踪的文件的更改放入暂存区。需要注意的是未被跟踪的文件（新创建的文件）不会被自动加入暂存区，需要用 git add 命令手动添加。 -m：该参数后跟提交信息，表示以该提交信息提交本次更改。例如 git commit -m “hello world” 会以 “hello world” 作为本次提交的信息。

多个参数可以组合使用，例如：

1

git commit -a -m "update README.md"

Unix风格可以将a m连在一起写成-am。

1

git commit -am "update README.md"

查看提交记录 使用 git log 命令可以看仓库的提交历史记录。

可以看到，提交历史里记录了每次提交时的 SHA-1 校验和，提交的作者，提交时间和 commit 信息。

这里使用OpenList仓库演示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

git log

commit 15f276537c9940ec777b8bc268d100b8453aa69b (HEAD -> main, tag: v4.1.5, origin/main)
Author: ILoveScratch <[email protected]>
Date:   Sun Oct 19 22:48:21 2025 +0800

    fix(share): remove share when user delete (#1493)

commit 623a12050e7df5cf73f0c44b81e4722df3ea880a
Author: MadDogOwner <[email protected]>
Date:   Sun Oct 19 22:45:40 2025 +0800

    feat(openlist): add PassIPToUpsteam to driver (#1498)

...

注意: 通常你会发现很多时候并没有显示全，这是因为 Git 默认使用分页器（pager）来显示日志内容。按Enter键可以逐行浏览日志，按Space键可以逐页浏览日志，按q键可以退出日志查看。

大部分软件还会使用Conventional Commits规范来编写提交信息，这样可以让提交信息更有意义，也方便生成变更日志等。

分支管理

为什么版本管理中需要分支管理呢？答案主要有两点：

直接更改主分支不仅使历史记录混乱，也可能会造成一些危险的后果。 通过分支，我们可以专注于当前的工作。如果我们需要完成两个不同的工作，只需开两个分支即可，两个分支间的工作互不干扰。 不同的分支还同样可以用来版本和环境管理。

在 Git 中，简单来说，分支就是指向某个快照的指针。每次提交时，Git 都会为这次提交创建一个快照，并将当前分支的指针移动到该快照。

另外还有一个 HEAD 指针，它指向当前所在的分支。

切换分支的过程，简单来说就是将 HEAD 指针，从指向当前所在的分支，改为指向另外一个分支。在这一过程中，Git 会自动完成文件的更新，使得切换分支后仓库的状态与目标分支指向的快照一致。

分支的创建 利用 git branch 命令可以创建分支，git switch 命令可以切换分支，git switch -c 命令可以创建分支并切换到这个新分支。

1
2
3

git branch dev-branch # 创建一个叫做 dev-branch 的新分支
git switch dev-branch # 切换当前分支到 dev-branch
Switched to branch 'dev-branch'

1
2
3
4
5

git switch -c dev # 创建一个叫做 dev 的新分支并切换当前分支到 dev
Switched to branch 'dev'
git branch # 查看分支列表
  master
* dev

dev 前面的星号代表该仓库的当前分支为 dev，接下来对这个仓库的更改都将记录在这个分支上。

试着创建一个新文件 welcome.txt 并提交：

1

notepad.exe welcome.txt # 创建 welcome.txt 文件

1

vim welcome.txt # 创建 welcome.txt 文件

1
2
3
4
5

git add welcome.txt
git commit -m "add welcome.txt"
[dev 5da093b] add welcome.txt
 1 file changed, 1 insertion(+)
 create mode 100644 welcome.txt

现在切回 master 分支，查看 welcome.txt 文件是否存在：

1
2
3
4
5
6
7
8
9

git switch master
Switched to branch 'master'

git status
On branch master
nothing to commit, working tree clean

ls # 或者 dir (Windows CMD)
README.md

可以看到 welcome.txt 文件并不存在于 master 分支上。因为这个文件是被添加到 dev 分支上的。

切回 dev 分支，welcome.txt 文件又会出现：

1
2
3
4
5
6
7
8
9

git switch dev
Switched to branch 'dev'

git status
On branch dev
nothing to commit, working tree clean

ls # 或者 dir (Windows CMD)
README.md  welcome.txt

分支的合并

当一个分支上的工作已经完成，就可以将这些工作合并到另外一个分支上去。

还是接着上面这个例子，dev 分支的工作已经完成，通过 git merge 命令可以将该分支合并到当前分支（master）上：

$ git merge dev Merge made by the ‘recursive’ strategy. welcome.txt | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 welcome.txt

这次合并具体是怎么执行的呢？

在合并之前，master 指向 5ca15f0，而 dev 指向 5da093b，这两个状态并不在一条链上。

Git 会找到这两个状态的最近公共祖先（在上图中是 ae9dd37），并对这三个快照进行一次合并。三个快照合并的结果作为一个新的快照，并将当前分支指向这一快照。

合并过程本身也是一次提交，不过与常规提交不同的是，合并提交有不止一个前驱提交，它是多个提交状态合并后的结果。

在合并完成后，dev 分支就完成了它的使命，这时候可以利用下面的命令删除 dev 分支：

1

git branch -d dev

对于未合并的分支，可以使用 -D 参数强制删除

Conflicts

不过合并过程并非总是这么顺利，在某些情况下，合并过程可能会出现冲突，这个问题接下来会讲到。

如果在两个分支中，对同一个文件的同一部分进行了不同的更改，Git 就无法自动合并这两个分支，也就是发生了合并冲突。

接着上面的例子，假如你在合并后的 master 分支的基础上，新开了一个 readme-refactor 分支，准备重写一份自述文件。但因为一些疏忽，你同时更改了 readme-refactor 和 master 分支的自述文件。

刚开始自述文件是这样的：

1

# This is a test repo.

在 readme-refactor 分支下的自述文件是这样的：

1

# Test

在 master 分支下的自述文件是这样的：

1

# This is a test test repo.

这时候运行 git merge readme-refactor 命令，Git 提示出现了合并冲突。

执行一下 git status 命令，可以查看是哪些文件引发了冲突。

1
2
3
4
5
6
7
8
9
10
11

git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:      README.md

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

如何解决冲突？对于每个发生了合并冲突的文件，Git 都会在这些文件中加入标准的冲突解决标记。比如这个例子中的 README.md 文件，打开后它长这个样子：

1
2
3
4

<<<<<< HEAD
# This is a test repo.
======
# This is a test test repo.

====== 作为分界线将两个分支的内容隔开，««« HEAD 标记和 ====== 之间的部分是 HEAD 指针（master 分支）的内容，而 ====== 和 »»» readme-refactor 标记之间的部分是 readme-refactor 分支的内容。

通过编辑文本来处理冲突，删除这些冲突标记，保存文件，将这些文件纳入暂存区后提交，就可以解决合并冲突了。

编辑 README.md 文件如下：

1

# This is a test repo. It has been refactored.

1
2
3

git add README.md # 注意：即使解决了冲突，也需要将文件加入暂存区，不然Git不会认为你修改了
$ git commit
[master fe92c6b] Merge branch readme-refactor into master

其他合并方式

默认情况下，Git 采用 Merge（合并）的方式合并两个分支。使用该方法将分支 B 并入分支 A 时，会将 B 分支的所有 commit 并入 A 分支的提交历史中。

除此以外，Git 还提供了两种合并分支的方式：Squash（压缩）和 Rebase（变基）。

Squash（压缩）

使用 Squash 方式将分支 B 并入分支 A 时，在 B 分支上的所有更改会被合并为一次 commit 提交到 A 分支。

在 git merge 中加入 –squash 参数即可使用 Squash 方式进行分支合并。

git merge <branch> --squash

需要注意的是，在执行上述命令后，Git 只会将 B 分支的所有更改存入 A 分支的缓冲区内，接下来还需要执行一次 git commit 命令完成合并工作。

使用 Squash 方式合并可以简化 commit 记录，但是会丢失具体到每一次 commit 的信息（每次 commit 的提交者，每次 commit 的更改等等），只留下合并为一个整体的信息（每次 commit 的提交者会以 “Co-authored-by” 的形式在提交信息中列出）。但如果是在 GitHub 上进行 Squash and Merge，原有的信息都可以在 Pull Request 中查看。

Rebase（变基）

使用 Rebase 方式将分支 B 并入分支 A 时，在 B 分支上的每一次 commit 都会单独添加到 A 分支，而不再像 Merge 方式那样创建一个合并 commit 来合并两个分支的内容2。

首先，切换到 B 分支，接下来将 B 分支变基到 A 分支：

1
2

git checkout B
git rebase A

现在切回到 A 分支，再执行一次 git merge 命令，即可完成将 B 分支的内容合并到 A 分支的工作。

1
2

git checkout A
git merge B

使用 Rebase 完成合并可以让提交历史线性化，在适当的场景下正确地使用 Rebase 可以达到比 Merge 更好的效果。但是这样做会改变提交历史，在进行 Rebase 时和 Rebase 后再进行相关合并操作时都会增加出现冲突的可能，如果操作不当可能反而会使提交历史变得杂乱。因此，如果对 Rebase 操作没有充分的了解，不建议使用。

管理远程仓库

在本地完成更改后，你可能会需要将这些更改推送到 GitHub 等 Git 仓库托管平台上。托管在这些平台上的仓库就归属于远程仓库的范畴——你可以从这些仓库中获取信息，也可以将你作出的更改推送到远程仓库上。与其他人的协作往往离不开远程仓库，因此学会管理远程仓库很有必要。

远程仓库的查看

使用 git remote 命令可以查看当前仓库的远程仓库列表。

如果当前仓库是克隆来的，那么应该会有一个叫做 origin 的远程仓库，它的链接就是克隆时用的链接。

1
2

git remote
origin

如果要查看某个远程仓库的详细信息的话，可以这样操作：

1
2
3
4
5
6
7
8
9
10
11

git remote show origin


$ git remote show origin
* remote origin
  Fetch URL: https://github.com/OpenListTeam/OpenList.git
  Push  URL: https://github.com/OpenListTeam/OpenList.git
  HEAD branch: main
  Remote branches:
    main            tracked
  ...

远程仓库的配置 执行 git remote add <name> <url> 命令可以添加一个名字为 name，链接为 url 的远程仓库。

执行 git remote rename <oldname> <newname> 可以将名字为 oldname 的远程仓库改名为 newname。

执行 git remote rm <name> 可以删除名字为 name 的远程仓库。

执行 git remote get-url <name> 可以查看名字为 name 的远程仓库的链接。

执行 git remote set-url <name> <newurl> 可以将名字为 name 的远程仓库的链接更改为 newurl。

从远程仓库获取更改

在远程仓库中，其他人可能会推送一些更改，执行 git fetch 命令可以将这些更改获取到本地。

1

$ git fetch <remote-name> # 获取 <remote-name> 的更改

需要注意的是，git fetch 命令只会获取远程仓库的更改，而不会将这些更改合并到本地仓库中。如果需要将这些更改进行合并，可以使用 git pull 命令。在默认情况下，git pull 相当于 git fetch 后 跟着 git merge（或rebase，根据你的配置，参见开头的配置介绍）

1

$ git pull <remote-name> <branch> # 获取 <remote-name> 的更改，然后将这些更改合并到 HEAD

将更改推送到远程仓库 当你完成了一些更改之后，使用 git push 命令可以将这些更改推送到远程仓库。

1

git push <remote> <from>:<to> # 将本地 <from> 分支的更改推送至 <remote> 的 <to> 分支

根据远程仓库的要求，可能会要求你输入远程仓库账户的用户名和密码。

需要注意的是，你的更改能成功推送，需要满足两个条件：你拥有向这个仓库（分支）的写入权限，且你的这个分支比远程仓库的相应分支新（可以理解为没有人在你进行更改的这段时间进行了推送）。当远程分支有当前分支没有的新更改时，可以执行 git pull 命令完成合并再提交。

如果你需要强制将本地分支的更改推送到远程仓库的话，可以加入 -f 参数。此时 远程仓库的提交历史会被本地的提交历史覆盖，因此该命令应谨慎使用。更好的选择是使用 –force-with-lease 参数，该参数仅在远程仓库没有更新时才会进行覆盖。

追踪远程分支

通过将一个本地分支设定为追踪远程分支，可以方便地查看本地分支与远程分支的差别，并能简化与远程分支交互时的操作。

在开始追踪前，你需要先执行 git fetch <remote-name> 将远程仓库的信息抓取到本地。

接下来执行 git switch <remote-branch>，会在本地自动创建名字为 的新分支，并设定该分支自动追踪相应的远程分支。

需要注意，只有当本地不存在该分支，且恰好只有一个远程分支的名字与该分支匹配时，Git 才会自动创建该分支且设定其追踪相应的远程分支。

这时候执行 git status 命令，会提示当前分支与远程分支之间的差别。

因为设定了本地分支追踪的远程分支，向远程分支推送的命令也被简化了。只需要执行 git push 命令，在本地分支上作出的更改就能被推送至其追踪的远程分支。

对于本地已有的分支，设定其对应的远程追踪分支也很容易。只需在当前分支下执行 git branch -u <remote-name>/<remote-branch>，就可以设定当前的本地分支追踪 / 这一远程分支。

Tag

Tag（标签）用于给某个特定的提交打上标记，通常用于标记版本发布点（如 v1.0.0）。与分支不同，Tag 是不会随着新的提交而移动的。

创建 Tag

使用以下命令可以创建一个轻量级的 Tag：

1

git tag <tagname>

如果想创建一个附注 Tag，可以使用：

1

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

查看 Tag

使用以下命令可以查看所有的 Tag：

1

git tag

要查看特定 Tag 的详细信息，可以使用：

1

git show <tagname>

Reset

Git 提供了多种方式来撤销更改，其中 git reset 是一个强大的工具，可以用来重置当前分支的 HEAD 到指定的状态。

使用方式

1

git reset [--soft | --mixed | --hard] <commit>
  • --soft：仅重置 HEAD 到指定的提交，保留暂存区和工作目录的更改。
  • --mixed（默认选项）：重置 HEAD 和暂存区到指定的提交，但保留工作目录的更改。
  • --hard：重置 HEAD、暂存区和工作目录到指定的提交，所有更改都会被丢弃。

比如，要将当前分支重置到上一个提交，可以使用：

1

git reset --hard HEAD~1

也可以使用Commit SHA

1

git reset --hard a996761

注意事项

使用 git reset --hard 会丢弃所有本地在恢复提交后的更改，请谨慎使用，确保你不需要这些更改了。

如果你向GitHub等远程仓库推送了更改，使用 git reset 后需要强制推送（git push -f）以更新远程仓库，这可能会影响其他协作者的工作。

如果你加入了密钥文件并推送到了GitHub等远程仓库，不仅仅是删除提交，还需要更改密钥文件，否则密钥文件依然会存在于历史记录中。（见 https://trufflesecurity.com/blog/guest-post-how-i-scanned-all-of-github-s-oops-commits-for-leaked-secrets）

参考资料

GitHub
GitHub Dev Git 教程
本文由作者按照 CC BY 4.0 进行授权