签入还是不签入整个 Eclipse 项目？

To check in, or not check in, the entire Eclipse project?

提问by

I'm soon going to check in the very first commit of a new Java project. I work with Eclipse Ganymede and a bunch of plug ins are making things a little bit easier.

我很快将检查新 Java 项目的第一次提交。我使用 Eclipse Ganymede 和一堆插件使事情变得更容易一些。

Previously I've been part of projects where the entire Eclipse project was checked in. It's quite convenient to get the project settings after a check out. However this approach still was not problem free:

之前我参与过的项目都是将整个Eclipse项目都签入的，签出后获取项目设置非常方便。然而，这种方法仍然不是没有问题：

• I strongly suspect that some Eclipse configuration files would change without user interaction (from when I used Eclipse Europa), making them appear as changed (as they were changed, but not interactively) when it's time to do a commit.
• There are settings unique to each development machine as well as settings global for all developers on a project. Keeping these apart was hard.
• Sometime if the Eclipse version was different from others Eclipse would get angry and mess up the project configuration. Another case is that it change the format so it gets updated, and if commited messes up the configuration for others.

• 我强烈怀疑某些 Eclipse 配置文件会在没有用户交互的情况下更改（从我使用 Eclipse Europa 开始），使它们在进行提交时看起来已更改（因为它们已更改，但不是交互式的）。
• 每个开发机器都有独特的设置，以及项目中所有开发人员的全局设置。把这些分开是很难的。
• 有时如果 Eclipse 版本与其他版本不同，Eclipse 会生气并弄乱项目配置。另一种情况是它更改格式以便更新，并且如果提交会弄乱其他人的配置。

For this specific project I have another reason not to commit the project files:

对于这个特定的项目，我还有另一个不提交项目文件的原因：

• There might be developers who prefer NetBeans which will join the project later. However they won't join within the coming months.

• 可能有些开发人员更喜欢 NetBeans，稍后将加入该项目。但是，他们不会在未来几个月内加入。

How do you organize this? What do you check into versioning control and what do you keep outside? What do you consider best practice in this kind of situation?

你如何组织这个？你在版本控制中检查什么，你在外面保留什么？在这种情况下，您认为最佳实践是什么？

采纳答案by Brian Matthews

At a minimum you should be check-in the .projectand .classpathfiles. If anybody on your team is hard-coding an external JAR location in the .classpathyou should put them up against the wall and shoot them. I use Maven to manage my dependencies but if you are not using maven you should create user libraries for your external JARs with with a consistent naming convention.

至少您应该签入.project和.classpath文件。如果您团队中的任何人硬编码外部 JAR 位置，.classpath您应该将他们靠墙并射击。我使用 Maven 来管理我的依赖项，但是如果您不使用 Maven，您应该使用一致的命名约定为您的外部 JAR 创建用户库。

After that you need to consider things on a plug-in by plug-in basis. For example I work with Spring so I always check-in the .springBeansand likewise for CheckStyle I always check-in the .checkstyleproject.

之后，您需要逐个插件地考虑事情。例如，我使用 Spring，所以我总是签入项目.springBeans，同样对于 CheckStyle，我总是签入.checkstyle项目。

It gets a bit trickier when it comes to the configuration in the .settingsfolder but I generally check-in the following if I change the default settings for my project and want them shared with the rest of the team:

当涉及到.settings文件夹中的配置时，它会变得有点棘手，但如果我更改了项目的默认设置并希望它们与团队的其他成员共享，我通常会签入以下内容：

• .settings/org.eclipse.jdt.ui.prefs- it contains the settings for the import ordering
• .settings/org.eclipse.jdt.core.prefs- it contains the settings for the compiler version

• .settings/org.eclipse.jdt.ui.prefs- 它包含导入顺序的设置
• .settings/org.eclipse.jdt.core.prefs- 它包含编译器版本的设置

In general I haven't noticed Ganymede modifying files without me modifying the project preferences.

一般来说，我没有注意到 Ganymede 在没有修改项目首选项的情况下修改文件。

回答by André

I recommend to use mavenso that the entire life cycle is outside of any IDE. You can easily create an eclipse project with it on the command line and you can use whatever you want, if it's not eclipse. It has it's quirks but takes out a lot of bitterness when it comes to dependencies and build management.

我建议使用maven，以便整个生命周期都在任何 IDE 之外。您可以轻松地在命令行上使用它创建一个 eclipse 项目，并且您可以使用任何您想要的东西，如果它不是 eclipse。它有它的怪癖，但在依赖项和构建管理方面消除了很多痛苦。

回答by Bob Cross

In our world, we check in the entire Eclipse project and the entire parallel but separate Netbeans project. Our motivations for this were entirely focused on "when I do a checkout, I want a functional configuration immediatelyafterward." This means that we had to do some work:

在我们的世界中，我们检查整个 Eclipse 项目和整个并行但独立的 Netbeans 项目。我们这样做的动机完全集中在“当我结帐时，我希望之后立即进行功能配置”。这意味着我们必须做一些工作：

1. Create runnable configurations for each primary IDE (people like what they like). This includes main class, working directory, VM parameters, etc.
2. Create useful start up scripts for all of our relevant scenarios.
3. Create edited datasets that don't cause the checkout to take too much longer (it's a big project).

1. 为每个主要 IDE 创建可运行的配置（人们喜欢他们喜欢的东西）。这包括主类、工作目录、VM 参数等。
2. 为我们所有的相关场景创建有用的启动脚本。
3. 创建不会导致结帐花费太长时间的已编辑数据集（这是一个大项目）。

This philosophy was worth cash money (or at least labor hours which are almostmore valuable) when our new hire was able to check out the project from Subversion into Eclipse and immediately run a functional system with a (small) real data set without any fuss or bother on his part.

当我们的新员工能够将项目从 Subversion 检出到 Eclipse 并立即运行具有（小）真实数据集的功能系统时，这种理念值得现金（或至少几乎更有价值的劳动时间）或打扰他。

Follow up: this philosophy of "make the new guy's life easier" paid off again when he changed IDEs (he decided to try Netbeans after using Eclipse for quite a long time and decided to stick with it for a while). No configuration was required at all, he just opened the Netbeans project in the same directory that Eclipse had been pointing to. Elapsed switchover time: approximately 60 seconds.

跟进：这种“让新人的生活更轻松”的理念在他更换 IDE 时再次得到回报（他在使用 Eclipse 很长时间后决定尝试 Netbeans，并决定坚持一段时间）。根本不需要配置，他只是在 Eclipse 指向的同一目录中打开了 Netbeans 项目。已用切换时间：约 60 秒。

回答by hhafez

I only ever check in things are done by humans, anything else that is generated (whether automaticly or not) should be easy to regenerate again and is liable to change (as you've stated). The only exeption to this is when the generated files are hard (requires alot of human intervention ;) ) to get it right. How ever things like this should really be automated some how.

我只检查过由人类完成的事情，生成的任何其他内容（无论是否自动）都应该很容易再次重新生成并且易于更改（如您所说）。唯一的例外是生成的文件很难（需要大量人工干预;)）才能正确处理。像这样的事情应该如何真正实现自动化。

回答by hhafez

Try to port your project to a build system like maven. It has everything you need to get the same experience of the project on every machine you use.

尝试将您的项目移植到像 maven 这样的构建系统。它拥有在您使用的每台机器上获得相同项目体验所需的一切。

There are plugins for just everything. Like the eclipse plugin. You just type "mvn eclipse:eclipse" and the plugin generates your entire ready to work eclipse project.

有适用于一切的插件。就像eclipse插件一样。您只需输入“mvn eclipse:eclipse”，插件就会生成您整个准备工作的 eclipse 项目。

To give the answer to your question. Never check in files that are not being used by your project at any time in the development cycle. That means that metadata files like eclipse properties etc. should never be checked in in a SCM.

回答你的问题。在开发周期的任何时候都不要签入项目未使用的文件。这意味着永远不应该在 SCM 中签入元数据文件，例如 eclipse 属性等。

回答by Ross

I like checking in the .project, .classpath, and similar files only ifthey will be identical on any Eclipse user's machine anyway. (People using other IDEs should be able to check out and build your project regardless, but that issue is orthogonal to whether or not to check in Eclipse-only files.)

我喜欢签入 .project、.classpath 和类似文件，前提是它们无论如何在任何 Eclipse 用户的机器上都是相同的。（无论如何，使用其他 IDE 的人应该能够检出和构建您的项目，但该问题与是否检入仅限 Eclipse 的文件无关。）

If different users working on the project will want to make changes or tweaks to their .project or .classpath or other files, I recommend that you do notcheck them into source control. It will only cause headaches in the long run.

如果从事该项目的不同用户想要对其 .project 或 .classpath 或其他文件进行更改或调整，我建议您不要将它们签入源代码管理。长此以往只会让人头疼。

回答by Karsten Silz

Netbeans 6.5 has an improved Eclipse project import which is supposed to sync changes from Netbeans back to Eclipse: http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization

Netbeans 6.5 有一个改进的 Eclipse 项目导入，它应该将来自 Netbeans 的更改同步回 Eclipse：http: //wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization

回答by Cebjyre

I'd suggest having the actual project files ignored by the version control system due to the downsides you mentioned.

由于您提到的缺点，我建议版本控制系统忽略实际的项目文件。

If there is enough consistent information in the project settings that there would be benefit from having it accessible, copy it to a location that Eclipse doesn't treat as special, and you'll have it available to work with on checkout (and copy back to where Eclipse will pay attention to it). There is a decent chance that keeping the actual project files separate from the controlled ones will result in loss of synch, so I'd only suggest this if there is clear benefit from having the settings available (or you're confident that you'll be able to keep them synchronised)

如果项目设置中有足够多的一致信息可以从访问中受益，请将其复制到 Eclipse 不视为特殊的位置，并且您可以在结帐时使用它（并复制回到Eclipse会关注的地方）。将实际项目文件与受控文件分开很可能会导致失去同步，所以我只建议在设置可用有明显好处时才建议这样做（或者你有信心你会能够使它们保持同步）

回答by duffymo

I use IntelliJ, which has XML project files. I don't check those in, because they change frequently and are easy to recreate if I need to.

我使用 IntelliJ，它有 XML 项目文件。我不检查它们，因为它们经常更改，并且在需要时很容易重新创建。

I don't check in JAR files. I keep those in a separate repository, a la Maven 2.

我不签入 JAR 文件。我将它们保存在一个单独的存储库中，即 Maven 2。

I don't check in WARs or JARs or javadocs or anything else that can be generated.

我不检查 WAR 或 JAR 或 javadoc 或任何其他可以生成的东西。

I do check in SQL and scripts and Java source and XML config.

我确实检查了 SQL 和脚本以及 Java 源代码和 XML 配置。

回答by Robin

In our case, we used to check in the project files (.project and .classpath) to make it easy for all developers to create their project workspace. A common preferences file and team project set were located in source control as well, so creating your workspace was as simple as import preferences and import team project set. This worked very well, but does rely on everyone having a consistent environment, any customizations would have to be applied after the basic workspace is created.

在我们的例子中，我们过去常常签入项目文件（.project 和 .classpath），以便所有开发人员都能轻松创建他们的项目工作区。通用首选项文件和团队项目集也位于源代码管理中，因此创建工作区就像导入首选项和导入团队项目集一样简单。这很有效，但确实依赖于每个人都拥有一致的环境，任何自定义都必须在创建基本工作区后应用。

We still do this for the most part, but Maven is now used so of course dependency management is handled via Maven instead. To avoid conflicting information, the .project and .classpath were removed from source control and are now generated via maven goals before we import the team project set. This would easily allow for different environments, as you would simply need scripts to generate the IDE specific portions based on the Maven configuration.

我们仍然在大多数情况下这样做，但是现在使用 Maven，所以当然依赖管理是通过 Maven 处理的。为避免信息冲突，.project 和 .classpath 从源代码管理中删除，现在在我们导入团队项目集之前通过 maven 目标生成。这很容易允许不同的环境，因为您只需要脚本来根据 Maven 配置生成 IDE 特定部分。

PS-For ease of maintenance though, I prefer having everyone use the same environment. Anything else inevitably becomes a full time maintenance job for someone.

PS-为了便于维护，我更喜欢让每个人都使用相同的环境。其他任何事情都不可避免地成为某人的全职维护工作。