译：.gitignore 如何变成白名单

你刚刚开始了一个新项目。你运行了 cargo init、poetry init 和 go mod init。

这些命令创建了工作所需的文件，同时也在你的 .gitignore 中添加了以下几行：

markdown 复制代码

target
__pycache__
bin

一切都很好。你继续实现功能，当时机成熟时，你将项目发布到你选择的 Git 托管平台上。

人们开始对你的项目产生兴趣。其中一个人甚至决定要实现一个新功能！这简直是为你免费完成的工作！

好的。那个人使用他的代码编辑器和操作系统自带的工具来实现一个非常酷的新功能。然后他提交了合并请求。

你开始审查代码，注意到一个相当不合适的文件：.DS_Store。你问那个人这是什么，他说他也不知道。

算了。你只是从分支中删除了这个文件，并将文件名添加到仓库的 gitignore 中：

markdown 复制代码

target
__pycache__
bin
.DS_Store

很好。现在代码在 master 分支上，你的仓库只包含相关信息。

然后，有人使用基于 Web 技术创建的 IDE 提交了另一个合并请求。你查看它，发现有一个完全不相关的目录。你告诉那个人从分支中删除该目录并将其添加到 gitignore 中。gitignore 继续增长：

markdown 复制代码

target
__pycache__
bin
.DS_Store
.vscode

然后，有人使用 IntelliJ IDEA 提交了五百个 XML 文件和 .idea 目录。你重复这个过程：

markdown 复制代码

target
__pycache__
bin
.DS_Store
.vscode
.idea

岁月流逝。现在你的 gitignore 有数百行长，但人们仍然不断意外地提交测试脚本、foo、a、qux、data.tar.gz、start.sh、bin-release、cat、asd、fgsgskfh。

该死的。你感觉像一个神话中的神，因为欺骗死亡和欺骗冥界而受到惩罚。

你如何逃脱这个忽略偷偷溜进来的文件的无限循环？也许通过教育每一个合并请求的作者？不，这绝对行不通，应该有一种方法可以通过工具自动处理这个问题，而不是主观的人际沟通。

幸运的是，你意识到可以通过忽略所有内容并手动取消忽略所需文件，将文件黑名单（gitignore）转换为白名单。 你将 gitignore 更改为：

yaml 复制代码

*

!.gitignore

# 白名单 `src` 目录及其子目录，无论位置如何
!src/
!src/**/
!src/**/*.rs
!Cargo.{toml,lock}

# 白名单根目录的 `pysrc` 目录
!/pysrc/
!/pysrc/*.py
!pyproject.toml
!poetry.lock

!/cmd/
!/cmd/*.go
!main.go
!go.{mod,sum}

!/docs/
!/docs/*.md

现在，没有人可以意外提交不需要的文件，因为 git 会自动忽略它们，只允许明确列入白名单的文件。 这也是面向未来的，直到某个 IDE 决定使用 src/ide.rs 文件作为存储项目特定配置的便捷方式。希望那个未来永远不会到来。

你感到如释重负。