Java 项目：.classpath .project 文件是否应该提交到存储库中？
我应该签入我的 .project 和 .classpath 文件吗？
我的朋友告诉我，我应该只签入 .java 文件和 build.xml 以保证可移植性。他说“.classpath 会导致你在不同环境下的可移植性大大降低。.project 完全是你本地的 eclipse 设置”
我同意他的观点，但部分同意。
-- 不签入 .project 文件将使我的开发效率降低（我不能简单地从目录“导入”项目代码）
-- 不签入 .classpath 文件对我来说似乎没问题（？），如果我的 build.xml写得很仔细。
有人想在这里分享他们的经验吗？
Should I check in my .project and .classpath files?
My friend told me that I should only check in .java files and the build.xml to guarantee portability. He said ".classpath will cause you much less portability on different environment. .project is entirely your local eclipse setting"
I agree with him, but partially.
-- Not checking in .project file will make my development less efficient (I can't simply "import" a project code from a directory)
-- Not checking in .classpath file seems OK to me (?) if my build.xml is written carefully.
Anyone wants to share their experience here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
签入
.project和.classpath没有任何问题。如果您的build.xml无法为您创建这两个文件，我会这样做。正如您所说，当您尝试创建新的 Eclipse 工作区时，错过这些文件会让人感到不舒服。在签入
.classpath之前，您应该确保其中没有绝对路径。使用文本编辑器将其转换为相对的。编辑：或者更好的是，在您的绝对路径中使用 eclipse 类路径变量，如 @taylor-leese 评论的那样。
There is nothing wrong with checking in
.projectand.classpath. I would do so, if yourbuild.xmlisn't able to create both of the files for you. As you said, it's uncomfortable to miss these files when you try to create a new eclipse workspace.Before you check in
.classpathyou should be sure that there is no absolute path in it. Convert it into a relative one with a text editor.Edit: Or even better, use eclipse classpath variables in your otherwise absolute pathes, like @taylor-leese commented.
对于我的 2 美分，我认为这是一种不好的做法。项目不应与 IDE 绑定，尤其不应与 IDE 的特定版本绑定。
签入 Eclipse 配置文件可能适合更简单和短期的项目。对于开发数年的大型项目，这通常会导致更多麻烦，因为 IDE 版本会发生变化，而项目配置文件不会发生变化。想象一下，在 Eclipse 4.3 中使用 Eclipse 2.0 配置文件检查一个 2 年历史的分支，并使用一些自定义库和 m2e 集成...一点也不有趣...
For my 2 cents, I would rate it as a bad practice. Projects should not be tied to an IDE, and especially should not be tied to a specific version of an IDE.
Checking in Eclipse config files might work well for simpler and short-term projects. For larger projects that are developed over several years this will generally cause more hassle, as IDE versions change, and project config files don't. Just imagine checking in a 2 year old branch with Eclipse 2.0 config files in Eclipse 4.3 with some customized libraries and m2e integration... No fun at all...
在签入 .classpath 文件时我要注意的一件事是确保不要引用项目外部的文件。 Eclipse 使用完整的文件路径存储这些文件的位置，您需要确保其他开发人员将这些文件放在完全相同的位置。
One thing I would caution against with checking in .classpath file is make sure you don't reference files outside of your project. Eclipse stores the location of these files with a full filepath, and you would need to make sure other developers had those files in exactly the same place.
所有此类文件的关键问题是“它们可以自动复制吗？”如果没有，请将它们检查到源代码管理中。
在这种情况下，我会说“是”，除非您使用 maven，它有 m2eclipse 和 eclipse 插件来为您生成它们。
The key question with all such files is "Can they be reproduced automatically?" If not, check them into source control.
In this case, I'd say "yes," unless you're using maven, which has m2eclipse and the eclipse plugin to generate them for you.
我真的不知道 eclipse 首选项文件，但对于 IntelliJ，这些文件与操作系统无关，这意味着它不会破坏您的可移植性。除非您定义具有系统完整路径的库（那将非常危险/愚蠢）。
当您共享首选项时，您可以确定每个人都会在项目中使用相同的条件（插件配置、编码、配置文件 [for intelliJ]），这确实是一件好事。
当一些 Eclipse 文件在这里时它不会打扰我，并且我认为当一些隐藏文件就在那里时它不应该/不会真正打扰其他开发人员。
I don't really know eclipse preferences files, but with IntelliJ, those files are OS agnostics, which means that it won't ruin your portability. Unless you define libraries with a full path to your system (That would be pretty dangerous/stupid).
When you share preferences, you're sure that everyone will work with the same conditions on the project (plugins configuration, encoding, profiles [for intelliJ]) which can really be a good thing.
It doesn't bother me when some Eclipse files are here, and I think it shouldn't/doesn't really bother other developers when some hidden files just lay there.
我们签入.project 和.classpath。借助 ProjectSet，我们可以通过单个“导入团队 ProjectSet”检查复杂的工作空间
We check in .project and .classpath. With ProjectSet's this allows us to check out complex workspaces with a single "Import Team ProjectSet"
此问题，您可以选择创建新项目并导入现有源。
IDE 特定文件（例如 .project）的一个问题是其他开发人员可能希望使用另一个 IDE 来开发项目，因此他们可能会添加另一种类型的项目文件。这会让你的仓库变得混乱。
for this issue, you can choose to create new project and import existing source.
one issue with IDE specific files like .project is that other Developers may want to use another IDE do develop the project, so they may add another type of project files. this will make your repo messy.
我更愿意签入 .project 和 .classpath。
当该项目由多个开发人员共享时，这将很有帮助。只需使用 eclipse 将其作为现有项目导入到任何系统上，即可轻松且快速地设置开发环境。 。
这里唯一需要注意的是类路径是相对于项目的。
I would prefer to checkin .project and .classpath.
This would be helpful when this project is being shared by multiple developers. It becomes easy and faster to setup development env. by simply importing this as existing project on any system using eclipse.
Only caution needs to be taken here is classpath's are relative to project.
我经常有类似的、更普遍的问题。问题本质上是：
我提议在那里讨论这个问题，因此您可能会找到有关该问题的更多详细信息以及有趣的解决方案
:)我最喜欢的是使用
git submodule：将您的.project文件等保存在私有提交存储库中。并将您最终的、纯粹的、必要的src作品制作成一个整洁的子模块金块：一个公共存储库。无论如何，请参阅那里。
I often have a similar, more general questionning. The problem essentially is :
I offered discussing this there, so you may find more details about the problem, along with interesting solutions :)
The one I like best is the use of
git submodule: keep your.projectfiles etc. in a private commit repo. And make your final, pure, essentialsrcproduction into a neatsubmodulenugget: a public repo.See there anyway.
将 .classpath 和 .project 文件签入存储库不存在问题。它将帮助使用 Eclipse 的开发人员更快地上手。
警告：确保您的 .classpath 文件仅引用与项目一起签入存储库或可以自动获取的工件（例如 Maven 工件）。
There is not problem of checking in .classpath and .project files into repository. It will help developers which use Eclipse to get going faster.
Warning: Make sure your .classpath file is referencing only artifacts which either checked into the repository with the project or can be obtained automatically (such as maven artifacts).