¿Maneja múltiples componentes en uno o varios repositorys Git?

Tengo un gran proyecto basado en .NET con más de 20 soluciones diferentes que representan diferentes modules en un sistema más grande. Dentro de cada solución hay una cantidad de proyectos.

Actualmente manejamos todas las soluciones en un solo repository de Git, ya que pertenecen de alguna manera y hasta ahora nos ha funcionado bien. Ahora, sin embargo, nos gusta comenzar a usar un server de CI para, por ejemplo, build y probar modificaciones. Sin embargo, aquí es donde comienza a ponerse peludo. No puedo hacer que el server de CI cree la solución completa, sino solo para crear el componente que se modificó. En SVN podríamos lograr esto con un repository y limitar las diferentes configuraciones del server de CI para escuchar diferentes routes, por lo que, por ejemplo, "src / ModuleA" era una compilation y configuration y "src / ModuleB" era otra.

¿Cuáles son mis opciones en Git y qué se consideraría una mejor práctica? ¿Cuáles serían sus pros y sus contras? Me encantaría que me señalaran una solución de código abierto más grande con una configuration similar como parte de la respuesta.

  1. ¿Supongo que podría tener cada module en su propio repository? Pero ese es un problema cuando se trata de alojamiento en GitHub y demás, y cuando cobran por repo … ¿Sería esta la mejor opción?
  2. ¿Funcionarán los submodules de Git? ¿Es este el uso correcto para los submodules?
  3. ¿Conoce alguna otra opción en un producto de CI que ayude con este escenario de alguna manera?

¿Supongo que podría tener cada module en su propio repository? Pero ese es un problema cuando se trata de alojamiento en GitHub y demás, y cuando cobran por repo … ¿Sería esta la mejor opción?

Esa sigue siendo la mejor opción, a less que esos modules sean demasiado interdependientes, lo que significa un obstáculo adicional a la hora de gestionar la bifurcación (porque debe recordar ramificar todos o la mayoría de los modules al mismo time, lo mismo para fusionarse de nuevo)

Si la carga es un problema, recuerde que puede tener una organización similar en repositorys BitBucket (que ofrece repositorys privados gratuitos , aunque para un equipo pequeño )

Una vez que tenga cada module en su propio git repo, puede combinarlos con un subtree o con submodules, como explico en " Combinar un proyecto base que está creciendo en proyectos secundarios en el repository de git, excepto en los submodules de git o los methods de fusión de subtreees ".
git slave también puede ser una alternativa más simple.

Mientras que el submodule git y el subtree git son soluciones buenas (pero diferentes) para la gestión de subcomponentes, tienen algunas desventajas

submodule de git:

  • terminas con múltiples repositorys.
  • tienes que administrar cada repository por separado.
  • la interfaz de usuario es a veces francamente confusa .

subtree de git (no he trabajado demasiado, por lo que mis objeciones pueden ser infundadas):

  • usted tiene un solo historial para todo el proyecto. Si bien esto funciona bien, y siempre hay una manera de separar el historial, no hay una manera fácil de componer versiones arbitrarias de componentes en un sistema.

He ideado un método llamado componentes git que funciona en un repository único (como el subtree de git) y le da una flexibilidad de historial de componentes independientes (como el submodule de git).

El método se basa en el process de pago: checkout <branch_name> -- . (tenga en count el punto final).

El método utiliza una simple secuencia de commands bash similar a un manifiesto e impone algunas convenciones de nomenclatura para facilitar la administración de componentes.

Puede encontrar una descripción completa del método y la implementación de un juguete aquí:

https://github.com/picrin/git-components

editar

Como lo sugirió VonC , he intentado combinar esto con una nueva característica de git disponible con el git 2.5 git worktree . Aunque 2.5 aún no está disponible (a less que vengas aquí en el futuro), el máster maestro tiene la function y parece funcionar bien.

La manera en que sugiero usar git worktree con componentes git es revisando el tree de trabajo principal para dominar, y creando un tree de trabajo para cada componente y cada versión del sistema (clienteA, clienteB, etc.). De esta forma puede trabajar en cada componente simultáneamente sin tener que esconder su trabajo en el componente 1 cada vez que alguien lo interrumpe para hacer una revisión rápida en el componente 2.