几乎任何IDE都会创建许多与正在开发的应用程序无关的文件，它们由IDE生成并保留，因此他知道如何构建应用程序，版本控制存储库等等。
这些文件是否应该保留在版本控制下以及与aplication有关的文件（源代码，应用程序的配置文件......）？
事情是：在某些IDE上，如果您创建一个新项目，然后使用IDE中嵌入的版本控制客户端/命令将其导入版本控制存储库，那么所有这些文件都将被发送到respitory。而且我不确定这是对的：在同一个项目上工作的两个不同的开发人员想要使用两个不同的IDE？
我想保留此问题不可知，以避免引用任何特定的IDE，编程语言或版本控制系统。所以这个问题并不完全相同：
答案 0 :(得分：18)
经验法则：
遵循此顺序中的规则。
[更新] 生成的代码应该会发生什么问题。根据经验，我总是把那些置于版本控制之下。像往常一样，把这条规则带上一粒盐。
我的理由：
版本化生成的代码似乎浪费时间。它产生了吗？我只需按一下按钮就可以恢复它！
真的？
如果你必须咬紧牙关，并且必定会生成一些先前版本的完全相同的版本，那将会付出多少努力？生成代码时，您不仅需要正确获取所有输入文件，还必须为代码生成器本身转回时间。你能做到吗？总是？如果您将其置于版本控制之下，那么检查生成代码的某个版本会非常简单吗？
即使你可以，你能不能确定没有错过什么？
因此，一方面，将生成的代码置于版本控制之下是有意义的，因为它使得很容易做到VCS的用途：回到过去。
此外，它还可以轻松查看差异。代码生成器也是错误的。如果我修复了一个错误并生成了150'000个文件，那么当我将它们与之前的版本进行比较时，它会有很大的帮助，以便看到a）错误消失了b）没有任何 else 意外更改。这是您应该担心的意外部分。如果你不这样做，请告诉我，我会确保你永远不会为我的公司工作永远： - ）
代码生成器的主要痛点是稳定性。当你的代码生成器每次运行时只吐出随机乱七八糟的字节时，它就不会这样做（好吧，除非你不关心质量）。代码生成器需要稳定deterministic。使用相同的输入运行它们两次，输出必须相同，直到最低位。
因此，如果您无法检入生成的代码，因为生成器的每次运行都会产生不存在的差异，那么您的代码生成器就会出现错误。修理它。必要时对代码进行排序。使用保留顺序的哈希映射。尽一切可能使输出非随机。就像你在代码中的其他地方一样。
我可能不会在版本控制下生成的代码将是文档。文档有点软目标。当我重新生成错误版本的文档时（例如，它或多或少有一些错别字），这并不重要。但对于发行版，我可能会这样做，所以我可以看到版本之间的差异。例如，可能有用，以确保发行说明完整。
我也不检查JAR文件。因为我可以完全控制整个构建并完全相信我可以在一分钟内找回任何版本的源代码，而且我知道我有一切必要的构建它而无需任何进一步的手动干预，为什么我需要可执行文件？再次，将它们放入特殊的发行版回购中可能是有意义的，但最好还是在公司的Web服务器上保留最近三年的副本进行下载。想一想：比较二进制文件很难，但并没有告诉你多少。
答案 1 :(得分：6)
我认为最好将版本控制下的任何内容放在帮助开发人员快速入门，忽略可能由IDE或构建工具自动生成的任何内容（例如，Maven的eclipse插件生成.project和.classpath - 不需要检查这些）。特别要避免经常更改的文件，只包含用户首选项或IDE之间的冲突（例如，与eclipse一样使用.project的另一个IDE）。
对于eclipse用户，我发现添加代码样式（.settings / org.eclipse.jdt.core.prefs - 启用保存时自动格式化）以获得格式一致的代码非常方便。
答案 2 :(得分：4)
可以从源+配置文件自动生成的所有内容都不应该在版本控制之下！它只会导致问题和限制（如您所说的那样 - 使用不同程序员的2个不同的项目文件）。
它不仅适用于IDE“垃圾文件”，也适用于中间文件（如python中的.pyc，c中的.o）。
答案 3 :(得分：3)
这是build automation和构建文件的来源。
例如，您仍然可以构建项目（两个开发人员显然需要相同的构建软件），但他们可以反过来使用两个不同的IDE。
对于生成的“垃圾”，我倾向于忽略大多数。我知道这是与语言无关的，但考虑Visual Studio。它生成用户文件（用户设置等）。这不应该在源代码管理下。
另一方面，项目文件（构建过程使用）肯定应该。我应该补充一点，如果你是一个团队并且已经同意IDE，那么检查IDE特定文件是很好的，只要它们是全局的而不是用户特定的和/或不需要。
其他问题很好地解释了应该和不应该检查源控制的内容，所以我不会重复它们。
答案 4 :(得分：2)
如果丢失了任何破坏性的东西，都应该受版本控制。
答案 5 :(得分：2)
在我看来，这取决于项目和环境。在公司环境中，每个人都使用相同的IDE，将IDE文件添加到存储库是有意义的。虽然这取决于IDE，但有些包括绝对的事物路径。
对于在不同环境中开发的项目，它没有意义，从长远来看会很痛苦，因为项目文件不是由所有开发人员维护的，并且更难找到“相关”的东西。
答案 6 :(得分：0)
在我看来，构建项目所需的任何东西（代码，制作文件，媒体，带有所需程序信息的数据库等）都应该在存储库中。我意识到，特别是对于媒体/数据库文件这是有争议的，但对我来说，如果你不能分支然后点击构建源控件不做它的工作。对于具有廉价分支创建/合并的分布式系统，这是双倍的。
还有别的吗？存放在不同的地方。开发人员应尽可能选择自己的工作环境。
答案 7 :(得分：0)
从我一直看到的版本控制，似乎大多数事情应该进入它 - 例如源代码等。但是，许多VCS遇到的问题是在尝试处理大型文件（通常是二进制文件）时，有时还会处理音频和图形文件等问题。因此，我个人的方法是将源代码与通用的小尺寸图形一起置于版本控制之下，并将任何二进制文件留给其他管理系统。如果它是我使用IDE的构建系统自己创建的二进制文件，则可以明确地忽略它，因为它将在每次构建时重新生成。对于依赖库，这就是依赖包管理器的用武之地。
至于IDE生成的文件（我假设这些是在构建过程中没有生成的文件，例如Visual Studio的解决方案文件） - 好吧，我认为这取决于你是否独自工作。如果您单独工作，请继续添加它们 - 它们将允许您还原解决方案中的设置或您制作的任何内容。其他类似非解决方案的文件也是如此。但是，如果你正在进行协作，那么我的推荐就是没有 - 大多数IDE生成的文件往往是用户特定的 - 也就是说它们可以在你的机器上运行，但不一定在其他机器上运行。因此，在这种情况下，您最好不要包括IDE生成的文件。
tl; dr 你应该将大多数与程序相关的东西放到版本控制中，不包括依赖项（库，图形和音频之类的东西应该由其他一些依赖管理系统来处理）。至于IDE直接生成的东西 - 嗯，这取决于你是单独工作还是与其他人一起工作。