¿Tiene sentido almacenar files IDE específicos como parte del código fuente?

Estamos comenzando un nuevo proyecto y nos gustaría saber si necesitamos almacenar files específicos de ECIPSE IDE (.settings, .project, .classpath) como parte de nuestro tree fuente. ¿Deberíamos pedirle a cada desarrollador que cree estos files mediante el command "mvn eclipse: eclipse" o deberíamos registrarlo para ellos? ¿Cuál sería la mejor práctica aquí?

Los almacenamos en Git, porque queremos que cada desarrollador trabaje con el mismo entorno. Si permite que cada desarrollador cree su propia configuration de proyecto y no tenga ningún otro control sobre la configuration que utiliza, puede terminar con una configuration diferente que conduzca a fallas.

La principal ventaja de mantener los files de configuration de IDE / entorno en control de fuente es estandarizar su entorno de desarrollo.

Tener un ambiente estandarizado le confiere varias ventajas:

  • Su entorno y set de herramientas se vuelven familiares para todos.
  • Los problemas comunes son bien conocidos y documentados.
  • Curva de aprendizaje fácil para nuevos desarrolladores (quizás incluso un 'documento de configuration').

Por supuesto, también hay desventajas:

  • Al obligar a los desarrolladores a codificar de cierta manera, es posible que disminuya su productividad. Por ejemplo, tengo más experiencia con Eclipse. Claro, podría usar NetBeans pero no sería tan eficiente.
  • Los desarrolladores pueden estar less expuestos a nuevas herramientas / ideas / tecnología. Por ejemplo, uso Eclipse principalmente, pero cambio a NetBeans para crear perfiles y a IntelliJ para editar la configuration de EJB.

Una de las mejores políticas que he visto es "Oye, somos una tienda de Windows / Eclipse. Puedes usar [inserta tu OS / Herramienta / Técnica favorita aquí] si quieres, pero debes ser lo suficientemente competente como para solucionar tus propios problemas ".

Esta perspectiva parece get lo mejor de ambos mundos; la mayoría de los desarrolladores se apegará al estándar, documentará errores, producirá documentation de configuration, etc. Sin embargo, un pequeño grupo de desarrolladores (por lo general mayores) saldrán y harán lo suyo, descubrirán nuevas herramientas geniales y tal vez las incorporen en su entorno estandarizado. .