哪些 Eclipse 文件应该纳入版本控制范围内？

小开

最佳答案

元数据不应该在源代码控制中进行管理。它们主要包含与你的工作区相关的数据。

唯一的例外是.launch XML文件(启动器定义)。

它们存在于

[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches

它们应该复制到你的项目目录中:当你的项目刷新时，这些配置将显示在“Run configuration”对话框中。

这样，这些启动参数文件也可以管理到SCM中。

(警告:在运行/启动/启动配置首选项面板中执行取消勾选“删除关联资源时删除配置”选项:为了重新导入一个项目，通常会软删除它-强制重新初始化eclipse元数据。但这个选项，如果勾选，将删除您的详细发射参数!)

project-dir/.project
project-dir/.classpath
project-dir/.settings/*

应该在你的SCM(特别是.project和.classpath根据Eclipse文档)。

目标是任何人都可以签出/更新他/她的SCM工作空间，并将Eclipse项目导入Eclipse工作空间。

为此，你希望在你的.classpath中只使用相对路径，使用链接资源。

注意:如果project-dir指的是一个“外部”项目目录，而不是在eclipse工作空间下创建的目录，效果会更好。这样，这两个概念(eclipse工作空间和SCM工作空间)就被清晰地分开了。

正如ipsquiggle在注释中提到的，正如我已经提到的在一个古老的回答中，实际上你可以直接在项目目录中将启动配置保存为共享文件。所有启动配置都可以像其他项目文件一样进行版本控制。

(来自KD的博客文章提示:创建和共享启动配置)

alt text

小开

我觉得一个都没有。它们很可能包含只与您的工作站相关的信息(我在考虑库和所有的路径)。另外，如果团队中有人不使用Eclipse怎么办?

小开

我目前正在做一个项目，我们在源代码控制下有.project和.cproject文件。我们的想法是，与库路径和链接指令相关的设置将在整个团队中传播。

在实践中，它并没有很好地工作，合并几乎总是以冲突状态返回，需要在eclipse之外消除冲突，然后项目关闭并重新打开以使更改生效。

我不建议将它们保留在源代码控制中。

小开

有些项目，比如使用Maven的项目，喜欢基于POMs生成.project文件。

也就是说，除此之外- .metadata不应该在源代码控制中。您的项目将必须确定projectdir/。根据您计划如何管理标准等，设置会执行此操作。如果您可以真诚地相信开发人员会基于标准设置环境，并且您不必为任何项目定制任何特殊的东西，那么您就不需要把它们放进去。对我来说，我建议具体配置每个项目。这使得开发人员可以在同一个工作空间中处理多个项目的内容，而不必反复更改默认设置，并且它使设置非常明确，覆盖他们的默认设置以匹配项目的标准。

唯一困难的部分是确保它们保持同步。但在大多数情况下，您可以将.settings文件从一个项目复制到另一个项目。如果有任何您特别不想在源代码控制中使用的内容，为它们设置svn:ignore，如果您的SCM支持的话。

小开

CDT配置文件不是源代码控制友好的，这是毫无价值的。有一个关于.cproject文件频繁更改并导致冲突的错误文件，请参阅在存储库中共享cdt-project文件总是会导致冲突。

小开

classpath文件无疑是检查scm的一个很好的候选文件，因为手动设置它可能会有很多工作，并且对于新开发人员来说很难进入项目。的确，它可以从其他来源生成，在这种情况下，您将检入其他来源。

至于.settings，这取决于设置。这是一个灰色地带，但是一些设置几乎是强制性的，并且可以方便地检出项目，在Eclipse中导入它，并设置好一切。

因此，在我们的项目中，我们维护了一个名为CVS的.settings文件夹的副本。设置，我们有一个ant任务复制到。Settings。从CVS获取项目时，调用“eclipsify”ant任务将默认设置复制到新的.settings文件夹。当您配置了开发项目的每个人都需要的设置时，您将这些设置合并回CVS中。并将其提交到CVS。这样在SCM中保存设置就变成了一个有意识的过程。它确实要求开发人员在签入大的更改时，不时地将这些设置合并回他们的.settings文件夹。但是这个简单的系统却出奇的好。

小开

考虑:

.classpath
.project
.launch

这些应该在版本控制中，只要你坚持使用项目相对路径。这允许其他开发人员检查项目并立即开始工作，而不必经历其他开发人员所经历的所有设置痛苦。

您可能也想在版本控制中包含.metadata，这样Eclipse开发人员就可以检查整个工作空间，并将其预配置为所有正确的项目，但是它包含了大量特定于用户的信息，任何人在任何时候使用它都会发生变化，因此我建议不要包含.metadata。只需导入所有现有Eclipse项目，就可以轻松构建本地工作区。

小开

我花了太多时间为新同事(和我自己)配置eclipse工作空间设置。我最终做的是把我自己的.metadata复制到新的开发人员机器上。

如果你是在一个团队中工作，那么我认为以下是非常适合进行版本控制的:

已安装的jre及其名称
服务器运行时环境
Java编辑器模板
版本控制键盘快捷键
不提供项目特定设置的插件设置
Maven的设置
预配置的角度
.．.

小开

我还没有尝试过将.metadata中的任何东西置于版本控制之下，但我对这些文件使用版本控制已经有十年了:

project-dir/.project
project-dir/.classpath
project-dir/.settings/*

主要原因是Eclipse有时会损坏这些文件。如果没有版本控制，您就会变得很奇怪，并且很难跟踪错误。使用版本控制，您可以立即看到“为什么它试图部署测试类??”或“为什么Maven和Eclipse使用相同的类路径?”(导致https://bugs.eclipse.org/bugs/show_bug.cgi?id=430605)。

使用版本控制，您可以看到它何时发生，并轻松地返回到配置文件的工作集。

如果您使用m2e:您现在可以导入项目，使用快捷的“导入现有项目”;而不是缓慢的“导入Maven项目”。

这种方法的缺点是Eclipse似乎会随机更改其中一些文件。大多数插件保持它们的稳定，但有些使用HashMap而不是LinkedHashMap，所以元素的顺序一直在变化。这意味着提交时有一个额外的步骤:首先检查所有修改过的设置并处理它们。

这也意味着整个团队必须在一些标准上达成一致:比如应该启用哪些警告。有趣的是，许多人把这看作是一个额外的问题——就好像他们没有在一起工作一样。

根据我的经验，这些文件稳定下来需要几周时间。部分原因是您逐渐学会了如何调整Eclipse，部分原因是人们学会了哪些东西不能碰。你可以把这看作是浪费的时间，或者是花在改善工作环境质量上的时间(比如保持办公桌整洁)。

“先提交设置”还有一个额外的好处:它能让人们更频繁地、更小范围地提交(即更像“一次一个想法”)。而不是“一次一个功能”加上成千上万其他不相关的东西，我只是偶然发现……我在忙什么来着?”)。

作为一名经验丰富的开发人员，我更喜欢“小委托”。工作方式;坚持下去更容易，你倾向于把你的想法和改变分成更小、更易于管理的步骤。这有助于降低复杂性。每个人都能玩一个球，没人能玩20个球。

PS:对于某些设置文件，我有单元测试，以确保已知的错误不会像“试图部署测试”那样悄悄出现。在WTP。这在最初阶段很有帮助，“我太忙了”。阶段。