为什么人们gitignore .classpath和.project? [英] Why do people gitignore .classpath and .project?
问题描述
我的一位同事最近在eclipse中创建了一个新项目，并使用内置的git client进行了提交和推送.克隆到计算机并使用eclipse打开后，我发现eclipse创建了.classpath文件..classpath是不是eclipse project(也是.project)查找引用的jar的关键文件吗?谷歌搜索后，我感到非常困惑，看到所有讨论都在谈论忽略它们.它们对Eclipse正常工作不是至关重要的吗?人们为什么不理会他们?如果我不理them他们，那会是什么问题?
这些 Eclipse特定的文件使更容易设置 Java的Eclipse和Visual Studio代码项目.
通常， IDE和工具特定的文件(Eclipse， Jenkinsfile ，GitHub工作流程设置等)应该共享，只要它们被使用和保持.否则，将其删除.
当然，如果您使用的是不同的IDE ，而不是Eclipse和 Visual Studio代码，并且请勿在IntelliJ IDEA中使用Eclipse编译器，这些特定于Eclipse的文件是无用的，但没有害处.只要您不使用文件或文件夹链接(存储在 .project 文件中)之类的功能，共享这些文件不会导致IDE锁定.
在Maven和Gradle项目中， .classpath 文件可以从 pom.xml 或 build.gradle 文件派生，但应该共享的设置，例如编译器设置(警告和错误)，格式化程序或保存操作设置(存储在项目的 .settings 文件夹中)，strong>，以便每个人都使用相同的内容.
这也适用于 .project 文件，因为它包含了项目的性质以及所需的工具.如果缺少某些内容，则会出现一个对话框，询问是否应安装缺少的插件.
Eclipse将这些文件放在项目文件夹中，而不是在 .metadata 文件夹中，因为它们是要共享的.但是为什么有些人不共享这些文件?可能是由于历史原因.15或20年前，没有Git，Maven和Jenkins.如今，通常通过手动导出JAR或最多通过一些批处理/shell脚本在开发人员的计算机上构建Java应用程序.这意味着，在不同的计算机上甚至使用不同的IDE或IDE版本进行相同的构建可能导致不同的结果，从而带来很多麻烦.与IDE无关的构建是解决此问题的方法.也许这就是为什么今天的人们仍然认为一切都必须与IDE无关，并建议使用Maven或Gradle.但是，这些文件未共享以构建，而不是要交付的产品.希望如此.
One of my colleague recently created a new project in eclipse ,committed and pushed with built-in git client. After I cloned to my computer and opened with eclipse, I found eclipse creating .classpath file. Isn't .classpath a crucial file for eclipse project(also .project) to find referenced jars? I am very confused after googling, seeing all the discussions talking about ignoring them. Aren't they crucial to Eclipse to work correct ? Why are people ignoring them ? What's the problem if I have them not ignored ?
These Eclipse-specific files make it easier to set up Eclipse and Visual Studio Code for a Java project.
In general, IDE and tool specific files (Eclipse, Jenkinsfile, GitHub workflows settings, etc.) should be shared as long as they are used and maintained. Otherwise, delete them.
Of course, if you use a different IDE than Eclipse and Visual Studio Code and do not use the Eclipse compiler in IntelliJ IDEA, these Eclipse-specific files are useless, but they do no harm. As long as you do not use functions like file or folder links (stored in the .project file), sharing these files does not lead to IDE lock-in.
In Maven and Gradle projects the .classpath file can be derived from the pom.xml or build.gradle file, but settings that cannot be derived like compiler settings (warnings and errors), formatter or save actions settings (which are stored in the project's .settings folder) should be shared so that everyone uses the same.
This also applies to the .project file, as it contains which natures the project has and which tooling is required. If something is missing, a dialog will ask if the missing plug-ins should be installed.
Eclipse puts these files into the project folder and not into the .metadata folder, because they are intended to be shared. But why there are people who do not share these files? Probably because of historical reasons. 15 or 20 years ago, there wasn't Git, Maven and Jenkins. In these days, a Java application was usually built on a developer's computer by manually exporting JARs or at best via some batch/shell scripts. This meant, making the same build on a different computer or even just with a different IDE or IDE version might led to a different result, causing a lot of trouble. IDE agnostic builds was the solution for this problem. Maybe that's why people today still think that everything have to be IDE agnostic and recommend to use Maven or Gradle. But these files are not shared to build a product to be shipped. Hopefully.
这篇关于为什么人们gitignore .classpath和.project?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
