我应该保持我的项目文件在版本控制下？
我应该保持项目文件像Eclipse的.project，.classpath，.settings，在版本控制下（如Subversion，GitHub，CVS，Mercurial等）？
你确实想在版本控制中保留任何便携式设置文件 ，
含义：
任何没有绝对path的文件。
包括：
- 。项目，
- .classpath（ 如果没有使用绝对path ，可以使用IDEvariables或用户环境variables）
- IDE设置 （这是我强烈反对“接受”的答案）。 这些设置通常包括静态代码分析规则 ，对于任何将该项目加载到他/她的工作空间的用户来说，强制执行这些规则是非常重要的。
- IDE特定的设置build议必须写在一个大的README文件中（当然还有版本）。
我的经验法则：
您必须能够将一个项目加载到工作区中，并拥有您需要的一切，以便在IDE中正确设置并在几分钟内完成。
没有额外的文件，维基页面阅读或不。
加载它，设置它，去。
.project和.classpath文件是。 但是，我们不会将IDE设置保留在版本控制中。 有一些插件在保持设置方面做得不好，我们发现一些设置不是从一台开发机器移植到另一台机器。 所以，我们有一个Wiki页面，它强调了开发者设置他们的IDE所需的步骤。
这些是我认为是生成的文件，因此我从来没有把它们放在版本控制下。 例如，当人们安装了不同的Eclipse插件时，他们可能不同于机器和开发人员。
相反，我使用一个构build工具（Maven），可以在您进行新的签出时生成这些文件的初始版本。
我在这里两个select之间撕裂。
一方面，我认为每个人都应该可以自由地使用他们最有成效的开发工具，只要所有源文件都存储在版本控制中，并且构build脚本（比如ANT或者Maven）通过指定要使用哪个JDK，依靠哪个第三方库的版本，运行样式检查（例如checkstyle）和运行unit testing等。
另一方面，我认为很多人使用相同的工具（例如Eclipse），而且通常在devise时将一些事情标准化，而不是构build时间要好得多 – 例如，Checkstyle作为Eclipse插件比作为Eclipse插件更有用一个ANT或者Maven的任务 – 最好是在一套开发工具和一套通用的插件上进行标准化。
我参与了一个项目，每个人都使用完全相同的JDK，相同版本的Maven，相同版本的Eclipse，相同的Eclipse插件集和相同的configuration文件（例如Checkstyleconfiguration文件，代码格式化程序规则等）。 所有这些都保存在源代码pipe理 – .project，.classpath和.settings文件夹中的所有内容。 在项目的最初阶段，人们不断调整依赖关系或构build过程，这使得生活变得非常简单。 当为这个项目增加新的首发时，它也是非常有帮助的。
总的来说，我认为如果没有太多的宗教战争的机会，你应该标准化开发工具和插件的基本设置，并确保在你的构build脚本中的版本兼容性（例如通过明确指定Java版本）。不要认为将JDK和Eclipse安装存储在源代码控制中是有很大好处的。 其他所有不是派生的工件 – 包括您的项目文件，configuration和插件首选项（特别是代码格式化程序和样式规则） – 应该进入源代码控制。
PS如果使用Maven，有一个说法是说.project和.classpath文件是派生的工件。 这只有当你每次构build时生成它们，并且如果你从POM生成它们之后从来没有必须手工调整它们（或者通过改变一些偏好而无意中改变它们）
不，因为我只有构build软件需要的版本控制文件。 此外，个别开发者可能有自己的项目特定设置。
不，我是一个沉重的Maven用户，使用Q for Eclipse插件创build并保持.project和.classpath更新。 对于其他的东西，比如设置插件，我通常会维护一个README或Wiki页面。
另外，我所使用的那些更喜欢其他IDE，只是使用Maven插件来生成所需的文件，以保持IDE（和他们自己）的快乐。
我认为这是所有观点 – 但是多年来的最佳实践表明，特定于给定IDE的文件不应该存储在源代码pipe理中，除非整个组织在一个IDE上标准化，并且您从来没有任何转换意图。
无论哪种方式，你绝对不希望存储用户设置 – .project可以包含真正的开发人员特定的设置。
我build议使用像Maven或Ant这样的标准化构build系统。 任何开发人员都可以在几秒钟内获得在其IDE中configuration的类path。
是的，除了.settings文件夹。 提交其他文件适合我们。 这里也有类似的问题。
虽然我普遍认同“不生成文件”的方法，但是我们遇到了问题，不得不转回来。
注意：我也对VonC的答案感兴趣，特别是关于“在几分钟之内获得Eclipse”的一点。 但这对我们并不是决定性的。
我们的上下文是Eclipse + Maven，使用m2eclipse插件。 我们有一个共同的开发环境，尽可能使用通用的目录。 但有时候有人会尝试插件，或者在configuration中改变一些小东西，或者为另一个分支导入第二个工作空间。
我们的问题在于，在Eclipse中导入项目时会完成.project的生成，但在之后的所有情况下都不会更新 。 这很可悲，也许不是永久性的，因为m2eclipse插件将会改进，但现在是真的。 所以我们最终有不同的configuration。 我们今天所拥有的是： 在一些机器上的许多项目中添加了几个本质，然后performance得非常不同 🙁
我们看到的唯一解决scheme是版本的.project文件 （为了避免风险，我们将同样的.classpath和.settings）。 这样，当一个开发人员更改她的pom时，本地文件将使用m2eclipse进行更新，所有这些文件都会一起提交，其他开发人员将看到所有更改。
注意：在我们的例子中，我们使用相对的文件名，所以我们没有问题来分享这些文件。
所以，回答你的问题，我说是的，提交这些文件。
我也喜欢：
- 富贵卖家的答案
看起来像这些项目文件可以随着时间的推移而变化，所以我把它们放在版本控制之下。
是。 一切，但build立输出。
我们使用IntelliJ IDEA，并在版本控制下保存项目（.ipr）和模块（.iml）文件的'.sample'版本。
这里比这个更大的东西是分享和重用版本，恕我直言。 但是如果你打算分享这些configuration，那么放置它们比存储库更好的地方就在它旁边。
共享和版本化项目文件的一些优点：
- 您可以查看任何标签/分支并快速开始工作
- 使新开发人员更容易首先build立开发环境并加快速度
- 这更好地坚持DRY，这总是令人非常满意。 在此之前， 所有的开发人员都必须时不时地设置这些东西，本质上是做重复的工作。 当然，每个人都有自己的小方法来避免重复自己，但是从整体上来看，还有很多重复的努力。
请注意，在IDEA中，这些文件包含如下configuration：什么是“源”和“testing源”目录; 所有关于外部依赖的地方（图书馆jar子位于何处，以及相关的资源或javadocs）; 构build选项等。这是不同的开发者之间的开发（我不同意这一点 ）。 IDEA在其他地方存储更多的个人IDE设置，以及任何插件configuration。 （我不太了解Eclipse，这可能也可能不完全不同。）
我同意这个答案 ，说：
您必须能够将一个项目加载到工作区中，并拥有您需要的一切，以便在IDE中正确设置并在几分钟内完成。 加载它，设置它，去。
我们有这样的，感谢版本化的项目文件。
