我应该检查我的.project和.classpath文件吗？
我的朋友告诉我，我应该只检查.java文件和build.xml以保证可移植性。他说“.classpath会让你在不同环境下的便携性降低得多。。project完全是你当地的日食设置”
我同意他的观点，但部分同意。
- 不检入.project文件会降低我的开发效率（我不能简单地从目录中“导入”项目代码）
- 如果我的build.xml是小心写的，那么不检入.classpath文件对我来说似乎没问题（？）。
有人想在这里分享他们的经历吗？
答案 0 :(得分：25)
登入.project和.classpath时没有任何问题。如果您的build.xml无法为您创建这两个文件，我会这样做。正如您所说，当您尝试创建新的eclipse工作区时，错过这些文件会很不舒服。
在您登记.classpath之前，您应确保其中没有绝对路径。使用文本编辑器将其转换为相对的。
编辑：或者甚至更好，在你的绝对路径中使用eclipse类路径变量，比如@ taylor-leese评论。
答案 1 :(得分：10)
检查.classpath文件时我要注意的一件事是确保你没有引用项目之外的文件。 Eclipse使用完整的文件路径存储这些文件的位置，您需要确保其他开发人员将这些文件放在完全相同的位置。
答案 2 :(得分：7)
所有这些文件的关键问题是“它们可以自动复制吗？”如果没有，请将它们检入源代码管理中。
在这种情况下，我会说“是的”，除非你使用maven，它有m2eclipse和eclipse插件为你生成它们。
答案 3 :(得分：6)
对于我的2美分，我认为这是一种不好的做法。项目不应该绑定到IDE，尤其不应该绑定到特定版本的IDE。
签入Eclipse配置文件可能适用于简单和短期项目。对于多年来开发的大型项目，这通常会导致更多的麻烦，因为IDE版本发生了变化，而项目配置文件也没有。想象一下，使用Eclipse 4.3中的Eclipse 2.0配置文件检查一个2岁的分支，其中包含一些自定义库和m2e集成......没有任何乐趣......
答案 4 :(得分：3)
我真的不知道eclipse首选项文件，但是使用IntelliJ，这些文件是操作系统不可知，这意味着它不会破坏你的可移植性。除非您使用系统的完整路径定义库（这将非常危险/愚蠢）。
当你分享偏好时，你肯定每个人都会在项目中使用相同的条件（插件配置，编码，配置文件[用于intelliJ]），这真的是一件好事。
当一些Eclipse文件在这里时，它并没有打扰我，我认为当一些隐藏文件存在时，它不应该/不会真正打扰其他开发人员。
答案 5 :(得分：3)
我们签入.project和.classpath。使用ProjectSet，我们可以使用单个“Import Team ProjectSet”检查复杂的工作区
答案 6 :(得分：2)
不检入.project文件 使我的开发效率降低（我 不能简单地“导入”项目代码 来自目录）
对于此问题，您可以选择创建新项目并导入现有来源。
IDE特定文件（如.project）的一个问题是，其他开发人员可能希望使用另一个IDE来开发项目，因此他们可能会添加另一种类型的项目文件。这会让你的回购变得凌乱。
答案 7 :(得分：1)
我更愿意签入.project和.classpath。
当这个项目被多个开发人员共享时，这将非常有用。通过简单地将此项目作为现有项目导入，可以轻松快捷地设置开发环境。系统使用eclipse。
这里只需要注意，classpath是相对于项目的。
答案 8 :(得分：1)
我经常有一个类似的，更普遍的问题。问题主要是：
我提出讨论这个there，所以你可以找到有关这个问题的更多细节，以及有趣的解决方案：）
我最喜欢的是使用git submodule：将您的.project个文件等保存在私人提交回购中。并将最终的，纯粹的，必不可少的src制作成一个整洁的submodule金块：公共回购。
project/ # root module
| .git # private repo
| .project
| .classpath
| momsNumber.txt
+---src/ # submodule
| | .git # public repo
| | main.java
| +---package/
| | | Etc.java
答案 9 :(得分：0)
将.classpath和.project文件签入存储库没有问题。它将帮助使用Eclipse的开发人员加快速度。
警告：确保您的.classpath文件仅引用通过项目检入存储库或可以自动获取的工件（例如maven工件）。