Should I keep project filesm like Eclipse's .project, .classpath, .settings, under version control (e.g. Subversion, GitHub, CVS, Mercurial, etc)?
我是否应该将项目文件m(如Eclipse的.project、.classpath、.settings)置于版本控制之下(例如Subversion、GitHub、CVS、Mercurial等)?
12 个解决方案
#1
87
You do want to keep in version control any portable setting files,
meaning:
Any file which has no absolute path in it.
That includes:
您确实希望在版本控制中保留任何可移植的设置文件，即:任何没有绝对路径的文件。这包括:
- .project,
- . project,
- .classpath (if no absolute path used, which is possible with the use of IDE variables, or user environment variables)
- .classpath(如果不使用绝对路径，可以使用IDE变量或用户环境变量)
- IDE settings (which is where i disagree strongly with the 'accepted' answer). Those settings often includes static code analysis rules which are vitally important to enforce consistently for any user loading this project into his/her workspace.
- IDE设置(我强烈反对“已接受”的答案)。这些设置通常包括静态代码分析规则，这些规则对于任何将项目加载到他/她的工作区中的用户来说都是非常重要的。
- IDE specific settings recommandations must be written in a big README file (and versionned as well of course).
- IDE特定的设置命令必须写在一个大的README文件中(当然也包括版本)。
Rule of thumb for me:
You must be able to load a project into a workspace and have in it everything you need to properly set it up in your IDE and get going in minutes.
No additional documentation, wiki pages to read or what not.
Load it up, set it up, go.
我的经验法则是:您必须能够将一个项目加载到一个工作空间中，并在其中包含所有您需要的东西，以便在IDE中正确设置它，并在几分钟内开始工作。不需要额外的文档，不需要阅读的wiki页面。加载，设置，开始。
#2
30
.project and .classpath files yes. We do not however keep our IDE settings in version control. There are some plugins that do not do a good job of persisting settings and we found that some settings were not very portable from one dev machine to the next. So, we instead have a Wiki page that highlights the steps required for a developer to setup their IDE.
.project和.classpath文件是的。但是，我们不会在版本控制中保持IDE设置。有些插件在持久化设置方面做得不太好，我们发现有些设置在一台开发机器到另一台机器之间的可移植性不是很好。因此，我们有一个Wiki页面，强调开发人员设置IDE所需的步骤。
#3
16
These are what I consider to be generated files, and as such I never place them under version control. They can be different from machine to machine and developer to developer, for instance when people have different Eclipse plugins installed.
这些是我认为是生成的文件，因此我从不将它们置于版本控制之下。它们可以不同于机器、开发人员和开发人员，例如当人们安装了不同的Eclipse插件时。
Instead, I use a build tool (Maven) that can generate initial versions of these files when you make a new checkout.
相反，我使用一个构建工具(Maven)，它可以在您进行新的签出时生成这些文件的初始版本。
#4
7
I am torn between two options here.
我在两个选择之间左右为难。
On one hand, I think that everyone should be free to use the set of developemnt tools they are most productive with, as long as all source artifacts are stored in version control, and the build script (say ANT or Maven) ensures standards compliance by specifying exactly which JDK to use, which versions of which third party libraries to depend upon, running style checks (e.g. checkstyle) and running unit tests etc.
一方面,我认为每个人都应该免费使用的集合developemnt他们最有效的工具,只要所有源构件存储在版本控制,并构建脚本(比如ANT或Maven)确保合规通过指定哪些标准JDK使用哪个版本的依赖的第三方库,运行方式检查(如checkstyle)和运行单元测试等。
On the other hand, I think so many people use the same tools (e.g. Eclipse) and often it is much better to have some things standardised at design time instead of build time - for example Checkstyle is far more useful as an Eclipse plugin than as an ANT or Maven task - that it is better to standardise on the set of development tools and a common set of plugins.
另一方面,我认为很多人使用相同的工具(例如Eclipse),通常是更好的一些标准化在设计时,而不是构建时——例如Checkstyle是有用的作为一个Eclipse插件远远超过一个ANT或Maven的任务——最好是标准化的开发工具集和一组通用的插件。
I worked on a project where everyone used exactly the same JDK, same version of Maven, the same version of Eclipse, the same set of Eclipse plugins and the same configuration files (e.g. Checkstyle profiles, code formatter rules etc.). All of these were kept in source control - .project, .classpath and everything in the .settings folder. It made life really easy during the initial phases of the project when people were continually tweaking the dependencies or the build process. It also helped immensely when adding new starters to the project.
我在一个项目中工作，每个人都使用相同的JDK、相同版本的Maven、相同版本的Eclipse、相同的Eclipse插件和相同的配置文件(例如Checkstyle profiles、code formatter规则等)。所有这些都保存在source control - .project、.classpath以及.settings文件夹中的所有内容中。在项目的初始阶段，当人们不断地调整依赖关系或构建过程时，它使生活变得非常简单。在为项目添加新启动程序时，它也非常有用。
On balance, I think that if there are not too many chances of a religious war, you should standardise on the basic set of develop tools and plugins and ensure version compliance in your build scripts (for example by explicitly specifying the Java version).I don't think that there is much benefit to storing the JDK and the Eclipse installation in source control. Everything else that is not a derived artifact - including your project files, configuration and plugin preferences (particularly code formatter and style rules) - should go into source control.
总的来说，我认为如果发生宗教战争的可能性不大，您应该对基本的开发工具和插件集进行标准化，并确保构建脚本中的版本遵从性(例如显式地指定Java版本)。我不认为在源代码控制中存储JDK和Eclipse安装有很多好处。其他一切不是派生的工件——包括您的项目文件、配置和插件首选项(特别是代码格式化程序和样式规则)——应该进入源代码控制。
P.S. If you use Maven, there is an argument for saying that the .project and .classpath files are derived artifacts. This is only true if you generate them every time you do a build, and if you have never had to tweak them by hand (or inadvertently changed them by changing some preferences) after generating them from the POM
如果使用Maven，则有一种说法认为.project和.classpath文件是派生的构件。只有在每次构建时都生成它们，并且在从POM生成它们之后从来不用手工修改它们(或通过更改某些首选项不经意地修改它们)时，才会这样
#5
6
No, because I only version control files that are needed to build the software. Besides, individual developers may have their own project-specific settings.
不，因为我只控制需要构建软件的版本控制文件。此外，个别开发人员可能有他们自己的特定于项目的设置。
#6
5
No, I'm a heavy Maven user and use the Q for Eclipse plugin that creates and keeps .project and .classpath updated. For other things such as settings for plugins I usually mantain a README or Wiki-page about that.
不，我是一个重量级的Maven用户，使用Q作为Eclipse插件，创建并保持.project和.classpath更新。对于其他的东西，比如插件的设置，我通常要求一个自述或维基页面。
Also those I've worked with that prefer other IDEs just use the Maven-plugins to generate the files needed to keep their IDE (and themselves) happy.
另外，那些喜欢使用其他IDE的人也可以使用Maven-plugins来生成让他们的IDE(以及他们自己)满意的文件。
#7
5
This is all opinion, I suppose - but best practices over the years indicate that files specific to a given IDE shouldn't be stored in source control, unless your entire organization is standardized on one IDE and you never have any intent on switching.
我认为这是所有的观点——但是多年来的最佳实践表明，特定于给定IDE的文件不应该存储在源代码控制中，除非您的整个组织在一个IDE上标准化，并且您从来没有任何交换的意图。
Either way, you definitely don't want user settings stored - and .project can contain settings that are really developer specific.
不管怎样，您肯定不希望用户设置被存储——和.project可以包含真正针对开发人员的设置。
I recommend using something like Maven or Ant as a standardized build system. Any developer can get a classpath configured in their IDE in a few seconds.
我建议使用Maven或Ant作为标准构建系统。任何开发人员都可以在几秒钟内在IDE中配置一个类路径。
#8
1
Yes, except for the .settings folder. Committing the other files works well for us. There is a similar question here.
是的，除了.settings文件夹。提交其他文件对我们来说很有用。这里有一个类似的问题。
#9
1
Although I generally agree on the "do not version generated files" approach, we have problems with it and have to switch back.
虽然我大体上同意“不要生成文件”的方法，但是我们有问题，必须切换回来。
Note: I am also interested in VonC's answer, particularly about the "get Eclipse up within minutes" point. But it is not decisive to us.
注意:我对VonC的答案也很感兴趣，特别是关于“在几分钟内完成Eclipse”这一点。但这对我们来说并不是决定性的。
Our context is Eclipse+Maven, using m2eclipse plug-in. We have a common development environment, with common directories as much as possible. But it happens sometimes that someone would try a plug-in, or change little things in the configuration, or import a second workspace for a different branch...
我们的上下文是使用m2eclipse插件的Eclipse+Maven。我们有一个通用的开发环境，有尽可能多的通用目录。但是，有时有人会尝试一个插件，或者在配置中更改一些小东西，或者为另一个分支导入第二个工作区……
Our problem is that the generation of .project is done when importing a project in Eclipse, but is not updated in all cases later on. It's sad, and probably not permanent as the m2eclipse plug-in will improve, but it's true right now. So we end up having different configurations. What we had today was that: several natures were added to many projects on some machine, which then behaved much differently :-(
我们的问题是，在Eclipse中导入项目时完成了.project的生成，但是在以后的所有情况中都没有更新。令人遗憾的是，随着m2eclipse插件的改进，它可能不会永久存在，但现在确实如此。所以我们得到了不同的构型。我们今天看到的是:在某些机器上，许多项目增加了一些性质，而这些性质又表现得大不相同。
The only solution we see is to version the .project file (to avoid risks, we'll do the same for .classpath and .settings). That way, when one developer changes her pom, the local files get updated using m2eclipse, all of them get committed together, and other developers will see all changes.
我们看到的唯一解决方案是版本.project文件(为了避免风险，我们将对.classpath和.settings执行相同的操作)。这样，当一个开发人员更改她的pom时，本地文件会使用m2eclipse更新，所有这些文件都将一起提交，其他开发人员将看到所有的更改。
Note : in our case, we use relative file names, so we have no problem to share those files.
注意:在我们的示例中，我们使用相对文件名，因此共享这些文件没有问题。
So, to answer your question, I say yes, commit those files.
为了回答你的问题，我同意，提交那些文件。
I also liked:
我也喜欢:
- Rich Seller's answer
- 丰富的卖家的回答
#10
0
It seems like these project files can change over time as you work on a project so yes, I place them under version control.
看起来这些项目文件可以随着时间的推移而更改，因为您正在处理一个项目，所以是的，我将它们置于版本控制之下。
#11
0
Yes. Everything but build output.
是的。除了构建输出。
#12
0
We use IntelliJ IDEA, and keep '.sample' versions of the project (.ipr) and module (.iml) files under version control.
我们使用IntelliJ IDEA，并keep '。在版本控制下的项目(.ipr)和模块(.iml)文件的示例版本。
Somewhat bigger thing here is sharing and re-use than versioning, IMHO. But if you are going to share these configurations, what better place to put them than the repository, right next to everything else.
比版本控制更重要的是共享和重用。但是，如果您要共享这些配置，还有什么比存储库更适合放置它们的地方呢?
Some advantages of shared & versioned project files:
共享和版本化项目文件的一些优点:
- You can check out any tag/branch and start working on it quickly
- 您可以检查任何标记/分支并开始快速地处理它
- Makes it easier for a new developer to first set up the development environment and get up to speed
- 让新开发人员更容易地首先设置开发环境，并加快速度。
- This better adheres to DRY, which is always deeply satisfying. Before this, all developers had to set these things up every now and then, essentially doing repeated work. Of course everyone had their own little ways to avoid repeating themselves, but looking at the team as a whole, there was a lot of duplicated effort.
- 这样可以更好地保持干燥，这总是令人非常满意的。在此之前，所有开发人员都必须时不时地设置这些东西，本质上就是做重复的工作。当然，每个人都有自己的小方法来避免重复自己，但是从整个团队来看，有很多重复的工作。
Note that in IDEA these files contain configurations such as: what are the "source" and "test source" dirs; everything about external dependencies (where are library jars located, as well as related sources or javadocs); build options, etc. This is stuff that does not vary from developer to developer (I disagree with this quite strongly). IDEA stores more personal IDE settings elsewhere, as well as any plugin configurations. (I don't know Eclipse that well; this may or may not be quite different.)
注意，在思想这些文件包含配置，如:什么是“源”和“测试源”dirs;关于外部依赖项的所有内容(库jar位于何处，以及相关的源或javadocs);构建选项等等。这一点在开发人员和开发人员之间没有差别(我非常不同意这一点)。IDEA在其他地方存储更多的个人IDE设置，以及任何插件配置。(我不太了解Eclipse;这可能是完全不同的，也可能不是完全不同。
I agree with this answer that says:
我同意这个答案:
You must be able to load a project into a workspace and have in it everything you need to properly set it up in your IDE and get going in minutes. [...] Load it up, set it up, go.
您必须能够将项目加载到一个工作空间中，并在其中包含您需要的一切，以便在IDE中正确设置项目，并在几分钟内开始工作。[…装好，装好，走。
And we have it like this, thanks to versioned project files.
多亏了版本化的项目文件，我们得到了这样的结果。
#1
87
You do want to keep in version control any portable setting files,
meaning:
Any file which has no absolute path in it.
That includes:
您确实希望在版本控制中保留任何可移植的设置文件，即:任何没有绝对路径的文件。这包括:
- .project,
- . project,
- .classpath (if no absolute path used, which is possible with the use of IDE variables, or user environment variables)
- .classpath(如果不使用绝对路径，可以使用IDE变量或用户环境变量)
- IDE settings (which is where i disagree strongly with the 'accepted' answer). Those settings often includes static code analysis rules which are vitally important to enforce consistently for any user loading this project into his/her workspace.
- IDE设置(我强烈反对“已接受”的答案)。这些设置通常包括静态代码分析规则，这些规则对于任何将项目加载到他/她的工作区中的用户来说都是非常重要的。
- IDE specific settings recommandations must be written in a big README file (and versionned as well of course).
- IDE特定的设置命令必须写在一个大的README文件中(当然也包括版本)。
Rule of thumb for me:
You must be able to load a project into a workspace and have in it everything you need to properly set it up in your IDE and get going in minutes.
No additional documentation, wiki pages to read or what not.
Load it up, set it up, go.
我的经验法则是:您必须能够将一个项目加载到一个工作空间中，并在其中包含所有您需要的东西，以便在IDE中正确设置它，并在几分钟内开始工作。不需要额外的文档，不需要阅读的wiki页面。加载，设置，开始。
#2
30
.project and .classpath files yes. We do not however keep our IDE settings in version control. There are some plugins that do not do a good job of persisting settings and we found that some settings were not very portable from one dev machine to the next. So, we instead have a Wiki page that highlights the steps required for a developer to setup their IDE.
.project和.classpath文件是的。但是，我们不会在版本控制中保持IDE设置。有些插件在持久化设置方面做得不太好，我们发现有些设置在一台开发机器到另一台机器之间的可移植性不是很好。因此，我们有一个Wiki页面，强调开发人员设置IDE所需的步骤。
#3
16
These are what I consider to be generated files, and as such I never place them under version control. They can be different from machine to machine and developer to developer, for instance when people have different Eclipse plugins installed.
这些是我认为是生成的文件，因此我从不将它们置于版本控制之下。它们可以不同于机器、开发人员和开发人员，例如当人们安装了不同的Eclipse插件时。
Instead, I use a build tool (Maven) that can generate initial versions of these files when you make a new checkout.
相反，我使用一个构建工具(Maven)，它可以在您进行新的签出时生成这些文件的初始版本。
#4
7
I am torn between two options here.
我在两个选择之间左右为难。
On one hand, I think that everyone should be free to use the set of developemnt tools they are most productive with, as long as all source artifacts are stored in version control, and the build script (say ANT or Maven) ensures standards compliance by specifying exactly which JDK to use, which versions of which third party libraries to depend upon, running style checks (e.g. checkstyle) and running unit tests etc.
一方面,我认为每个人都应该免费使用的集合developemnt他们最有效的工具,只要所有源构件存储在版本控制,并构建脚本(比如ANT或Maven)确保合规通过指定哪些标准JDK使用哪个版本的依赖的第三方库,运行方式检查(如checkstyle)和运行单元测试等。
On the other hand, I think so many people use the same tools (e.g. Eclipse) and often it is much better to have some things standardised at design time instead of build time - for example Checkstyle is far more useful as an Eclipse plugin than as an ANT or Maven task - that it is better to standardise on the set of development tools and a common set of plugins.
另一方面,我认为很多人使用相同的工具(例如Eclipse),通常是更好的一些标准化在设计时,而不是构建时——例如Checkstyle是有用的作为一个Eclipse插件远远超过一个ANT或Maven的任务——最好是标准化的开发工具集和一组通用的插件。
I worked on a project where everyone used exactly the same JDK, same version of Maven, the same version of Eclipse, the same set of Eclipse plugins and the same configuration files (e.g. Checkstyle profiles, code formatter rules etc.). All of these were kept in source control - .project, .classpath and everything in the .settings folder. It made life really easy during the initial phases of the project when people were continually tweaking the dependencies or the build process. It also helped immensely when adding new starters to the project.
我在一个项目中工作，每个人都使用相同的JDK、相同版本的Maven、相同版本的Eclipse、相同的Eclipse插件和相同的配置文件(例如Checkstyle profiles、code formatter规则等)。所有这些都保存在source control - .project、.classpath以及.settings文件夹中的所有内容中。在项目的初始阶段，当人们不断地调整依赖关系或构建过程时，它使生活变得非常简单。在为项目添加新启动程序时，它也非常有用。
On balance, I think that if there are not too many chances of a religious war, you should standardise on the basic set of develop tools and plugins and ensure version compliance in your build scripts (for example by explicitly specifying the Java version).I don't think that there is much benefit to storing the JDK and the Eclipse installation in source control. Everything else that is not a derived artifact - including your project files, configuration and plugin preferences (particularly code formatter and style rules) - should go into source control.
总的来说，我认为如果发生宗教战争的可能性不大，您应该对基本的开发工具和插件集进行标准化，并确保构建脚本中的版本遵从性(例如显式地指定Java版本)。我不认为在源代码控制中存储JDK和Eclipse安装有很多好处。其他一切不是派生的工件——包括您的项目文件、配置和插件首选项(特别是代码格式化程序和样式规则)——应该进入源代码控制。
P.S. If you use Maven, there is an argument for saying that the .project and .classpath files are derived artifacts. This is only true if you generate them every time you do a build, and if you have never had to tweak them by hand (or inadvertently changed them by changing some preferences) after generating them from the POM
如果使用Maven，则有一种说法认为.project和.classpath文件是派生的构件。只有在每次构建时都生成它们，并且在从POM生成它们之后从来不用手工修改它们(或通过更改某些首选项不经意地修改它们)时，才会这样
#5
6
No, because I only version control files that are needed to build the software. Besides, individual developers may have their own project-specific settings.
不，因为我只控制需要构建软件的版本控制文件。此外，个别开发人员可能有他们自己的特定于项目的设置。
#6
5
No, I'm a heavy Maven user and use the Q for Eclipse plugin that creates and keeps .project and .classpath updated. For other things such as settings for plugins I usually mantain a README or Wiki-page about that.
不，我是一个重量级的Maven用户，使用Q作为Eclipse插件，创建并保持.project和.classpath更新。对于其他的东西，比如插件的设置，我通常要求一个自述或维基页面。
Also those I've worked with that prefer other IDEs just use the Maven-plugins to generate the files needed to keep their IDE (and themselves) happy.
另外，那些喜欢使用其他IDE的人也可以使用Maven-plugins来生成让他们的IDE(以及他们自己)满意的文件。
#7
5
This is all opinion, I suppose - but best practices over the years indicate that files specific to a given IDE shouldn't be stored in source control, unless your entire organization is standardized on one IDE and you never have any intent on switching.
我认为这是所有的观点——但是多年来的最佳实践表明，特定于给定IDE的文件不应该存储在源代码控制中，除非您的整个组织在一个IDE上标准化，并且您从来没有任何交换的意图。
Either way, you definitely don't want user settings stored - and .project can contain settings that are really developer specific.
不管怎样，您肯定不希望用户设置被存储——和.project可以包含真正针对开发人员的设置。
I recommend using something like Maven or Ant as a standardized build system. Any developer can get a classpath configured in their IDE in a few seconds.
我建议使用Maven或Ant作为标准构建系统。任何开发人员都可以在几秒钟内在IDE中配置一个类路径。
#8
1
Yes, except for the .settings folder. Committing the other files works well for us. There is a similar question here.
是的，除了.settings文件夹。提交其他文件对我们来说很有用。这里有一个类似的问题。
#9
1
Although I generally agree on the "do not version generated files" approach, we have problems with it and have to switch back.
虽然我大体上同意“不要生成文件”的方法，但是我们有问题，必须切换回来。
Note: I am also interested in VonC's answer, particularly about the "get Eclipse up within minutes" point. But it is not decisive to us.
注意:我对VonC的答案也很感兴趣，特别是关于“在几分钟内完成Eclipse”这一点。但这对我们来说并不是决定性的。
Our context is Eclipse+Maven, using m2eclipse plug-in. We have a common development environment, with common directories as much as possible. But it happens sometimes that someone would try a plug-in, or change little things in the configuration, or import a second workspace for a different branch...
我们的上下文是使用m2eclipse插件的Eclipse+Maven。我们有一个通用的开发环境，有尽可能多的通用目录。但是，有时有人会尝试一个插件，或者在配置中更改一些小东西，或者为另一个分支导入第二个工作区……
Our problem is that the generation of .project is done when importing a project in Eclipse, but is not updated in all cases later on. It's sad, and probably not permanent as the m2eclipse plug-in will improve, but it's true right now. So we end up having different configurations. What we had today was that: several natures were added to many projects on some machine, which then behaved much differently :-(
我们的问题是，在Eclipse中导入项目时完成了.project的生成，但是在以后的所有情况中都没有更新。令人遗憾的是，随着m2eclipse插件的改进，它可能不会永久存在，但现在确实如此。所以我们得到了不同的构型。我们今天看到的是:在某些机器上，许多项目增加了一些性质，而这些性质又表现得大不相同。
The only solution we see is to version the .project file (to avoid risks, we'll do the same for .classpath and .settings). That way, when one developer changes her pom, the local files get updated using m2eclipse, all of them get committed together, and other developers will see all changes.
我们看到的唯一解决方案是版本.project文件(为了避免风险，我们将对.classpath和.settings执行相同的操作)。这样，当一个开发人员更改她的pom时，本地文件会使用m2eclipse更新，所有这些文件都将一起提交，其他开发人员将看到所有的更改。
Note : in our case, we use relative file names, so we have no problem to share those files.
注意:在我们的示例中，我们使用相对文件名，因此共享这些文件没有问题。
So, to answer your question, I say yes, commit those files.
为了回答你的问题，我同意，提交那些文件。
I also liked:
我也喜欢:
- Rich Seller's answer
- 丰富的卖家的回答
#10
0
It seems like these project files can change over time as you work on a project so yes, I place them under version control.
看起来这些项目文件可以随着时间的推移而更改，因为您正在处理一个项目，所以是的，我将它们置于版本控制之下。
#11
0
Yes. Everything but build output.
是的。除了构建输出。
#12
0
We use IntelliJ IDEA, and keep '.sample' versions of the project (.ipr) and module (.iml) files under version control.
我们使用IntelliJ IDEA，并keep '。在版本控制下的项目(.ipr)和模块(.iml)文件的示例版本。
Somewhat bigger thing here is sharing and re-use than versioning, IMHO. But if you are going to share these configurations, what better place to put them than the repository, right next to everything else.
比版本控制更重要的是共享和重用。但是，如果您要共享这些配置，还有什么比存储库更适合放置它们的地方呢?
Some advantages of shared & versioned project files:
共享和版本化项目文件的一些优点:
- You can check out any tag/branch and start working on it quickly
- 您可以检查任何标记/分支并开始快速地处理它
- Makes it easier for a new developer to first set up the development environment and get up to speed
- 让新开发人员更容易地首先设置开发环境，并加快速度。
- This better adheres to DRY, which is always deeply satisfying. Before this, all developers had to set these things up every now and then, essentially doing repeated work. Of course everyone had their own little ways to avoid repeating themselves, but looking at the team as a whole, there was a lot of duplicated effort.
- 这样可以更好地保持干燥，这总是令人非常满意的。在此之前，所有开发人员都必须时不时地设置这些东西，本质上就是做重复的工作。当然，每个人都有自己的小方法来避免重复自己，但是从整个团队来看，有很多重复的工作。
Note that in IDEA these files contain configurations such as: what are the "source" and "test source" dirs; everything about external dependencies (where are library jars located, as well as related sources or javadocs); build options, etc. This is stuff that does not vary from developer to developer (I disagree with this quite strongly). IDEA stores more personal IDE settings elsewhere, as well as any plugin configurations. (I don't know Eclipse that well; this may or may not be quite different.)
注意，在思想这些文件包含配置，如:什么是“源”和“测试源”dirs;关于外部依赖项的所有内容(库jar位于何处，以及相关的源或javadocs);构建选项等等。这一点在开发人员和开发人员之间没有差别(我非常不同意这一点)。IDEA在其他地方存储更多的个人IDE设置，以及任何插件配置。(我不太了解Eclipse;这可能是完全不同的，也可能不是完全不同。
I agree with this answer that says:
我同意这个答案:
You must be able to load a project into a workspace and have in it everything you need to properly set it up in your IDE and get going in minutes. [...] Load it up, set it up, go.
您必须能够将项目加载到一个工作空间中，并在其中包含您需要的一切，以便在IDE中正确设置项目，并在几分钟内开始工作。[…装好，装好，走。
And we have it like this, thanks to versioned project files.
多亏了版本化的项目文件，我们得到了这样的结果。