我应该提交由 Eclipse 更改的文件吗？
我以Eclipse项目的形式继承了一个Java项目。更改 Tomcat 配置（从 v6 到 v7）后，Subclipse 提示我提交以下文件：
.classpathorg.eclipse.core.prefsorg.eclipse .common.project.facet.core.refsorg.eclipse.common.project.facet.core.xml
提交它们会帮助我的团队成员还是会扰乱他们的工作空间？
对此的最佳实践方法是什么？
I inherited a Java project in the form of an Eclipse project. After changing the Tomcat configuration (from v6 to v7), Subclipse prompted me to commit the following files:
.classpathorg.eclipse.core.prefsorg.eclipse.common.project.facet.core.refsorg.eclipse.common.project.facet.core.xml
Will commiting them help my team members or will it mess with their workspace?
What is the best practice approach to this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
作为一般规则，您应该避免提交包含用户首选项以及 Eclipse 和/或您的插件可以重新生成的项目详细信息的文件。
但在某些情况下，事情有点模糊。例如，.classpath 文件可以是 Eclipse 构建路径的主要来源；例如，如果您的项目树中有 JAR 文件而不是使用 Maven。 （使用 Maven，m2eclipse 插件根据 POM 文件中的依赖信息生成 .classpath 文件，因此不应签入该文件。）
此外，一些方面的内容是边界性的。例如，在包含 JSP 和 Javascript 的项目中，我发现更改方面属性以禁用损坏的验证器至关重要。有一个很好的理由将这些更改视为项目的一部分而不是个人偏好。
将小组/项目偏好与个人偏好分离是 (IMO) Eclipse 严重缺陷的一个领域。
As a general rule, you should avoid committing files that contain user preferences, and project details that that Eclipse and/or your plugins can regenerate.
But in some cases things are a bit murky. For instance, the .classpath file can be the primary source of the Eclipse build path; e.g. if you have JAR files in your project tree rather than using Maven. (With Maven, the m2eclipse plugin generates the .classpath file from the dependency information in the POM file, and hence the file should not be checked in.)
Also, some of the facet stuff is borderline. For instance, in projects with JSPs and Javascripts, I have found it essential to change the facet properties to disable broken validators. And there's a good case for treating those changes as part of the project rather than as personal preferences.
Separation of group / project preferences from personal preferences is one area where (IMO) Eclipse is seriously deficient.
最好不要提交这些文件，因为不同工作站上的路径/设置可能不同。
您可能想使用一些构建工具来克服这个问题。 （例如 Maven）
就好像任何团队成员不使用 eclipse（使用其他 ide）一样，这些文件对他们来说没有任何意义。
如果每个人都提交不同的 IDE 设置，想象一下这会造成什么样的混乱。
编辑：
更多解释；
我曾在团队中工作过，人们使用 NetBeans、Eclipse、IDEA...很长一段时间，对他们来说改变 IDE 并不是一个真正的选择。它只会影响那个人的生产力。
当人们习惯了他们的 IDE 时，他们会学习快捷方式，他们知道在哪里寻找一些函数（重构/生成 getter setter/实现覆盖所需的方法......），因此如果你强迫他们使用其他 IDE，它只会让事情变得更糟对他们来说更困难，对整个过程来说更慢。恕我直言，根据我的经验，拥有灵活的代码库总是好的。我是一个 Eclipse 爱好者，可能不想使用任何其他 IDE，因为我知道很多快捷方式，这使得事情对我来说变得更快/更容易，而且这些快捷方式在不同的 IDE 上是不同的。
所有 IDE 文件都可以由 IDE 本身自动重新生成，只需单击几下即可。
而我当前的项目有3个开发人员，每个开发人员都使用不同的IDE eclipse(me)、NetBeans、IDEA，没有任何问题。我不想看到 IDEA 或 NetBeans 配置文件，当我从存储库查看源代码时，这些文件对 Eclipse 没有任何意义。对他们来说也是如此。
It is better not to commit those files as paths/settings may differ on different workstations.
You may wanna use some build tool to overcome this. (eg. Maven)
As if any of the team members are not using eclipse (using some other ide) , those files have no meaning for them.
If everyone commits different IDE settings, imagine what kind of mess it can cause.
EDIT:
More explanation;
I have worked in teams that people used NetBeans, Eclipse, IDEA...for a really long time and it is not really an option for them to change the IDE. It will only affect the productivity of that person.
When people get used to their IDEs they learn shorcuts, they know where to look for some functions (refactor/generate getter setter/implement override required methods....) so if you force them to use some other IDE it will just make things harder for them and slower for the overall process. IMHO and from my experience having a flexible codebase is always good. I am an eclipse guy and probably would not want to work with any other IDE as I know lots of shorcuts which makes thing real quicker/easier for me and those shorcuts are different on different IDEs.
All IDE files can be regenerated automatical by the IDE itself probably in just a couple of clicks.
And my current project has 3 developers, each using different IDEs eclipse(me), NetBeans, IDEA without any problems. I dont want to see IDEA or NetBeans config files which makes no sense for eclipse when I check out the source from repo. Likewise for them as well.
是的，但请确保工作区中的路径是相对路径而不是绝对路径。将这些文件放在工作区中可以让您的团队成员在与您相同的环境中工作。它还使设置新的开发环境变得更加容易：您只需将其从源代码控制中签出，然后在 Eclipse 中使用“导入...”即可。将现有项目放入工作空间'
正如 @adamdunne 提到的，这些文件可以包含环境特定的路径。但是，如果您通过使用变量并且不导入外部 jar（即仅包含工作区中项目的 jar）来小心确保路径在工作区中是相对的，那么您应该没问题。在我的工作区中，我们签入这些文件，并且设置开发时遇到的问题少了很多。以来的环境。
Yes, though do make sure that paths are relative in the workspace rather than absolute paths. Having these files in the workspace allows members of your team to work in the same environment as you are. It also makes setting up a new development environment much easier: you just check it out of source control and in Eclipse use 'Import... > Existing Projects into Workspace'
As @adamdunne mentioned, these files can contain environment specific paths. However it if you are careful to make sure paths are relative within your workspace, by using variables and by not importing external jars, i.e., by only including jars from projects in the workspace, then you should be okay. In my workspace we check in those files and have had a lot less issues setting up dev. environments since.
我在一个项目中工作，我们提交 .classpath 文件，因为所有开发人员都使用相同的文件非常有用:) 如果您仅在工作空间内使用依赖项，则该文件使用相对路径，因此在所有计算机上都应该相同。即使这个文件可能不需要构建（例如使用 ant），同步它也非常方便。
相比之下，org.eclipse.core.prefs 存储（据我所知）特定于项目的开发人员的个人偏好，我不会检查这些偏好。
对于这些方面，我还没有在实际项目中工作过，所以我不能说。但总的来说，我认为这取决于文件中的信息以及你的工作方式。
如果您不确定，请尝试一下。如果您整天在这些文件中遇到冲突，则表明您可能没有采取完美的方式。
I work in a project where we commit the .classpath file since it is very useful that all developers use the same :) If you only use dependencies inside your workspace, this file uses relative paths and thus should be same on all machines. Even if this file might not be necessary to build (with ant e.g.) it´s very convenient to synchronize it.
In contrast the org.eclipse.core.prefs stores (afaik) project-specific, but personal preferences of developers which I would not check in.
With the facets I didn´t work yet in a real project, so I can´t tell. But in general, I think it depends on the information in the file and on the way you work.
If you are unsure, just try it. If you get conflicts in these files all day this is a hint you may not be on the perfect way.
这些文件对于在开发人员之间共享配置非常有用。另一种选择是使用 Maven（这对于已建立的项目来说是一项艰巨的任务），或者使用不断过时的分步说明，而新开发人员甚至要花半天时间才能构建项目。
但是，您应该注意确保这些配置是可移植的，即不包含本地路径。这可以通过使用工作空间内的相对路径、Eclipse 路径变量和用户库来完成。
These files can be very useful to share configurations between developers. The alternative is to either use Maven (which is a huge task for an established project) or to have constantly-outdated step-by-step instructions and new developers taking half a day until they can even build the project.
However, you should take care to ensure that these configurations are portable, i.e. contain no local paths. This can be done via the use of relative paths within the workspace, eclipse path variables and user libraries.
我们所做的就是忽略这些文件，因为它们可能会弄乱项目中其他人的工作区。
忽略它们也会让你的项目更干净，这是我一直喜欢的。
What we've done is ignore these files, as they may mess up the workspace of others on the project.
Ignoring them also makes your project cleaner, which I always like.
这些文件可以包含环境特定路径，因此我建议不要签入它们。在我当前的项目中，我们使用 ant 脚本来创建项目并对所有代码进行初始签出。
These files can contain environment specific paths so I would suggest not checking them in. On my current project we use ant scripts to create the project and do the initial checkout of all our code.
一般来说，您应该签入（并在更改后提交）所有有助于构建的内容，并且不能通过完全重新构建来重新生成，并且是特定于工作站的。 （此语句的含义取决于您的构建过程/程序，这是有意的。）
这意味着您应该排除在完整构建等时重新生成的所有内容，因此不会签入（并且不提供签入） 。
Generally speaking, you should check-in (and commit after changes) everything that does contribute to the build AND is not re-generateable by re-building completely AND is workstation-specific. (The implications of this statement depend on your build process/procedure, which is intended.)
This implies you should exclude everything that is re-generated upon full build etc. so it is not checked in (and not offered for check-in).