eclipse 我应该将我的项目文件置于版本控制之下吗？

Should I keep my project files under version control?

提问by cretzel

Should I keep project filesm like Eclipse's .project, .classpath, .settings, under version control (e.g. Subversion, GitHub, CVS, Mercurial, etc)?

我是否应该像 Eclipse 的 .project、.classpath、.settings 一样将项目文件保留在版本控制之下（例如 Subversion、GitHub、CVS、Mercurial 等）？

回答by VonC

You do want to keep in version control any portable setting files,
meaning:
Any file which has no absolute path in it.
That includes:

您确实希望保留任何可移植设置文件的版本控制，
这意味着：
其中没有绝对路径的任何文件。
包括了：

• .project,
• .classpath (if no absolute path used, which is possible with the use of IDE variables, or user environment variables)
• IDE settings(which is where i disagree strongly with the 'accepted' answer). Those settings often includes static code analysis ruleswhich are vitally important to enforce consistently for any user loading this project into his/her workspace.
• IDE specific settings recommandations must be written in a big README file (and versionned as well of course).

• 。项目，
• .classpath（如果没有使用绝对路径，可以使用 IDE 变量或用户环境变量）
• IDE 设置（这是我强烈不同意“已接受”答案的地方）。这些设置通常包括静态代码分析规则，对于将此项目加载到他/她的工作区的任何用户一致地强制执行这些规则非常重要。
• IDE 特定的设置建议必须写在一个大的 README 文件中（当然也要进行版本控制）。

Rule of thumb for me:
You must be able to load a project into a workspace and have in it everything you need to properly set it up in your IDE and get going in minutes.
No additional documentation, wiki pages to read or what not.
Load it up, set it up, go.

我的经验法则：
您必须能够将项目加载到工作区中，并在其中包含在 IDE 中正确设置并在几分钟内开始工作所需的一切。
没有额外的文档，维基页面阅读或什么不。
加载它，设置它，去。

回答by Kevin

.project and .classpath files yes. We do not however keep our IDE settings in version control. There are some plugins that do not do a good job of persisting settings and we found that some settings were not very portable from one dev machine to the next. So, we instead have a Wiki page that highlights the steps required for a developer to setup their IDE.

.project 和 .classpath 文件是的。但是，我们不会将 IDE 设置保留在版本控制中。有一些插件不能很好地保持设置，我们发现一些设置从一台开发机器到另一台开发机器不是很容易移植。因此，我们有一个 Wiki 页面，其中突出显示了开发人员设置其 IDE 所需的步骤。

回答by Chris Vest

These are what I consider to be generated files, and as such I never place them under version control. They can be different from machine to machine and developer to developer, for instance when people have different Eclipse plugins installed.

这些是我认为是生成的文件，因此我从不将它们置于版本控制之下。它们可能因机器和开发人员而异，例如当人们安装了不同的 Eclipse 插件时。

Instead, I use a build tool (Maven) that can generate initial versions of these files when you make a new checkout.

相反，我使用了一个构建工具 (Maven)，它可以在您进行新的结账时生成这些文件的初始版本。

回答by Vihung

I am torn between two options here.

我在这两种选择之间左右为难。

On one hand, I think that everyone should be free to use the set of developemnt tools they are most productive with, as long as all source artifacts are stored in version control, and the build script (say ANT or Maven) ensures standards compliance by specifying exactly which JDK to use, which versions of which third party libraries to depend upon, running style checks (e.g. checkstyle) and running unit tests etc.

一方面，我认为每个人都应该可以自由地使用他们最高效的开发工具集，只要所有源工件都存储在版本控制中，并且构建脚本（比如 ANT 或 Maven）通过以下方式确保符合标准准确指定要使用的 JDK、要依赖的第三方库的哪些版本、运行样式检查（例如 checkstyle）和运行单元测试等。

On the other hand, I think so many people use the same tools (e.g. Eclipse) and often it is much better to have some things standardised at design time instead of build time - for example Checkstyle is far more useful as an Eclipse plugin than as an ANT or Maven task - that it is better to standardise on the set of development tools and a common set of plugins.

另一方面，我认为很多人使用相同的工具（例如 Eclipse）并且通常在设计时而不是构建时标准化一些东西要好得多 - 例如 Checkstyle 作为 Eclipse 插件比作为 Eclipse 插件有用得多ANT 或 Maven 任务 - 最好对一组开发工具和一组通用插件进行标准化。

I worked on a project where everyone used exactly the same JDK, same version of Maven, the same version of Eclipse, the same set of Eclipse plugins and the same configuration files (e.g. Checkstyle profiles, code formatter rules etc.). All of these were kept in source control - .project, .classpath and everything in the .settings folder. It made life really easy during the initial phases of the project when people were continually tweaking the dependencies or the build process. It also helped immensely when adding new starters to the project.

我在一个项目中工作，每个人都使用完全相同的 JDK、相同版本的 Maven、相同版本的 Eclipse、相同的 Eclipse 插件集和相同的配置文件（例如 Checkstyle 配置文件、代码格式化规则等）。所有这些都保存在源代码控制中 - .project、.classpath 和 .settings 文件夹中的所有内容。在项目的初始阶段，当人们不断调整依赖项或构建过程时，它使生活变得非常轻松。在向项目添加新的启动器时，它也有很大帮助。

On balance, I think that if there are not too many chances of a religious war, you should standardise on the basic set of develop tools and plugins and ensure version compliance in your build scripts (for example by explicitly specifying the Java version).I don't think that there is much benefit to storing the JDK and the Eclipse installation in source control. Everything else that is not a derived artifact - including your project files, configuration and plugin preferences (particularly code formatter and style rules) - should go into source control.

总的来说，我认为如果发生宗教War的可能性不大，您应该对基本的开发工具和插件集进行标准化，并确保构建脚本中的版本合规性（例如通过明确指定 Java 版本）。不要认为在源代码管理中存储 JDK 和 Eclipse 安装有多大好处。不是衍生工件的所有其他东西——包括你的项目文件、配置和插件首选项（特别是代码格式化程序和样式规则）——都应该进入源代码控制。

P.S. If you use Maven, there is an argument for saying that the .project and .classpath files are derived artifacts. This is only true if you generate them every time you do a build, and if you have never had to tweak them by hand (or inadvertently changed them by changing some preferences) after generating them from the POM

PS 如果您使用 Maven，则有一个说法是 .project 和 .classpath 文件是派生的工件。只有在每次构建时都生成它们，并且在从 POM 生成它们之后，您从未需要手动调整它们（或通过更改某些首选项无意中更改它们）时，这才是正确的

回答by John Topley

No, because I only version control files that are needed to build the software. Besides, individual developers may have their own project-specific settings.

不，因为我只有构建软件所需的版本控制文件。此外，个别开发人员可能有自己的项目特定设置。

回答by Kevin Day

This is all opinion, I suppose - but best practices over the years indicate that files specific to a given IDE shouldn't be stored in source control, unless your entire organization is standardized on one IDE and you never have any intent on switching.

我想这就是全部意见 - 但多年来的最佳实践表明，特定于给定 IDE 的文件不应该存储在源代码管理中，除非您的整个组织在一个 IDE 上进行了标准化，并且您从未打算进行切换。

Either way, you definitely don't want user settings stored - and .project can contain settings that are really developer specific.

无论哪种方式，您绝对不希望存储用户设置 - 并且 .project 可以包含真正特定于开发人员的设置。

I recommend using something like Maven or Ant as a standardized build system. Any developer can get a classpath configured in their IDE in a few seconds.

我建议使用 Maven 或 Ant 之类的东西作为标准化的构建系统。任何开发人员都可以在几秒钟内获得在他们的 IDE 中配置的类路径。

回答by Andreas Holstenson

No, I'm a heavy Mavenuser and use the Q for Eclipseplugin that creates and keeps .project and .classpath updated. For other things such as settings for plugins I usually mantain a README or Wiki-page about that.

不，我是Maven的重度用户，并使用Q for Eclipse插件创建并保持 .project 和 .classpath 更新。对于其他事情，比如插件设置，我通常会维护一个关于它的 README 或 Wiki 页面。

Also those I've worked with that prefer other IDEs just use the Maven-plugins to generate the files needed to keep their IDE (and themselves) happy.

还有那些与我合作过的更喜欢其他 IDE 的人只使用 Maven 插件来生成保持他们的 IDE（和他们自己）满意所需的文件。

回答by Jay R.

Yes, except for the .settings folder. Committing the other files works well for us. There is a similar question here.

是的，除了 .settings 文件夹。提交其他文件对我们来说效果很好。还有一个类似的问题在这里。

回答by KLE

Although I generally agree on the "do not version generated files" approach, we have problems with it and have to switch back.

虽然我普遍同意“不要版本生成的文件”的方法，但我们遇到了问题，不得不切换回来。

Note: I am also interested in VonC's answer, particularly about the "get Eclipse up within minutes" point. But it is not decisive to us.

注意：我也对VonC 的回答感兴趣，特别是关于“在几分钟内启动 Eclipse”这一点。但这对我们来说不是决定性的。

Our context is Eclipse+Maven, using m2eclipse plug-in. We have a common development environment, with common directories as much as possible. But it happens sometimes that someone would try a plug-in, or change little things in the configuration, or import a second workspace for a different branch...

我们的上下文是Eclipse+Maven，使用m2eclipse插件。我们有一个共同的开发环境，尽可能的有共同的目录。但有时会发生有人会尝试插件，或更改配置中的小东西，或为不同的分支导入第二个工作区......

Our problem is that the generation of .project is done when importing a project in Eclipse, but is not updated in all cases later on. It's sad, and probably not permanent as the m2eclipse plug-in will improve, but it's true right now. So we end up having different configurations. What we had today was that: several natures were added to many projects on some machine, which then behaved much differently:-(

我们的问题是 .project 的生成是在 Eclipse 中导入项目时完成的，但在以后的所有情况下都没有更新。这很可悲，而且可能不是永久性的，因为 m2eclipse 插件会改进，但现在确实如此。所以我们最终有不同的配置。我们今天所拥有的是：在某些机器上的许多项目中添加了几种性质，然后它们的行为大不相同:-(

The only solution we see is to version the .project file(to avoid risks, we'll do the same for .classpath and .settings). That way, when one developer changes her pom, the local files get updated using m2eclipse, all of them get committed together, and other developers will see all changes.

我们看到的唯一解决方案是版本 .project 文件（为了避免风险，我们将对 .classpath 和 .settings 做同样的事情）。这样，当一个开发人员更改她的 pom 时，本地文件会使用 m2eclipse 更新，所有这些文件一起提交，其他开发人员将看到所有更改。

Note : in our case, we use relative file names, so we have no problem to share those files.

注意：在我们的例子中，我们使用相对文件名，所以我们共享这些文件没有问题。

So, to answer your question, I say yes, commit those files.

所以，为了回答你的问题，我说是的，提交这些文件。

---

---

I also liked:

我也喜欢：

• Rich Seller's answer

• 富卖家的回答

回答by dbrien

It seems like these project files can change over time as you work on a project so yes, I place them under version control.

当您处理项目时，这些项目文件似乎会随着时间的推移而更改，所以是的，我将它们置于版本控制之下。