什么是允许程序员团队在同一个项目中使用 Netbeans、Eclipse 和 IntelliJ 的最佳方式,从而消除“哪个 IDE 更好”的问题。
哪些文件应该或不应该签入源代码控制?
什么是允许程序员团队在同一个项目中使用 Netbeans、Eclipse 和 IntelliJ 的最佳方式,从而消除“哪个 IDE 更好”的问题。
哪些文件应该或不应该签入源代码控制?
我认为最好的方法是让构建过程独立于 IDE。这意味着您的项目不应依赖任何特定于 IDE 的文件来构建,而应使用外部构建系统,如Apache Maven、Apache Ant,甚至是制作或自定义脚本。大多数流行的 Java IDE 直接或通过插件支持 Maven。
如果您不想使用外部构建系统,您至少应该使项目尽可能易于设置(即通过为共享库和其他依赖项设置标准文件夹)。过去,当我在具有多个 IDE 的团队中工作时,我花费最多的时间来解决依赖关系,因为构建项目的先决条件会随着时间的推移而发生变化。在最坏的情况下,您甚至可能最终导致开发人员不愿意从版本控制存储库中获取最新版本,因为他们认为设置新项目非常麻烦。
如果您的项目有许多库依赖项,我认为在版本控制存储库中以二进制形式提供这些是一个好主意。这样人们就不必解决依赖关系的所有依赖关系等等,只是为了构建一个项目。但是,这确实要求您有人负责在“官方”二进制文件发生更改时保持最新状态。(这与 Maven 存储库使用的理念几乎相同,但即使不使用 Maven,也可以手动应用这些原则。)
嗯,这是一个非常自我回答的问题。
不签入源代码控制的文件是与 IDE 本身有关的文件。
让开发人员生成这些文件。
如果您使用 Maven,它可以为您生成 Eclipse 等.project
文件.classpath
。一般来说,Eclipse 非常易于使用基本文件结构(使用新Java Project
选项)。
我认为 Maven 也支持 Netbeans,但不确定 IntelliJ。
Maven 的站点是maven.apache.org。
对于拥有多个开发人员的每个 IDE,请签入所有支持文件。为什么要在每张桌子上重新发明轮子。
我已经使用许多不同的 IDE 完成了此操作,但我还没有看到文件名冲突。
事实上,即使只有一个开发人员使用特定的 IDE,对支持文件进行版本控制对他/她来说也是有利的,原因与您在开发环境中对其他文件进行版本控制的原因相同:历史记录、差异、注释等。
对于 Eclipse,这将是 .classpath 和 .project 文件。
我的团队使用 Maven,并且不鼓励开发人员签入特定于 Eclipse 的文件。因为它们可以从 Maven 生成,所以这些文件是多余的。
此外,检查特定于项目的文件似乎可以节省时间,但由于不同开发人员工作站的差异,它通常会很痛苦,导致浪费时间解决特定于 IDE 的文件中的冲突。解决这个问题的唯一方法是强制每个人都以相同的方式设置他们的环境,这违背了与 IDE 无关的方法。
在同一个项目团队中使用多个工具集时有许多注意事项。例如,我的团队有使用 IntelliJ 的 Java 开发人员和使用 eclipse 的大多数前端(JSP/CSS/HTML)开发人员。我们正在将 Eclipse 用户迁移到 IntelliJ,因为我们开发的一些 IntelliJ 插件为我们的环境提供了扩展支持。我们不会为多个平台开发插件,因此我们将全面标准化 IntelliJ。
具体文件方面,我可以和 IntelliJ 谈谈。我们已经签入了 .ipr 文件和 .iml 文件。不要签入 .iws 文件。如果您还有 Eclipse 用户,请将您的 IntelliJ 项目配置为在 .classpath 文件中读取/存储依赖信息并将其提交到您的 VCS。
我们有意支持来自同一个 SVN 存储库的多个 IDE。我们的想法是,我们希望确保,如果有新人加入团队或有人必须开始在新机器上工作,我们希望他们能够检查代码库,将其导入 IDE 并立即开始工作-能配置。
这在开发人员端意味着他们不应该将更改提交到 IDE 文件。其他所有内容(例如,src、test、lib 等)成为我们通常每天更新和提交的集合。
附带的好处是我们已经完全消除了这里的 IDE 战争:Netbeans 和 Eclipse 人生活在完美的和谐中(斜眼看着 IntelliJ 人,但是嘿...... ;-)。
有关此主题的更多评论和答案,请参阅此问题(如何处理不同的 Java IDE 和 svn?)
我们重命名 IDE 文件以使用额外的扩展名 .deletethis 或类似名称进行签入。当一个新人签出项目时,他们只需剥离额外的扩展名就可以了。这样,当人们调整他们的环境时,我们可以避免与项目文件的源代码控制冲突。而且您不必担心教育新开发人员不要签入这些文件。
通常,我会认为这是一个坏主意。我不确定这是一种什么样的环境(也许是开源的?),但支持多个 IDE 真的很糟糕。如果这是不可避免的,我会推荐的一件事是在 ant 脚本中标准化您的构建。如果您有大量依赖项,这可能是在所有平台上获得可预测构建的最简单方法。
如果其中一个 IDE 恰好是 RAD(基于 eclipse),则存在一个名为 .settings 的完整文件夹,您不希望将其包含在 SCM 中。