Aplicación modular de Java en el repository de GIT

Estoy trabajando en una "aplicación Java modular", tiene alnetworkingedor de 60 modules independientes, todos obviamente "edificables" por sí mismos.

Estoy tratando de entender cuál puede ser el mejor enfoque para estructurar este tipo de aplicación bajo GIT.

Voy a explicar mejor a mí mismo:

He estado trabajando varios años con SVN y sería muy fácil para mí estructurar un proyecto como este bajo una herramienta de control de versiones centralizada como SVN, aunque no estoy seguro de las mejores prácticas y pros / contras de GIT.

Con SVN:

Importaría todo el proyecto en el mismo repository

Consideraría dos enfoques diferentes, con consecuencias similares, por ejemplo:

mod_A |___trunk |___branches | |___branch_A | |___tags mod_B |___trunk |___branches | |___branch_A | |___branch_B | |___tags 

O

  trunk |___mod_a |___mod_b |___mod_c branches |___branch_A | |___mod_a |___branch_B |___mod_a |___mod_b 

Con ambos enfoques sería muy fácil para mí get información como, cuáles son los modules ramificados para una característica particular, y ver la aplicación desde los modules prospectivos, pero también desde las twigs prospectivas.

Además, con ambas estructuras podría ramificar fácilmente solo algunos de los modules sin tener que ramificarlos todos en cualquier momento.

Con GIT:

Por el momento, la aplicación modular con la que estoy trabajando está estructurada con un solo repository independiente para cualquier module, en mi opinión esta estructura, incluso si trae algunas ventajas, también tiene un gran problema.

De hecho, me parece difícil tener una visión completa y clara de la aplicación, porque tengo que conectarme a cada repository y verificar las twigs para comprender qué modules están involucrados en una twig en particular, así que si tengo que administrar una versión ramificada de mi aplicación, que por ejemplo involucra solo 7 modules para ser ramificados en una twig particular BUG_FIXING o FEATURE y no toda la aplicación, no tendría forma de get esta información a través de GIT, y debería administrar esta información en una versión personalizada path.

Entonces, incluso si la aplicación se hubiera configurado dentro del mismo repository, no habría podido decidir ramificar solo un subset de modules porque "Git opera en todo el repository, no en directorys individuales".

¿Pueden aclarar cómo puede ser el mejor enfoque a seguir con una aplicación modular? ¿Pueden los submodules de GIT ser una solución? ¿Hay algún otro enfoque que no estoy considerando, o estoy pasando de suposiciones erróneas?

¡Muchas gracias!

En primer lugar, debe administrar la aplicación Java del module en un repository git como lo hizo en un repository SVN, ya que todos los modules funcionan para el mismo proyecto.

Para la estructura de modules de bifurcación para su aplicación, sugeriré que administre cada module en twigs separadas ( modX ) y que administre todo su proyecto en la twig master .

El flujo de trabajo puede ser:

  • Administre los files de nivel de proyecto en la twig master . la estructura para la twig principal como:

     Root (master branch) |___... (project level files) 
  • modA twigs del module (como la twig modB , la twig modC y la twig modC ) desde el maestro. Eliminó los files de nivel de proyecto y agregó files para el module en la carpeta mod_X .

    Tal como para la twig modA, la estructura es:

     Root (modA branch) |___mod_A (folder) |___... (module A level files) 
  • Cuando haya terminado de trabajar para el module X, modX twig modX en la twig master .

  • Después de que todos los modules hayan finalizado su trabajo (y se hayan fusionado en el master ), la estructura del file para la twig master debería ser:

     Root (master branch) |___... (project level files) |___mod_A (folder) |___... (module A level files) |___mod_B (folder) |___... (module B level files) |___mod_C (folder) |___... (module C level files) 
  • Si actualiza el module X en la twig modX , entonces fusione la twig modX nuevo en la twig master para asegurarse de que la aplicación se actualice.

  • Para mantener files de nivel de proyecto (agregador de aplicaciones), también puede desarrollar / probar / corregir en twigs de develop , feature y hotfix :

    1. twig master como la versión de producción para su aplicación Java.
    2. develop twig de develop (twig larga de vida, que debe pagarse desde la twig master ) se usa para todos los desarrolladores que trabajan en ella. Cuando la aplicación modificada se comstack correctamente (verificada), puede fusionar el develop twig en el master .
    3. feature twigs feature son twigs vivas cortas. Si necesita desarrollar nuevas funciones para su aplicación, puede verificar una twig de características desde la twig de develop . Y luego, la function finaliza, fusiona la twig de características en la twig de develop para verificar tu código.
    4. hotfix twigs de hotfix también son twigs vivas cortas. Puede corregir errores en las twigs, cuando se solucionan los errores, fusione la twig de revisión en la twig de develop .

    Y hay un model de bifurcación exitoso que puede recomendar para administrar los files de nivel de proyecto (agregador de aplicaciones).

Aparte: no use twigs para administrar diferentes modules. Las twigs deben ser efímeras y, en última instancia, fusionadas a maestra cuando estén lists para su lanzamiento.


Si los modules "cambian / sueltan" juntos, podría inclinarse por mantenerlos en un repository. Aunque el hecho de que cada module tuviera sus propias carpetas de troncales / twigs en SVN parece indicar que cambian por separado.

Si está utilizando maven con su aplicación java, se puede configurar en un repository como un proyecto de varios modules.

Si va con repositorys separados, puede nombrar sus sucursales de manera similar (agregue un número de ticket o feature/ticket-123-more-cow-bells similares feature/ticket-123-more-cow-bells ) para que sepa que una determinada function afecta a múltiples modules / repos.

Si va con repos por module, puede usar los submodules de Git para volver a unirlos, pero eso es más bien una solución alternativa.

Quizás también leer sobre algunas estrategias de ramificación de git diferentes lo ayude a comprender cómo 'git piensa' sobre las sucursales.