如何向管理层证明在 GitHub 中保存 IDE 特定文件是徒劳的

Posted 2023-02-19

【中文标题】如何向管理层证明在 GitHub 中保存 IDE 特定文件是徒劳的

【英文标题】：How to prove to the management the futility of saving IDE specific files in GitHub

【发布时间】：2020-10-15 09:58:39

【问题描述】：

我无法向管理层证明在 GitHub 中保存 IDE 特定文件和文件夹是徒劳的，甚至是有害的

故意把两个不同的问题混在一起也有问题：

我想用 Eclipse； 如果我们使用 Eclipse，那么它的文件应该存储在存储库中；

我什么都试过了：

来自“与项目无关的文件不应存在” 致“每个开发人员都知道如何根据 pom.xml 为项目配置 IDE” 和“如果两个程序员使用两个不同的 IDE，他们的文件也应该被保存吗？” 等等...比如“专门设计的 gitignore.io 会根据您的使用情况提供推荐的 gitignore。”

除了“很长一段时间没有人这样做，因为它很明显”之外，还可以给出什么论据。

PS。我不会开始另一场圣战，我需要管理层清楚的论据。

【问题讨论】：

How to manage projects under Version Control Systems 可能有用。

【参考方案1】：

规则不是不共享特定于 IDE 的文件，而是只要维护特定于工具的文件，它们应该共享，即使不是所有人都使用它们。

这适用于 GitHub、Jenkins、FindBugs/SpotBugs、Eclipse 等工具的特定文件。这些文件的存在不会造成损害（以点开头的文件和文件夹意味着隐藏）。这是有据可查的（例如here for Eclipse），毕竟，这些工具不会无缘无故地将这些文件放在项目目录中，尽管其他情况下也有可能，但因为它们是用来共享的。

但是，仍然有人认为应该只存在一个特定于 Maven 的 pom.xml 文件，该文件只专注于构建。但由于他们都不是工具开发人员，而且他们都从未说服过工具开发人员，因此您不太可能说服您的管理层。

还要注意 Eclipse 特定的文件并不特定于 Eclipse IDE，因为它们也被例如使用。 VS 代码。特定于 Eclipse 的甚至不是特定于 IDE，因为例如，Java 的 Eclipse 编译器 (ecj) 可以用作构建内部的 linter，以在服务器上运行。