我应该在IDE项目的存储库中包括什么

我想添加一个在这种情况下在Netbeans中创建的项目，但是这个问题对于大多数IDE来说都是通用的。很简单，我应该在存储库中包含什么。例如，Netbeans创建一个nbproject文件夹，eclipse创建一个.settings文件夹等。如果我将这些包含在我的存储库中，则包含或不包含项目特定设置的优点/缺点是什么？

在这种情况下，这是一个个人项目，因此我不认为其他人会开始进行该项目，但是最好添加最少的项目设置，这样项目本身就可以轻松在不同的机器上开始工作。

它实际上取决于它是什么数据，并且应该根据具体情况决定，甚至对于单个文件也应如此。看一下这些文件的内容。您经常会说出它们的意思。在源代码管理中，您不需要IDE窗口的位置和大小之类的东西。

但是某些IDE项目文件是至关重要的项目元数据。我不太了解Netbeans，但是对于eclipse，.project文件告诉IDE项目的名称是什么，它是Java Web项目等，.classpath文件包含有关源文件夹和库的信息。.settings目录中的某些文件可能同样重要，例如org.eclipse.core.resources.prefs包含有关哪些文件应使用哪种编码的信息。

作为项目元数据，这些内容非常值得在源代码管理中进行版本控制。

某些IDE可以从其他IDE导入项目元数据。以不受特定IDE约束的形式提供它甚至会更好。

对于Java，有这样的事情：Maven。它对项目的结构强加了约定，并允许您在一点（项目主目录中当然还有源代码控制中，一个名为pom.xml的文件）中指定项目元数据（例如库依赖项）。有一些插件可以从Maven配置中创建IDE项目文件，还有一些插件可以使项目构建过程自动化，或者可以执行几乎所有操作。有时感觉好像使事情变得不必要地复杂，需要花费一些时间来学习，但是通常值得这样做。

这实际上取决于您希望在存储库中拥有什么样的信息。如果您希望所有内容都到提交时打开并正在编辑的文件，并且您是唯一使用存储库的文件，请继续进行所有提交，但要知道它可能无法在另一台计算机上运行。

如果您希望能够与可能未使用同一IDE的其他人共享代码，则只需提交代码本身，而无需任何特定于项目的实现。

如果您知道每个人都使用相同的IDE，那么您可能可以包含所有非计算机专用的东西，即仅IDE本身的任何设置文件/文件夹，这样他们就可以将项目作为文件导入。 IDE期望它。

不应包括对您的开发无济于事的工件，这些工件对构建/发行版或项目本身都没有用。仓库应该干净整洁，并且只有与项目有关的东西，而不是与您的环境有关的东西。回购应该了解您的习惯。其次，当执行类似于git status...的操作时，它会不必要地给您带来麻烦，但是，嘿，我从未进行任何更改...啊，不要理会。

让我给出一个更实际的例子（我将git在这里用作工具）：

您永远不会希望主存储库中的（递归）子模块具有特定于IDE的东西（它也可能会干扰主项目环境），因为您所关心的只是别人（或您）编写的代码，并且在当前项目中的使用情况。不是开发它的环境。您可能也不想对其他人这样做。

为了能够在另一台机器上使用您的设置，我建议在您的IDE中进行挖掘，并查看它为这些事情提供了哪些支持。Emacs也有initEmacs服务器。或者，您可以使您的自定义宏或script（.sh）自动执行设置。

如果是个人项目，我说是将设置存储在源代码管理中。就个人而言，没有什么比重新建立开发环境更能杀死我的项目动力了。

当更多的人参与进来时，我不会将这些东西放在源代码控制中。在我的团队中，我们混合使用了IntelliJ，Sublime Text和Eclipse。IDE文件只会增加混乱，并导致其他人针对您不使用的IDE提交对这些文件的提交。

另外，您的项目无论如何都不应依赖于IDE。构建服务器不会启动Eclipse来编译您的产品，因此它应该已经没有IDE。还有一个小问题：它消除了项目中的个人组织。例如，在IntelliJ中，我喜欢在项目中使用许多模块。没有其他人使用IntelliJ担心这一点，因为我们不存储.iml（模块）文件。

如果您的团队使用相同的IDE，那就更好了，但是有人提交了错误的.c​​lasspath条目，因为他们使用了绝对路径。现在，使用IDE的每个人都对此感到担心。

当然，缺点是当有人签出项目时会有更多设置。我认为这是值得的。我们使用Ivy进行依赖项管理，并获得有关设置，依赖项等的信息。尽管有前期成本，但我认为将IDE设置置于源代码控制之外还是值得的。