我应该提交由 Eclipse 更改的文件吗？答案

【问题标题】：Should I commit files that are changed by Eclipse?我应该提交由 Eclipse 更改的文件吗？
【发布时间】：2011-06-16 10:39:35
【问题描述】：

我继承了一个 Eclipse 项目形式的 Java 项目。更改 Tomcat 配置（从 v6 到 v7）后，Subclipse 提示我提交以下文件：

.classpath
org.eclipse.core.prefs
org.eclipse.common.project.facet.core.refs
org.eclipse.common.project.facet.core.xml

提交它们会帮助我的团队成员还是会扰乱他们的工作空间？

对此的最佳实践方法是什么？

【问题讨论】：

见stackoverflow.com/questions/116121/…，或stackoverflow.com/questions/2024307/…，或（更通用的）stackoverflow.com/questions/1880817/…
哇。我试着环顾四周。我认为我的问题可以“分成”两三个，并为每个问题得到适当的答复。我相信最好的答案是您的评论:-)

标签： java eclipse svn subclipse

【解决方案1】：

一般来说，您应该签入（并在更改后提交）对构建有贡献的所有内容，并且不能通过完全重新构建重新生成，并且是特定于工作站的。（此语句的含义取决于您的构建过程/程序，这是预期的。）

这意味着您应该排除在完整构建等时重新生成的所有内容，因此不会签入（并且不提供签入）。

【讨论】：

这也意味着问题中的所有文件都应检查与工作站相关的内容，例如文件路径和用户首选项。如果其中一些没有工作站或用户依赖，那么提交该特定文件就没有错。例如，.classpath 可能包含文件系统路径，但它可能只包含与工作站无关的库名称，并且它们的路径在别处定义。
@Sergey Tachenov：是的，这就是我所说的“此声明的含义取决于您的构建过程/程序，这是预期的。”
我检查了所有内容，发现这些文件都是独立于路径的。我认为在 Eclipse 中，一切都是路径独立或依赖的，但不是两者都...

【解决方案2】：

作为一般规则，您应该避免提交包含用户偏好的文件，以及 Eclipse 和/或您的插件可以重新生成的项目详细信息。

但在某些情况下，事情有点模糊。例如，.classpath 文件可以是 Eclipse 构建路径的主要来源；例如如果您的项目树中有 JAR 文件而不是使用 Maven。（使用 Maven，m2eclipse 插件会根据 POM 文件中的依赖信息生成 .classpath 文件，因此不应签入该文件。）

另外，一些方面的东西是边缘的。例如，在具有 JSP 和 Javascript 的项目中，我发现更改构面属性以禁用损坏的验证器至关重要。将这些更改视为项目的一部分而不是个人偏好是一个很好的案例。

将组/项目偏好与个人偏好分开是 (IMO) Eclipse 严重不足的一个领域。

【讨论】：

其他 IDE 是否更好，如果是，如何？我认为eclipse马马虎虎：将基本项目配置作为文本文件放在项目目录中真是太好了。让它们以各种格式分布在各种文件中并不是很好。
@Michael - “其他 IDE 更好吗” - 说真的，我不知道。它可能是那些太难/太迟无法修复的事情之一。

【解决方案3】：

最好不要提交这些文件，因为不同工作站上的路径/设置可能不同。

您可能想使用一些构建工具来克服这个问题。（例如 Maven）

好像任何团队成员都没有使用 eclipse（使用其他 ide），这些文件对他们没有意义。

如果每个人都提交不同的 IDE 设置，想象一下它会造成什么样的混乱。

编辑：

更多解释；

我曾在人们使用 NetBeans、Eclipse、IDEA 的团队中工作了很长时间……对于他们来说改变 IDE 并不是一个真正的选择。它只会影响那个人的工作效率。

当人们习惯他们的 IDE 时，他们会学习快捷方式，他们知道在哪里寻找某些功能（重构/生成 getter setter/实现覆盖所需的方法......）因此，如果您强迫他们使用其他 IDE，它会只是让他们的事情变得更难，让整个过程变得更慢。恕我直言，根据我的经验，拥有灵活的代码库总是好的。我是一个 Eclipse 人，可能不想与任何其他 IDE 一起工作，因为我知道很多快捷方式，这让我的事情变得更快/更容易，而且这些快捷方式在不同的 IDE 上是不同的。

只需点击几下，IDE 本身就可以自动重新生成所有 IDE 文件。

我目前的项目有 3 个开发人员，每个开发人员都使用不同的 IDE eclipse(me)、NetBeans、IDEA，没有任何问题。当我从 repo 查看源代码时，我不想看到对 eclipse 没有意义的 IDEA 或 NetBeans 配置文件。他们也一样。

【讨论】：

+1 表示工作站特定方面。作为回报，我允许自己在自己的答案中添加这个方面。
“由谁？为什么？” :) 完整的疑问句会让我明白问题是什么？
@fatih：好的。 “这被一个人否决了——被谁投反对票？为什么？”更好？
downvote 来自我，因为这些（除了对 Maven 的引用）都不是避免签入这些文件的实质性好处的好论据。
在 IDE 上进行标准化或让每个人都使用他们最了解的东西是一种权衡利弊的做法。但是“不想看到”来自其他 IDE 的配置文件仍然是不将它们置于源代码控制中的一个非常糟糕的理由。他们用那个 IDE 帮助人们，最坏的情况是对其他人来说只是一个小麻烦。

【解决方案4】：

是的，但请确保路径在工作空间中是相对的，而不是绝对路径。将这些文件放在工作区中可以让您的团队成员在与您相同的环境中工作。它还使设置新的开发环境变得更加容易：您只需将其从源代码控制中检查出来，然后在 Eclipse 中使用“导入... > 现有项目到工作区”

正如@adamdunne 提到的，这些文件可以包含特定于环境的路径。但是，如果您通过使用变量而不是导入外部 jar 来确保路径在您的工作空间内是相对的，即仅包括工作空间中项目的 jar，那么您应该没问题。在我的工作区中，我们签入了这些文件，并且在设置开发时遇到的问题要少得多。之后的环境。

【讨论】：

+1 表示如何摆脱特定于工作站的配置细节。
我们这样做了（'导入...> 现有项目到工作区'），这就是我首先提出这个问题的原因。目前我的团队处于培训模式，我想在项目的生命周期中采用尽可能多的最佳实践。

【解决方案5】：

我在一个项目中工作，我们在其中提交 .classpath 文件，因为所有开发人员都使用相同的文件非常有用.即使可能不需要构建此文件（例如使用 ant），同步它也非常方便。

相比之下，org.eclipse.core.prefs 存储 (afaik) 项目特定的，但我不会签入的开发人员的个人偏好。

我还没有在实际项目中工作过这些方面，所以我无法确定。但总的来说，我认为这取决于文件中的信息以及您的工作方式。

如果您不确定，请尝试一下。如果您整天都在这些文件中遇到冲突，这表明您可能没有走上完美的道路。

【讨论】：

>>如果您不确定，请尝试一下。
>> 如果您整天在这些文件中遇到冲突，这表明您可能不是在完美的道路上。
org.eclipse.core.prefs 存储诸如 Java 编译器源和目标版本以及警告/错误设置之类的内容，实际上我认为这些内容对于让每个开发人员自己决定都非常有用。
@Michael 的评论...我在哪里可以找到 Eclipse 存储什么？
@dimitris：这就是问题所在......我不认为它在任何地方都有正式记录。但是配置文件通常是相当可读的。

【解决方案6】：

这些文件对于在开发人员之间共享配置非常有用。另一种选择是使用 Maven（这对于已建立的项目来说是一项艰巨的任务），或者拥有不断过时的分步说明，新开发人员甚至需要半天时间才能构建项目。

但是，您应该注意确保这些配置是可移植的，即不包含本地路径。这可以通过使用工作区中的相对路径、eclipse 路径变量和用户库来完成。

【讨论】：

我也在不同的评论中写了它，我相信 eclipse 有所有相对或绝对的路径，但不是两者兼而有之。这是我发布这个问题的主要原因。基于这个和类似的建议，我开始审查每个文件并查看每个文件中发生了什么。非常感谢。
@dimitris：绝对有可能两者兼得。例如，当将 JAR 添加到项目的构建路径（这会在 .classpath 文件中生成一个条目）时，您可以使用“添加 JAR”选项，它允许您从工作区中选择一个文件并生成一个相对路径，和“添加外部 JAR”，它允许您选择任何文件并生成绝对路径。

【解决方案7】：

我们所做的是忽略这些文件，因为它们可能会弄乱项目中其他人的工作空间。

忽略它们也会使您的项目更整洁，这是我一直喜欢的。

【讨论】：

我没有投反对票，但是我猜反对票的人认为“更干净”太含糊了，就像“搞砸工作区”的情况一样。典型的新手情况：你尝试，然后被撞开。继续前进，@cgratgny，从中学习，你的积分余额迟早会爆炸。只是不要对这个最初的学习曲线感到沮丧，它可以被认为是正常的。
感谢@TheBlastOne 的评论。我知道我在尝试......只是在他们提供的解决方案方面不像其他人那么雄辩。

【解决方案8】：

这些文件可以包含特定于环境的路径，因此我建议不要签入它们。在我当前的项目中，我们使用 ant 脚本来创建项目并对我们所有的代码进行初始签出。

【讨论】：