我至少可以想到两种情况，您希望在不同的（子）目录中有多个.gitignore文件。

• 不同的目录有不同类型的文件要忽略。例如，项目顶层目录中的.gitignore忽略生成的程序，而Documentation/.gitignore忽略生成的文档。
• 只忽略给定（子）目录中的给定文件（不过，您可以在.gitignore中使用/sub/foo）。

请记住，.gitignore文件中的模式递归地应用于文件所在的（子）目录及其所有子目录，除非模式包含“/”（例如，模式name应用于给定目录及其所有子目录中名为name的任何文件，而/name仅应用于给定目录中具有此名称的文件）。

顺便说一句，如果你想在工作副本中多一个你不打算提交的目录，那么多个.gitignore文件的功能是非常有用的。只要在那个目录中放入一个1字节的.gitignore（只包含一个星号），它就永远不会出现在git status等目录中。

您可以有多个.gitignore，当然每个都在自己的目录中。
要检查哪个gitignore规则负责忽略文件，请使用git check-ignore：git check-ignore -v -- afile .
每个分支可以有不同版本的.gitignore文件：我已经看到了这种配置，以确保一个分支忽略一个文件，而另一个分支不：比如看这个问题。
如果您的repo包括几个独立的项目，最好将它们作为子模块来引用。
这将是实际的最佳实践，允许这些项目中的每一个都被独立克隆（使用它们各自的.gitignore文件），同时被全局父项目中的特定修订引用。
更多信息请参见子模块的真实性质。
请注意，从git 1.8.2（2013年3月）开始，你可以执行一个git check-ignore -v -- yourfile来查看哪个gitignore运行（来自哪个.gitignore文件）被应用于' yourfile '，并更好地理解为什么该文件被忽略。
请参见“which gitignore rule is ignoring my file?“

亲单

• 很容易找到。
• 如果我有多个gitignore，在repo的几个级别上，寻找排除规则可能会相当困难。
• 对于多个文件，您通常也会有相当多的重复。
  专业多
• 将“知识”范围限定到文件树中需要它的部分。
• 由于Git只跟踪文件，空的.gitignore是提交“空”目录的唯一方法。

(And在Git 1.8之前，排除模式my/**.example的唯一方法是在中创建模式**.foo的my/.gitignore（这个理由现在不适用，因为你可以创建/my/**/*.example）。
我更喜欢一个文件，在那里我可以找到所有的排除项.我从来没有错过per-directory .svn，我也不会错过per-directory .gitignore.
也就是说，多个gitignore是很常见的。如果你确实使用它们，至少要在使用上保持一致，使它们合理地工作。例如，你可以把它们放在根目录的下一级目录中。

在很多情况下，你想把一个目录提交到你的Git存储库中，但其中没有文件，例如logs，cache，uploads目录等。
所以我总是在这些目录中添加一个.gitignore文件，其内容如下：

# this directory is intentionally ignored
/*
!/.gitignore

有了这个.gitignore文件，Git将不会跟踪这些目录中的任何文件，但仍然允许我将.gitignore文件以及目录本身添加到repo中。

.gitignore在子文件夹中的另一个用例是在monorepos中，它可能更适合于每个repo指定哪些文件应该被忽略，而不是将它们都移动到一个单独的mega .gitignore中，这个mega .gitignore向下到达每个项目。
示例：我们有一个基于nx构建系统的monorepo。在它里面，我们有一个tools文件夹，其中包含了各种实用程序，其中一些是独立的小项目。在本例中，似乎适合这些工具中的每一个（例如，它有自己的package.json）也有一个单独的.gitignore。这更容易维护，也更容易让开发人员看到发生了什么。