Múltiples repositorios Git para cada proyecto Eclipse o un repositorio Git

Utilizo 1 repositorio por proyecto.

Algunos razonamientos:

• Cuando descubres que has estropeado algo después de varias confirmaciones, es mucho más fácil arreglarlo cuando se trata de un solo proyecto. Solo piensa, hiciste commits en otros dos proyectos y ahora necesitas arreglar el commit que hiciste en el 3er proyecto.

• Como dijo Fedir, su historial y registro es mucho más limpio. Solo muestra las confirmaciones para ese proyecto.

• Funciona mejor con el desarrollo flujo de trabajo que tengo. Tengo una rama maestra para producción, desarrollo de rama para, bueno, desarrollo, y creo ramas para implementar características (puede leer más sobre esto aquí: http://blog.avirtualhome.com/development-workflow-using-git/)

• Cuando trabajas en equipo y "compartes" el repositorio de git, ¿los miembros del equipo realmente necesitan todos los demás proyectos también?

Solo unos pocos pensamientos, pero a lo que se reduce: Hacer lo que funciona para usted.

Tengo varios proyectos (proyectos Eclipse) y he probado diferentes cosas para averiguar qué funcionó mejor en términos de desarrollo diario real. Esto es lo que encontré y creo que la mayoría de la gente encontraría lo mismo si mantuvieran un registro de los resultados y los analizaran objetivamente.

En resumen, la aplicación de las siguientes reglas dará los mejores resultados:

1. Crear un repositorio separado para cada grupo de proyecto.
2. Cada grupo de proyecto consiste en un grupo de proyectos que están estrechamente conectados entre sí, que deben administrarse juntos y que no pueden disociarse fácilmente entre sí.
3. Un grupo de proyecto puede contener un solo proyecto.
4. Un grupo de proyecto que contiene varios proyectos debe ser examinado para ver si algunos de sus proyectos se pueden desacoplar entre sí para que pueda dividirse en grupos de proyecto más pequeños que todavía contienen proyectos que están estrechamente conectados entre sí, que deben administrarse juntos y eso no se puede desacoplar fácilmente entre sí.

Las siguientes pautas explican este proceso para determinar qué proyectos poner en el mismo repositorio con más detalle:

1. Si un proyecto no está estrechamente relacionado con ningún otro proyecto (por ejemplo, el proyecto se puede abrir sin que se abran otros proyectos y ningún otro proyecto depende de que el proyecto se abra cuando se abran), entonces definitivamente debe colocarlo en su propio repositorio para el razones explicadas en las respuestas anteriores.

2. Si un proyecto depende de otros proyectos u otros proyectos dependen del proyecto, entonces se reduce a exactamente qué tan conectados están entre sí, qué tan bien se pueden empaquetar juntos y qué tan fácilmente se pueden desacoplar entre sí.

A) Por ejemplo, un proyecto de prueba que contiene clases de prueba junit para probar las clases de un proyecto principal es un caso donde los dos proyectos están muy conectados entre sí, se pueden empaquetar fácilmente juntos y no se pueden desacoplar fácilmente entre sí. Estos proyectos deben colocarse en el mismo repositorio por las razones que se explican en la parte C infra.

B) En un caso en el que un proyecto depende de otro proyecto para proporcionar algún tipo de recursos compartidos, realmente se reduce a lo bien que se pueden administrar juntos y lo fácil que se pueden desacoplar entre sí. Por ejemplo, si el proyecto con los recursos compartidos es en el que se basan muchos proyectos, entonces debería colocarse en su propio repositorio porque los otros proyectos no relacionados se ven afectados por los cambios en el proyecto de código fuente compartido. En un caso como este, el proyecto de recursos compartidos debe estar desacoplado de los proyectos dependientes en lugar de estar conectado directamente a los proyectos dependientes. (Por ejemplo, sería mejor crear archivos de archivo versionados [archivos Jar con un nombre como "ProjectName".1.0.1.0.jar, por ejemplo] e incluir una copia de los cada proyecto en lugar de compartir los recursos mediante la vinculación de los proyectos juntos.)

C) Si los múltiples proyectos están conectados, se pueden administrar fácilmente juntos pero no se pueden desacoplar fácilmente entre sí, entonces depende de cuán estrechamente conectados estén entre sí.

I) Si los proyectos se colocan en un repositorio, entonces los proyectos se mantendrán sincronizados entre sí en el repositorio cada vez que haya una confirmación, lo que puede ser un ahorro real si los proyectos están estrechamente conectados. Sin embargo, esto también crea los problemas señalados en las respuestas anteriores.

II) Si los proyectos se colocan en repositorios separados, entonces tendrá que tener cuidado de mantener las confirmaciones sincronizadas entre sí y asegúrese de incluir algún tipo de mecanismo para indicar qué confirmaciones pertenecen al mismo punto de sincronización en los proyectos (Tal vez algo como incluir el mismo número de punto de sincronización en los comentarios para la confirmación de cada proyecto cuando un grupo de confirmaciones se hace a través de los proyectos.)

III) por Lo que en casos como este, casi siempre es mejor poner estos proyectos en un único repositorio para reducir la sobrecarga de esfuerzo humano en la sincronización de los comete y para evitar el error humano debe el cometa necesidad de realizarse. La única vez que podría ser mejor colocarlos en repositorios separados es cuando solo uno de los proyectos se cambia regularmente y los otros proyectos conectados rara vez se cambian.

Creo que esta pregunta está relacionada con una que respondí aquí. básicamente, Git por su naturaleza soporta una estructura granular muy fina cuando se trata de proyectos / repositorios. He leído y me han enseñado que 1 repositorio por proyecto es casi siempre la mejor práctica. Usted pierde casi nada al mantener los proyectos separados y ganar mucho como otros han estado describiendo.

Probablemente, será más eficiente trabajar con él si va a crear varios repositorios git.

Si va a crear una rama, solo se ramificarán los archivos del proyecto, y no todos los proyectos. Pequeño proyecto será más rápido para analizar, para comprometerse. Las operaciones llevarán menos tiempo.

El registro será más claro también, podría hacer una configuración más granulada si tiene varios repositorios git.