IDE 项目文件是否应该置于源代码管理之下？
这可以归结为意见： 我想知道项目文件（由 IDE 而不是编译器生成和使用的文件）是否应该包含在源代码控制存储库中。在某些情况下他们应该和不应该吗？
编辑：我应该提到，我问的原因是因为我正在查看使用 Visual Studio 时 git 忽略的一些文件列表 - 其中一些列表包含项目文件，有些则没有。
This may boil down to opinion:
I am wondering if project files (the files generated and used by the IDE and not the compiler) should be included in source control repositories. Are there certain cases where they should and shouldn't?
Edit: I should mention that the reason I am asking is because I'm looking at some lists of files to be ignored by git when using Visual Studio -- some of these lists have the project files and some don't.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
一个简单的问题：您需要它们来构建您的代码吗？如果不是，那么它们就是人工制品，而不是源文件，并且在源代码控制系统中没有位置。
像编辑器颜色首选项或键绑定之类的东西不是构建系统的一部分。编译器标志等等。
我们存储构建所需的一切，包括操作系统安装磁盘和所需的配置。肛门保留甚至不足以描述我们:-) 如果我们可以存储硬件，我们会的（我们必须存储一份详细说明硬件规格的文档）。
我们偶尔也会测试仅使用存储库中存储的内容从头开始构建开发环境的能力。那里的失败意味着我们不享受灾难恢复。
One simple question: Do you need them to build your code? If not, then they're artefacts, not source files, and have no place being in the source control system.
Things like your editor color preferences or keybindings are not part of the build system. Compiler flags and so on are.
We store everything that's needed to build, down to the operating system install disks and required configuration. Anal-retentive doesn't even come close to describing us :-) If we could store the hardware, we would (we have to make do with storing a document detailing the hardware specs).
We also occasionally test our capability to build the development environment from scratch using only what's stored in the repositories. Failure there means that we;re not covered in terms of disaster recovery.
对我来说，将项目文件包含在存储库中更容易且符合逻辑，因为它们是项目本身的一部分。项目发生变化，项目文件也发生变化。
每当您需要将整个项目恢复到之前的状态或邀请某人签入该项目时，拥有每个文件会方便得多。不仅仅是源代码。
顺便说一句，大多数 IDE 都将项目文件包含在存储库中，排除它们并仍然保留从 IDE 本身签入和签出的可能性会非常痛苦。
It is easier and logical to me to include project files in the repositories, since they are part of the project itself. Project changes, project files too.
Whenever you have to revert the whole project to the previous state or invite someone to check in to work on the project, it is much more convenient to have every file. Not just source code.
By the way, most IDEs include the project files in repositories, and it will be too painful to exclude them and still keep the possibility to check in and check out from IDE itself.
如果您与其他开发人员合作，并且他们不使用其他 IDE 或其他版本的 IDE，则 IDE 项目文件将不相同。我认为 IDE 项目文件不应该置于源代码管理之下。
If you work with other developers and they don't use other IDE, or other versions of IDE, the IDE project files won't be the same. I think IDE project files should not be put under source control.
如果您有特殊的构建脚本，IDE 可能需要它来构建您的项目。另外，如果您进行全新的检查，您是否真的想每次都经历设置所有项目构建参数等的麻烦？
If you have special build scripts it may be required for the IDE to build your project. Plus if you do a fresh checkout do you really want to go through the hassle of setting up all the project build parameters etc each time?
一般来说，项目文件应该受到版本控制，但用户首选项文件应该被忽略。
例如，当使用 Visual Studio 时，“.proj”和“.sln”文件应受版本控制，但“.suo”应被忽略。
Generally, project files should be version controlled but user preference files should be ignored.
For example when using Visual Studio, '.proj' and '.sln' files should be version controlled, but '.suo' should be ignored.
对于.NET，我认为项目文件应该包含在源代码控制存储库中。在 C# 和 VB 中，项目文件定义了哪些源文件属于程序集的一部分。如果您将源文件添加到项目中，但该项目文件没有受源代码控制，则团队中的所有其他开发人员都必须手动将该文件添加到他们的项目中。
在 Java 中，源树中的所有文件都会自动包含在构建中（如果我没记错的话），因此 Java 中对项目文件的需求可能不同。
For .NET, I think the project files should be included in the source control repositories. In C# and VB it's the project file that defines which source files that are part of the assembly. If you add a source file to the project and don't have the project file under source control, all other developers in the team must manually add the file to THEIR project.
In Java all files in a source tree is automatically included in the build (if I remember it correctly) so the need for a project file may not be the same in Java.
我们使用 Eclipse，我们签入的唯一文件是 .classpath 文件，这样任何类路径更改都不会破坏更新时的构建。
We use Eclipse and the only file we checkin is the .classpath file so that any classpath changes don't break the build on an update.
我在一家开发和销售 IDE 的公司工作。一开始，我们从用户目录中删除了所有项目文件。大多数人都对这种方式感到满意。但时不时有人问这是否可能，因为他们也想在家庭系统上工作，并使用版本控制作为同步工作和家庭位置的快速文件传输实用程序。
我可以告诉你，实现这个要求并不容易！
设置必须明确分开，例如，如果您的 IDE 将窗口坐标存储在设置文件中，而您在工作中使用双显示器系统，而在家里使用小笔记本电脑，那就非常糟糕了。 IDE 还必须能够提供一种方法来处理每个文件路径中的环境变量扩展。最后，当然它必须能够为设置文件提供单独的名称或将它们存储在不同的位置 - 否则您很快就会发现项目中的 3 个不同的开发人员对字体、颜色、默认值等有 5 个不同的意见，因为如果这做得不好他们都会使用相同的设置。
另一方面，许多 IDE 需要存储大量数据，其中一些甚至在项目设置中存储 GUI 配置的单元测试用例。在这种情况下，重用这些文件并将其签入版本控制系统当然很有用。
所以你看这取决于。尝试一下，看看它如何适合您的环境。
I'm working for a company who develops and selles an IDE. At the beginning we removed all project files away from the user directories. Most of the people were happy with this way. But from time to time someone asked if it is possible because they wanted to work also from there home system and use the version control as a fast file transfer utility synchronizing work and home place.
I can tell you that implementing this request was not easy!
The settings has to be clearly separated, for example if your IDE stores window coordinates in the settings file and you work on dual monitor system at work and a small notebook at home it is really bad. The IDE must also be able to provide a way to handle environment variable expansion in every file path. And finally of course it must be able to give setting files individual names or store them in different places - otherwise you will soon find out that 3 different developers on the project have 5 different opinions about fonts, colors, default values etc. because if this is not well done they will all use the same settings.
On the other hand many IDEs have huge amounts of data to store, some of them even store GUI configured unit test cases in project settings. In this case it is of course useful to reuse the files and check it into the version control system.
So you see it depends. Try it out and see how it works for your environment.
包含构建指令的项目文件绝对应该处于源代码控制之下。
您不想在每次新签出时设置正确的编译器和链接器标志和路径，对吗？
然而，并非所有项目文件都是一样创建的，有些只是存储标签或最近打开的文件等的“帮助文件”。这些不得进行版本控制，因为它们可能因每个开发人员而异。
版本控制项目文件有两个不同的好处：
Project files that include build instruction should definitely be under source control.
You don't want to set correct compiler and linker flags and path on each fresh checkout, do you ?
However, not all project files are created equal, and some are just "helping files" that store tags or recently open files and so on. Those must not to be versionned, since they can vary for each developper.
There are two different benefit from versionning project files :
是的，我相信 IDE 项目文件应该提交给 Subversion，因为其中大部分包含有关如何构建/编译项目的配置。
如果存在仅用于存储编码约定之外的开发人员首选项的配置，则必须将这些配置删除（即排除），以免造成混乱。
Yes, I believe IDE project files should be committed to Subversion as most of this includes configurations on how to build/compile the project.
If there configurations that are solely used to store developer preferences outside of the coding convention then those must be taken out (i.e. excluded) so as not to introduce confusion.
不确定是否被提及，但 Visual Studio（至少是 C++ 版本）会生成两个项目文件：
Not sure if it was mentioned, but Visual Studio (at least the C++ version) produces two project files: