这可以归结为意见： 我想知道项目文件（IDE生成和使用的文件而不是编译器）是否应该包含在源代码管理存储库中。是否有某些情况应该和不应该？
编辑：我应该提一下我之所以要问的原因是因为我正在查看使用Visual Studio时git会忽略的一些文件列表 - 其中一些列表包含项目文件而另一些则没有。
答案 0 :(得分：14)
一个简单的问题：您是否需要来构建代码？如果没有，那么它们就是人工制品，而不是源文件，并且没有位于源控制系统中。
诸如编辑器颜色首选项或键绑定之类的东西不是构建系统的一部分。编译器标志等等。
我们存储构建所需的所有，直到操作系统安装磁盘和所需的配置。 Anal-retentive甚至没有接近描述我们:-)如果我们可以存储硬件，我们会（我们必须处理存储详细说明硬件规格的文档）。
我们偶尔也会使用存储在存储库中的内容来测试我们从头开始构建开发环境的能力。失败意味着我们;在灾难恢复方面没有涉及。
答案 1 :(得分：6)
将项目文件包含在存储库中更容易和合乎逻辑，因为它们是项目本身的一部分。项目更改，项目文件也是。
每当您必须将整个项目恢复到以前的状态或邀请其他人签入以处理项目时，使用每个文件会更方便。不只是源代码。
顺便说一下，大多数IDE都包含了存储库中的项目文件，排除它们会非常痛苦，并且仍然可以从IDE本身检入和签出。
答案 2 :(得分：2)
如果您有特殊的构建脚本，IDE可能需要构建您的项目。另外，如果你做一个新的结账，你真的想经历每次设置所有项目构建参数等的麻烦吗？
答案 3 :(得分：2)
如果您与其他开发人员合作并且他们不使用其他IDE或其他版本的IDE，则IDE项目文件将不同。我认为IDE项目文件不应该置于源代码管理之下。
答案 4 :(得分：2)
通常，项目文件应该受版本控制，但应忽略用户首选项文件。
例如，在使用Visual Studio时，“。proj”和“.sln”文件应受版本控制，但应忽略“.suo”。
答案 5 :(得分：1)
答案 6 :(得分：1)
对于.NET，我认为项目文件应该包含在源代码管理存储库中。在C＃和VB中，它是项目文件，用于定义哪些源文件是程序集的一部分。如果将源文件添加到项目中并且没有源代码控制下的项目文件，则团队中的所有其他开发人员必须手动将文件添加到THEIR项目。
在Java中，源代码树中的所有文件都自动包含在构建中（如果我没记错的话），因此在Java中对项目文件的需求可能不同。
答案 7 :(得分：0)
我们使用Eclipse，我们检查的唯一文件是.classpath文件，这样任何类路径更改都不会破坏更新的构建。
答案 8 :(得分：0)
包含构建指令的项目文件肯定应该受源代码控制。 您不希望在每次新结账时设置正确的编译器和链接器标志和路径，对吗？
但是，并非所有项目文件都是相同的，有些只是“帮助文件”存储标签或最近打开的文件等等。那些不能被版本化，因为它们可能因每个开发者而异。
版本化项目文件有两个不同的好处：
答案 9 :(得分：0)
我正在为一家开发和选择IDE的公司工作。开始时，我们删除了远离用户目录的所有项目文件。大多数人都对这种方式很满意。但有时候有人问是否有可能，因为他们也希望从家庭系统工作，并使用版本控制作为快速文件传输工具同步工作和家庭。
我可以告诉你，实施这个要求并不容易！
设置必须清楚地分开，例如，如果您的IDE将窗口坐标存储在设置文件中，并且您在工作时使用双显示器系统，而在家中使用小型笔记本则非常糟糕。 IDE还必须能够提供在每个文件路径中处理环境变量扩展的方法。最后当然它必须能够为设置文件提供单独的名称或将它们存储在不同的地方 - 否则你很快就会发现项目中有3个不同的开发人员对字体，颜色，默认值等有5种不同的看法，因为如果这样的话做得不好他们都会使用相同的设置。
另一方面，许多IDE都需要存储大量数据，其中一些甚至在项目设置中存储GUI配置的单元测试用例。在这种情况下，重用文件并将其检入版本控制系统当然很有用。
所以你看它依赖。尝试一下，看看它如何适用于您的环境。
答案 10 :(得分：0)
是的，我认为IDE项目文件应该提交给Subversion，因为其中大部分都包含有关如何构建/编译项目的配置。
如果存在仅用于存储编码约定之外的开发者偏好的配置，则必须取出（即排除）这些配置，以免引起混淆。
答案 11 :(得分：0)
不确定是否提到过，但Visual Studio（至少是C ++版本）会生成两个项目文件：