为什么在 Git 中忽略特定于 IDE 的项目文件？

Question

我看到在 Github 上发布的许多项目都有一个 .gitignore 文件，其中明确排除了与 IDE 相关的控制文件。这些控制文件广泛用于定义项目及其依赖项。这些可以是 .NET 的 .sln 或 Eclipse 的 .project。

考虑到我同意实现 IDE 中立性（不要将开发人员绑定到特定 IDE）是一个很好的原则，我想问一下为什么这种做法被广泛应用或被认为是一种好的做法。

相反，这些控制文件通常在多个配置中指示项目依赖项、配置或编译变量（例如 .csproj 文件就是这种情况）。

我见过大量忽略 Eclipse 文件的开源项目，但是到目前为止，我无法在没有项目文件的情况下建立开发环境（即使我从现有代码创建项目，或者创建一个新项目和导入代码，我总是得到大量的编译错误）。

如果项目文件存在于存储库中，那么通过“下载代码、导入项目并编译源代码”来设置开发环境将非常简单，但它显然会将开发人员绑定到特定的 IDE（这就是不好笑）。

标准化或迁移项目文件不在问题范围内。

那么，从外部贡献者的角度来看，如何为他从 Github 下载源代码的项目构建一个工作和编译项目环境？ （克隆所有子模块后，如果需要）

随便挑一个我想导入Eclipse的示例项目，分析一下，稍作修改，here就是。

Answer 1

请注意，csproj 文件不是特定于 IDE，而是构成.NET 项目的基本项目结构和构建步骤。即使您切换到像 SharpDevelop 这样的完全不同的 IDE，您仍然需要它们来运行项目。所以，一般来说，这些不应该出现在.gitignore 文件中。仅应排除用户或 IDE 特定的内容。

Answer 2

在 Java 世界中有很多构建系统（Maven、Gradle、SBT 等）。为您的 IDE 生成项目文件是小菜一碟。这使得没有必要将它们签入版本控制，因为它们可以被视为构建工件。

此外，在一个混合团队中，不同的人使用不同的 IDE，当有人更新 Eclipse 项目文件时，使用 IntelliJ 的人突然也需要更新他的项目文件，因为他现在遇到了编译问题。而使用生成这些文件的构建系统可确保它们始终是最新的。以 Maven 为例，当您将 M2Eclipse 插件添加到 Eclipse 或使用 IntelliJ 时，甚至无需用户交互即可完成。

所以我一直提倡将项目文件添加到.gitignore...

Answer 3

因为有些人不使用这些 IDE，而其他人则对其配置进行了一些调整。更不用说这些 IDE 特定文件在每个编译步骤之后更改太快且太无用。

最好有 Makefile、Ant 文件或其他等效的构建系统，而不是依赖 IDE 文件。

当然，有些错误是由于缺少库引起的。您必须自己安装它们，是否在 repo 中有 IDE 文件并不重要。

我通常做的事情：克隆项目，如果不存在则创建构建脚本，将其添加到.git/info/exclude，因为它是特定于机器的。