¿Elegir entre proyectos únicos o múltiples en un repositorio de git?

Hay tres desventajas principales en one project per repository , la forma en que lo describiste anteriormente. Esto es menos cierto si se trata de proyectos realmente distintos, pero los sonidos de uno a otro requieren cambios a otro, lo que realmente puede exagerar estos problemas:

1. Es más difícil descubrir cuándo se introdujeron errores. Las herramientas como git bisect se vuelven mucho más difíciles de usar cuando fraccionas tu repositorio en sub repositorios. Es posible, no es tan fácil, lo que significa la búsqueda de errores en tiempos de crisis es mucho más difícil.
2. El seguimiento de todo el historial de una función es mucho más difícil. Los comandos que atraviesan el historial como git log simplemente no generan el historial de manera tan significativa con estructuras de repositorio fracturadas. Puede obtener algunos resultados útiles con submódulos o subárboles, oa través de otros métodos de secuencias de comandos, pero no es lo mismo que escribir tig --grep=<caseID> o git log --grep=<caseID> y escanea todos los compromisos que te interesan. Su historial se vuelve más difícil de entender, lo que lo hace menos útil cuando realmente lo necesita.
3. Los nuevos desarrolladores pasan más tiempo aprendiendo la estructura del Control de versión antes de que puedan comenzar a codificar. Cada nuevo trabajo requiere procedimientos de recuperación, pero fracturar un repositorio de proyecto significa que tienen que elegir la estructura de VC además de la arquitectura del código. . En mi experiencia, esto es particularmente difícil para los desarrolladores nuevos de git que vienen de tiendas más tradicionales y centralizadas que usan un solo repositorio.

Al final, es un cálculo de costo de oportunidad. En un antiguo empleador, tuvimos nuestra aplicación principal dividida en 35 sub-repositorios diferentes. Además de eso, utilizamos un conjunto complicado de scripts para buscar en el historial, asegurarnos de que el estado (es decir, las ramas de producción frente al desarrollo) fuera el mismo en todas ellas, e implementarlas individualmente o en masa.

Era demasiado; demasiado para nosotros al menos La sobrecarga de administración hizo que nuestras características fueran menos ágiles, hizo que las implementaciones fueran mucho más difíciles, que la enseñanza de nuevos desarrolladores tomara demasiado tiempo, y al final, apenas pudimos recordar por qué fracturamos el repositorio en primer lugar. Un hermoso día de primavera, gasté $ 10 por una tarde de tiempo de cómputo de grupo en EC2. Volví a juntar los repositorios con un par de docenas de git filter-branch llamadas. Nunca miramos hacia atrás.

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?

1. Un único repositorio sería demasiado grande para ser eficiente.
2. Sus repositorios están débilmente acoplados o desacoplados.
3. Un desarrollador normalmente solo necesita uno o un pequeño subconjunto de tus repositorios para desarrollar.
4. Por lo general, desea desarrollar los repositorios de forma independiente y solo necesita sincronizarlos ocasionalmente.
5. Quieres fomentar una mayor modularidad.
6. 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.

Como usamos GitHub, en realidad tenemos varios proyectos en un repositorio, pero nos aseguramos de que esos proyectos / módulos están debidamente modularizados (usamos las convenciones de -api y -core + Maven + estática y verificación de tiempo de ejecución y incluso podría ir a OSGi un día para arrancar).

¿En qué ahorra? Bueno, no tenemos que emitir múltiples solicitudes de extracción si estamos cambiando algo pequeño en múltiples proyectos. Los problemas y Wiki se mantienen centralizados, etc.

Todavía tratamos cada módulo / proyecto como un proyecto independiente adecuado y los construimos e integramos por separado en nuestro servidor de CI, etc.

Para mí, la principal diferencia en el uso de uno o más de un repositorio son las respuestas a las siguientes preguntas:

• ¿Las partes múltiples desarrolladas por el mismo equipo tienen el mismo ciclo de lanzamiento, el mismo cliente? Entonces hay menos razones para dividir el repositorio.
• ¿Son las partes múltiples altamente dependientes unas de otras? Por lo tanto, dividir el modelo, el controlador y la interfaz de usuario (incluso cuando son partes diferentes) no es muy sensible, debido a la alta dependencia entre ellos. Pero si 2 partes solo tienen una pequeña dependencia, que se implementa mediante una interfaz estable que solo se cambia cada pocos años, sería conveniente dividir las 2 partes en 2 repositorios.

A modo de ejemplo, tengo una pequeña aplicación (solo cliente), que verifica la "calidad" de un repositorio de Subversion. Existe la implementación central, que podría iniciarse desde la línea de comandos, y funciona bien con Java 6. Pero empecé a implementar una interfaz de usuario, que utiliza JavaFX como parte de Java 8. Así que he dividido el 2 y he creado un Segundo repositorio (con un segundo proceso de compilación), con diferente programación, ...

Me gustan las respuestas anteriores (las he votado), pero creo que no son toda la historia real. Así que también quería agregar los argumentos para dividir los repositorios. Así que la respuesta real (cuándo dividirse) puede estar en algún lugar en el medio ...

Puede ser que git-subtree (vea blog de Atlassian , medio blog , o enlace del kernel ) sería un buen ajuste para eso que tiene. Por lo tanto, cada uno de sus proyectos de nivel superior utilizaría un conjunto de subárbol en versiones posiblemente diferentes.