¿Qué debo incluir en mi repositorio de proyectos IDE?

10

Quiero agregar un proyecto que en este caso se crea en Netbeans, pero esta pregunta es general para la mayoría de los IDE. Es simplemente, qué debo incluir en mi repositorio. Por ejemplo, Netbeans crea una carpeta nbproject, eclipse crea una carpeta .settings, etc. Si debo incluirlos en mi repositorio, cuáles son las ventajas / desventajas de incluir o no la configuración específica del proyecto.

En este caso es un proyecto personal, así que no imagino que otras personas comenzarán a trabajar en él, pero sería bueno agregar la mínima configuración del proyecto para que el proyecto en sí sea fácil de comenzar a trabajar en diferentes máquinas.

programming-practices git project maintainability Daniel Figueroa
fuente
Considere herramientas como maven con su complemento eclipse (u otro ide) para configurar el entorno adecuado en lugar de incluir el suyo propio.
@MichaelT Lo siento mucho pero realmente no te sigo, ¿te importaría ampliar eso?
Daniel Figueroa
Usar una herramienta de compilación y tener la herramienta de compilación configurando el entorno para la ide le permite estar seguro de que la configuración es la misma sin importar la plataforma (o ide). Incluso los desarrolladores en solitario tienen múltiples entornos (ide vs build). Esto simplifica la pregunta a una que se responde "no verifique nada que sea específico para su entorno porque son código generado". - el mismo racional que no verifica en las clases .java generadas por jaxb, sino más bien las instrucciones (build.xml o .pom file) sobre cómo construirlas.
Si es "original" se debe hacer una copia de seguridad. Si cambia y esos necesitan seguimiento y es original, debe ser controlado por revisión. El truco: cómo estructurar su repositorio para que su fuente siga siendo su fuente, mientras que las configuraciones de la cadena de herramientas no contaminan el repositorio de fuente. Lo mismo se aplica a recursos como imágenes, sonido y video ...
mattnz

Respuestas:

4

Realmente depende de qué datos sean y debe decidirse caso por caso, tal vez incluso para archivos individuales. Echa un vistazo a los contenidos de esos archivos. Más a menudo que no se puede decir lo que significan. Cosas como la posición y el tamaño de las ventanas del IDE es algo que no desea en el control de origen.

Pero algunos de los archivos del proyecto IDE son metadatos vitales del proyecto. No conozco bien Netbeans, pero para eclipse, el archivo .project le dice al IDE cuál es el nombre del proyecto, que es un proyecto web Java, etc. y el archivo .classpath contiene información sobre las carpetas y bibliotecas de origen. Algunos archivos en el directorio .settings pueden ser igualmente importantes, por ejemplo, org.eclipse.core.resources.prefs contiene información sobre qué codificación se debe usar para qué archivos.

Como metadatos del proyecto, este material merece ser versionado en el control de código fuente.

Algunos IDE pueden importar metadatos del proyecto desde otros IDE. Sería aún mejor tenerlo en una forma que no esté vinculada a un IDE específico.

Para Java, existe tal cosa: Maven . Impone convenciones fuertes en la estructura del proyecto y le permite especificar metadatos del proyecto (como las dependencias de la biblioteca) en un punto (un archivo llamado pom.xml que está en el directorio principal del proyecto y, por supuesto, en el control de origen). Hay complementos que luego crean archivos de proyecto IDE a partir de la configuración de Maven, y otros que pueden automatizar el proceso de construcción del proyecto o hacer casi cualquier cosa. A veces parece que hace que las cosas sean innecesariamente complejas y lleva algún tiempo aprender, pero los beneficios generalmente valen la pena.

Michael Borgwardt
fuente
1
si no me equivoco, Maven es independiente del IDE. Si es así, entonces, dado que contiene configuraciones / metadatos de proyectos, por lo tanto, definitivamente debe incluir en el repositorio, pero no los "archivos de proyecto IDE" a los que OP parece referirse específicamente.
Sangrado dedos
@ hus787: mi punto es que estos metadatos son lo suficientemente importantes como para estar en el repositorio, y si bien es genial cuando lo tienes en forma independiente del IDE, cuando ese no es el caso, aún es mejor tenerlo que no hacerlo. tenerlo.
Michael Borgwardt
2

Esto realmente depende de qué tipo de información le gustaría tener en el repositorio. Si desea todo hasta los archivos que tenía abiertos y editando en el momento de la confirmación, y usted es el único que usa el repositorio, continúe y confirme todo, pero sepa que puede que no funcione en otra máquina .

Si desea poder compartir su código con otras personas que podrían no estar usando el mismo IDE, simplemente confirme el código sin ninguna implementación específica del proyecto.

Si sabe que todos usan el mismo IDE, entonces probablemente pueda incluir cualquier cosa que no sea específica de la computadora, es decir, cualquier archivo / carpeta de configuración solo para el IDE en sí, de esa manera ya pueden tener la capacidad de importar el proyecto como IDE lo espera.

Ampt
fuente
2

No se deben incluir los artefactos que ayudan a su desarrollo y que no son útiles para la compilación / lanzamiento o el proyecto en sí . El repositorio debe estar limpio y ordenado, y solo debe tener aquellas cosas que sean relevantes para el proyecto, no su entorno . El repositorio debe ser incógnito de sus hábitos. Y en segundo lugar, te molestará innecesariamente cuando hagas algo parecido a ... pero bueno, nunca hice ningún cambio ... ahh ignora eso.git status

Permítanme dar un ejemplo más práctico (lo usaré gitaquí como herramienta):

Nunca desearía que un submódulo (recursivo) dentro de su repositorio principal tenga un material específico de IDE (también podría interferir con el entorno principal del proyecto) porque lo único que le importa es el código escrito por otra persona (o usted) y es de uso dentro del proyecto actual. No es el entorno en el que se desarrolló. Probablemente tampoco quieras hacerle eso a otra persona.

Para poder usar su configuración en una máquina diferente, sugiero cavar dentro de su IDE y ver qué soporte brinda para tales cosas. Emacs tiene inity servidor Emacs también. O puede hacer su macro o script personalizado ( .sh) que realiza la configuración automáticamente.

Dedos sangrantes
fuente
-1: no estoy de acuerdo por completo. Esta puede ser información muy importante y útil, y su repositorio definitivamente debe incluir dicha información.
Michael Borgwardt
@MichaelBorgwardt, ¿qué pasa si OP planea cambiar a otro IDE? ¿Cómo se entenderán esas configuraciones específicas del IDE del proyecto en la otra? Un ejemplo sería muy apreciado.
Sangrado dedos
Algunos IDE pueden importar metadatos del proyecto desde otros IDE. Incluso si no pueden, estos archivos son usualmente legibles para los humanos y tenerlos es mejor que no tenerlos.
Michael Borgwardt
¿Y qué sucede si cubres completamente tu espacio de trabajo (me sucedió a mí recientemente) y no puedes revertir los cambios configurando manualmente las cosas como creías que eran antes? Probablemente me ahorré horas porque el espacio de trabajo fue registrado. Sin mencionar que en algunos IDE, el espacio de trabajo incluirá elementos como plantillas de código que sería un gran problema tener que configurar manualmente cada vez.
Amy Blankenship
@AmyBlankenship, ese es mi punto, es su espacio de trabajo, ¿cómo puede estar seguro de que no interfiere con el de los demás? puede usar mercurial para el espacio de trabajo específico de su proyecto personal VC y git para el proyecto VC. Acerca de las plantillas de código, creo que su IDE no es lo suficientemente maduro (o aún no se ha explorado correctamente) y si dice que las plantillas son específicas del proyecto, supongo que debería estar buscando patrones en su código.
Sangrado dedos
1

Si se trata de un proyecto personal, digo almacenar la configuración en el control de fuente. Personalmente, nada mata más mi motivación para un proyecto que configurar un entorno de desarrollo nuevamente.

Cuando hay más personas involucradas, no pongo estas cosas en el control de la fuente. En mi equipo, tenemos una combinación de IntelliJ, Sublime Text y Eclipse en uso. Los archivos IDE simplemente agregan desorden, y resultan en la recepción de confirmaciones a esos archivos de otras personas para un IDE que no usa.

Además, su proyecto no debería depender del IDE de todos modos. Un servidor de compilación no iniciará Eclipse para compilar su producto, por lo que ya no debería tener IDE. Un punto más menor: elimina la organización personal dentro del proyecto. Por ejemplo, en IntelliJ me gusta usar muchos módulos dentro de nuestro proyecto. Nadie más que use IntelliJ se preocupa por esto porque no almacenamos los archivos .iml (módulo).

Si su equipo está usando el mismo IDE, entonces es mejor, pero alguien comete una entrada de .classpath incorrecta porque usaron una ruta absoluta. Ahora todos los que usan el IDE se preocupan por eso.

Claro, la desventaja es que hay más configuración cuando alguien revisa el proyecto. Creo que vale la pena. Usamos Ivy para la gestión de dependencias y tenemos información sobre la configuración, las dependencias, etc. A pesar de este costo inicial, creo que vale la pena mantener la configuración de IDE fuera del control de la fuente.

Críptico
fuente