¿Deben ignorarse los files específicos de Eclipse en un VCS, si se usa Maven?

Sé por qué no enviar files específicos de Eclipse / IDE a un VCS como Git (que en realidad estoy usando). Esa es una de las razones por las que estoy usando Maven y teniendo que generar estos files para usted y no tenerlos bajo control de versiones.

Pero me pregunto si estos files deberían ignorarse en .gitignore, que está bajo el control de VCS / Git:

.classpath .project .settings/ target/ 

¿Esta bien?

¿Cuáles son los pros y los contras dado que el file .gitignore en sí mismo se convierte en un tipo de IDE específico ya que los files ignorados son IDE-spefific? ¿Alguna mejor práctica?

Con el equipo en el que he trabajado, la regla general ha sido que no ingreses nada que Maven genere u obtenga. Como el pom.xml contiene todo lo que necesita para crear los files .project, .classpath y .settings, no los registramos.

Mi .gitignore siempre contiene .classpath, .settings, .project y target para los proyectos de Maven.

Editar: Como mencioné en mi comentario a continuación, aquí hay otra sugerencia: si realmente desea evitar tener inputs específicas de Maven o IDE en su .gitignore, intente escribir su .gitignore para que solo enumere lo que desea registrar .

 * !stuffIDoWantToCheckIn 

Obtengo mi información del siguiente artículo: https://help.github.com/articles/ignoring-files

Eso sugiere que puede crear un file global de gitignore (sugiera bajo ~ / .gitignore_global) que contenga .project, etc. Como el file está fuera del repository, no se mostrará …

Lo registra como un file global de ignorar con el siguiente command:

 git config --global core.excludesfile ~/.gitignore_global 

Alternativamente, puede crear inputs por gitignore sin seguimiento por reposition en el file .git / info / exlude

Estoy de acuerdo en no poner los files IDE bajo control de versiones, ocasionalmente esto ocasiona todo tipo de problemas, y como mencionaste usando maven, esto es innecesario ya que cualquier desarrollador puede simplemente importar el proyecto desde el POM y ponerse en marcha

Si estos files no se colocan en el .gitignore, se pueden registrar fácilmente por error

además, no encuentro que enlistrlos en .gitignore lo hace IDE específico, puede listr files de proyecto de eclipse, IntelliJ IDEA y Netbeans, todos en el mismo .gitignore si los miembros de su equipo usan una combinación de IDEs diferentes. Con el time, puede acumular una plantilla .gitignore que ignora los files del proyecto de todos los IDEs utilizados en su equipo (s) para usar cada vez que cree un nuevo repository

Si está totalmente en contra de poner estos en el proyecto .gitignore, puede ponerlos en el .gitignore de los usuarios, pero eso en mi opinión es un poco más flojo ya que depende de que las máquinas de desarrollo individuales estén configuradas correctamente, y también estas deben mantenerse. para mantenerse sincronizado con nuevas adiciones

Editar: Actualmente tengo un .hgignore equivalente, la misma syntax de concepto diferente, lo convertí a git como un ejemplo de un file .gitignore

 /target/ /bin/ /build/ /.classpath /.project /.settings/ /.checkstyle /atlassian-ide-plugin.xml /.idea/ /*.iml /*.ipr /*.iws *.orig *.swp *~ 

¡usualmente .project y .settings / deberían ser versionados e ignorados!

.classpath y target no se deben versionar, sino ignorar.

Este es un primer arranque inicial en la práctica de pago.

es decir

  • Le dijo a alguien que use cuatro espacios como pestaña, esta información se almacena en .settings / xxx
  • pero no da ninguna restricción donde tienen que instalar su tomcat / jdk (almacenado en .classpath)

¿Okay?