Christopher hizo un muy buen trabajo al enumerar las desventajas de un modelo de un proyecto por repositorio. Me gustaría discutir algunas de las razones por las que podría considerar un enfoque de múltiples repositorios. En muchos entornos en los que he trabajado, un enfoque de múltiples repositorios ha sido una solución razonable, pero la decisión de cuántos repositorios tener, y dónde hacer los recortes no siempre ha sido fácil.
En mi posición actual, migré un repositorio CVS de repositorio único con más de diez años de historia a varios repositorios de git. Desde esa decisión inicial, el número de repositorios ha crecido (a través de las acciones de otros equipos), hasta el punto donde sospecho que tenemos más de lo óptimo. Algunos recién contratados han sugerido fusionar los repositorios, pero he argumentado en contra. El proyecto Wayland tiene una experiencia similar. En una charla que vi recientemente, tenían, en un momento dado, más de 200 repositorios de git, por lo que el líder se disculpó. En cuanto a su sitio web , veo que ahora están en 5, lo que parece razonable. Es importante observar que unir y dividir repositorios es una tarea manejable, y está bien experimentar (dentro de lo razonable).
Entonces, ¿cuándo podrías querer múltiples repositorios?
- Un único repositorio sería demasiado grande para ser eficiente.
- Sus repositorios están débilmente acoplados o desacoplados.
- Un desarrollador normalmente solo necesita uno o un pequeño subconjunto de tus repositorios para desarrollar.
- Por lo general, desea desarrollar los repositorios de forma independiente y solo necesita sincronizarlos ocasionalmente.
- Quieres fomentar una mayor modularidad.
- Los diferentes equipos trabajan en diferentes repositorios.
Los puntos 2 y 3 solo son significativos si el punto 1 se mantiene. Al dividir nuestros repositorios, reduje significativamente los retrasos sufridos por nuestros colegas externos, reduje el consumo de disco y mejoré el tráfico de red.
4 y 5 son más sutiles. Cuando se dividen los repositorios de, por ejemplo, un cliente y un servidor, esto hace que sea más costoso coordinar los cambios entre el cliente y el código del servidor. Esto puede ser positivo, ya que fomenta una interfaz desacoplada entre los dos.
Incluso con las desventajas de los proyectos de múltiples repositorios, se realiza una gran cantidad de trabajo respetable de esta manera: Wayland y el impulso vienen a la mente. No creo que el consenso con respecto a las mejores prácticas haya evolucionado todavía, y se requiere algo de juicio. Las herramientas para trabajar con múltiples repositorios (git-subárbol, git-submódulo y otros) todavía se están desarrollando y experimentando. Mi consejo es experimentar y ser pragmático.