Help us learn about your current experience with the documentation. Take the survey.

教程：从提交历史中移除密钥

如果您的应用程序使用外部资源，通常需要使用密钥（如 token 或 key）来验证应用程序。如果密钥被推送到远程仓库，任何有权访问该仓库的人都可以冒充您或您的应用程序。如果您意外提交了密钥，仍然可以在推送之前将其移除。

在本教程中，您将提交一个假的密钥，然后在将其推送到项目之前从提交历史中移除该密钥。您还将学习当密钥被推送到仓库时该如何处理。

本教程改编自 GitLab Unfiltered 视频从提交历史中移除密钥。

开始之前

在完成本教程之前，请确保您具备以下条件：

GitLab 通过匹配特定的字母、数字和符号模式来识别密钥。这些模式也用于识别密钥的类型。例如，假密钥 glpat-12345678901234567890 是一个个人访问令牌（personal access token），因为它以字符串 glpat- 开头。

尽管许多密钥可以通过格式识别，但在您使用仓库时，仍可能意外提交密钥。让我们模拟意外提交密钥的情况：

在您的测试仓库中，检出一个新分支：
```
git checkout -b secret-tutorial
```
创建一个包含以下内容的新文本文件，移除 - 前后的空格，以匹配个人访问令牌的确切格式：
```
fake-secret: glpat - 12345678901234567890
message: hello, world!
```

将文件提交到您的分支：

git add .
git commit -m "Add fake secret"

我们创建了一个问题：如果我们推送更改，提交到文本文件中的个人访问令牌将被泄露！在继续之前，我们需要从提交历史中移除该密钥。

如果包含密钥的提交是 Git 历史记录中的最新提交，您可以修改历史记录来移除它：

密钥已从文件和提交历史记录中移除，您可以安全地推送更改。

有时，您在进行了多次额外提交后才发现添加了密钥。在这种情况下，仅从最新提交中删除密钥是不够的。您需要修改密钥被添加后的每个提交：

将假密钥添加到您的文件中并提交到分支。
至少再做一个提交。当您检查历史记录时，应该会看到类似这样的内容：
```
$ git log
commit 456def

    Do other things

commit 123abc

    Add fake secret

...
```
即使我们从提交 456def 中移除密钥，它仍然存在于历史记录中，如果我们现在推送更改，它仍会被暴露。
要修复历史记录，从引入密钥的提交开始交互式变基（rebase）：
```
git rebase -i 123abc~1
```
在编辑窗口中，对于每个包含密钥的提交，将 pick 改为 edit：
```
edit 456def Do other things
edit 123abc Add fake secret
```
打开您的文本文件并移除假密钥。
提交您的更改：
```
git add .
git commit --amend
```
可选。当您删除密钥时，可能会删除提交中唯一的差异。如果发生这种情况，Git 会显示此消息：
```
No changes
You asked to amend the most recent commit, but doing so would make it empty.
```
移除空提交：
```
git reset HEAD^
```
继续变基：
```
git rebase --continue
```
从下一个提交中移除密钥并继续变基。重复此过程直到变基完成：
```
Successfully rebased and updated refs/heads/secret-tutorial
```

密钥已移除，您可以安全地将更改推送到远程仓库。

有时，人们在注意到更改包含密钥之前就推送了更改。如果项目中启用了密钥推送保护，推送会被自动阻止，并显示有问题的提交。

但是，如果密钥被成功推送到远程仓库，它就不再安全，您应该立即撤销它。即使您认为没有太多人能访问该密钥，也应该替换它。暴露的密钥会带来严重的安全风险。

为了提高您的应用程序安全性，考虑在您的项目中启用至少一种密钥检测方法。