¿Usar múltiples repositorios Git en lugar de uno que contenga muchas aplicaciones de diferentes equipos? [duplicar]

Estás tratando con varios equipos y múltiples proyectos. Las décadas probables de trabajo fueron en el código base.

La respuesta corta es que sus equipos y proyectos tienen necesidades y dependencias que varían.

El enfoque del repositorio monolítico reduce los compromisos a "¡¡¡Todo es estable en esta configuración !!!" (es decir, compromisos enormes e irreales provenientes de muchos equipos). Eso, o muchos puntos intermedios de incompatibilidades para muchos proyectos. De cualquier manera, hay una gran cantidad de energía desperdiciada invertida en configuraciones de soporte que simplemente nunca debieron ser.

En su lugar, sus repositorios deberían estar estructurados de forma independiente y deberían tener múltiples repositorios que representen sus dependencias. Las dependencias deben ser configuradas, actualizadas y probadas por los encargados del proyecto en los puntos apropiados del desarrollo.

• ProjectA vio su último lanzamiento importante hace 3 años. Está en modo de mantenimiento y tiene requisitos de sistema "más antiguos". Debe referirse a un conjunto apropiado de dependencias. Tiene 20 dependencias.
• ProjectB acaba de ser lanzado. Tiene requisitos del sistema más modernos, y fue desarrollado y probado por otro equipo. Tiene 15 bibliotecas dependientes (= repos), 10 de las cuales se comparten con ProjectA. Estos proyectos generalmente se refieren a diferentes compromisos de sus bibliotecas dependientes. Las dependencias se actualizan en los puntos apropiados del desarrollo.
• ProjectC aún no se ha lanzado. Es muy similar a ProjectB, pero incluye cambios significativos y mejoras en sus dependencias. Los desarrolladores de ProjectB solo están interesados en tomar las versiones estables de las dependencias que comparten con ProjectC. El equipo de ProjectB se compromete con las dependencias compartidas, aunque en este momento son en su mayoría correcciones de errores y optimizaciones. Un repositorio monolítico podría frenar el desarrollo de ProjectC para mantener el soporte para ProjectA, o los cambios de ProjectC romperían A y B, o los desarrolladores terminarían sin compartir / reutilizar el código.

Con múltiples repositorios (distribuidos), cada equipo puede trabajar de forma independiente y minimizar el impacto en los otros proyectos mientras reutiliza y mejora constantemente las bases de código. Esto también evita que los equipos cambien de enfoque / velocidad cuando se producen cambios de otros equipos. El repositorio monolítico centralizado hace que cada equipo dependa del movimiento de cada equipo, y eso tendría que estar sincronizado.

No parece haber un argumento a favor del gran repositorio en este hilo, así que aquí hay uno:

La ventaja de un gran repositorio con todo tu código en él, es que tienes una fuente confiable de verdad. Todo el estado en su proyecto global está representado en la historia de ese repositorio. No tiene que preocuparse por preguntas como "¿Qué versión de libA necesito para compilar libB desde hace 3 meses?" o "¿Las pruebas de integración comenzaron a fallar debido al cambio de Susan en libC o al cambio de Bob en libD?" o "¿Quedan llamadores para evilMethod ()?" Todo está en la historia.

Cuando los proyectos relacionados se dividen en repositorios separados, git no hace un seguimiento de sus relaciones por usted. Su sistema de compilación necesita saber dónde encontrar el código para todas sus dependencias y, lo que es más importante, qué versión del código se debe compilar. Puede "simplemente compilar todo desde el maestro", pero eso dificulta la reproducción de compilaciones pasadas, es difícil hacer cambios (o retrotraer) que deben sincronizarse entre los repositorios y es difícil mantener las sucursales en un estado estable.

Entonces la pregunta no es "¿Un repositorio grande o muchos repositorios pequeños?" En realidad, es "Un repositorio grande o muchos repositorios pequeños con herramientas ". ¿Qué herramienta vas a utilizar? Repo (Android) y gclient (Chromium) de Google son dos ejemplos. Los submódulos de Git es otro. Todos ellos tienen major downsides que debes comparar con las desventajas de un gran repositorio.

Editar: aquí hay algunas respuestas más ¿Elegir entre proyectos individuales o múltiples en un repositorio git?

PD: Dicho todo esto, estoy trabajando en una herramienta para mejorar las cosas, para cuando tengas que dividir repos o usar el código de otras personas: enlace

Git tiende a experimentar problemas de rendimiento cuando se utiliza con grandes repositorios.

A quote Linus :

  

Y git obviamente no tiene ese tipo de modelo. Git
  Fundamentalmente, en realidad nunca se ve menos que todo el repositorio. Incluso si   limitas las cosas un poco (es decir, echa un vistazo solo a una parte, o tienes la   la historia retrocede solo un poco), git termina siendo siempre preocupado por   todo el asunto, y llevar el conocimiento a su alrededor.

     

Entonces, git escala muy mal si lo obligas a ver todo como   un enorme repositorio. No creo que esa parte sea realmente reparable,   aunque probablemente podamos mejorarlo.

Énfasis mío. Eso no quiere decir que el repositorio de control de versiones de su empresa sea "grande", pero esta es una de las razones por las que las personas tienden a evitar los grandes repositorios dentro de Git.

  

Quieren [algo que pueda] mostrar sus cambios en todos los proyectos en lugar de tratar de recordar en qué proyecto hicieron un cambio [a].

Sourcetree (una interfaz Git de GUI gratuita como cerveza) le permite registrar múltiples repositorios, organícelos en grupos lógicos, y luego vea el estado en todos ellos a la vez:

No estoy afiliado a ellos de ninguna manera.

TL; DR; el equivalente de un repositorio git es un módulo CVS, no un repositorio CVS.

CVS está diseñado con una noción de que los módulos son una subdivisión de un repositorio, y es común usar repositorios CVS con varios módulos que tienen una vida bastante independiente. Como ejemplo, es fácil tener sucursales específicas para un módulo y no presentes en otro.

git no se ha diseñado con una noción de módulo, cada repositorio de git está limitado a un módulo en el término CVS. Cuando creas una rama, es válido para todo el repositorio.

Por lo tanto, si desea importar un repositorio CVS con varios módulos en git, es mejor que cree un repositorio por módulo, especialmente si los módulos tienen una vida más o menos independiente y no comparten cosas como sucursales y etiquetas. (Debido a los diferentes patrones de uso de las sucursales en CVS y git, incluso puede investigar la utilidad de tener un repositorio por sucursal de CVS; pero para una migración de CVS a git, es probable que su flujo de trabajo sea al principio lo suficientemente similar como para un flujo de trabajo de CVS que no vale la pena).

Si está dispuesto a jugar a la pelota con ellos para apaciguar, puede configurarlo de esta manera . O este método . Aparte de eso, creo que solo esperan un solo punto de entrada al sistema para acceder a los activos.

Dependiendo de las necesidades de acceso, los repositorios GIT separados pueden seguir siendo la mejor opción, ya que "John Smith" puede necesitar acceso a ciertos datos, pero no a otros. Mientras que "Suzy Que" puede ser un administrador de sistema que necesita acceso a todo.

Si va con un solo repositorio, es posible que tenga problemas con sus requisitos de acceso interno. Si es un tipo de cosa de "todos tienen acceso completo", entonces podría ver su punto de vista.

página de ayuda de migración de Git desde Eclipse sugiere reorganizar el árbol de directorios CVS / SVN en múltiples repositorios Git:

  

Ahora es un buen momento para refactorizar su estructura de código.   Asigne los directorios, módulos, complementos, etc. de CVS / SVN actuales a su nuevo hogar en Git.   Normalmente, se crea un repositorio Git (.git) para cada lógica   agrupación de código: un proyecto, un componente, etc.

Los argumentos:

  

La compensación aquí es que cada repositorio Git adicional   agrega sobrecarga adicional a su proceso de desarrollo -   todos los comandos y operaciones de Git se producen en el nivel de un solo repositorio de Git.   Por otro lado, cada usuario del repositorio tendrá una copia completa.   de la historia del repositorio, haciendo que los repositorios muy grandes sean engorrosos   Trabajar con colaboradores ocasionales.

Git opera en un árbol completo a la vez, no solo en el subdirectorio en el que estás.

Supongamos que tienes tu proyecto en

C:\MyCode\ProjectABC

Y digamos que estos dos archivos han cambiado:

C:\MyCode\ProjectABC\stuff.txt
C:\MyCode\ProjectABC\Stuff\MoreStuff\morestuff.txt

Cuando estés en la raíz del proyecto y hagas un estado de git, verás que estos archivos han cambiado:

stuff.txt
Stuff\MoreStuff\morestuff.txt

Sin embargo, si cd al directorio de MoreStuff, ¿verá solo el archivo morestuff.txt? No. Seguirás viendo ambos archivos, en relación con tu posición:

..\..\stuff.txt
morestuff.txt

Como resultado, si agrupa todos sus proyectos en un gran repositorio de Git, entonces cada vez que vaya a registrarse, tendrá que elegir entre los cambios en cada proyecto .

Ahora podría haber formas de mitigar eso; por ejemplo, puede intentar asegurarse de que al menos temporalmente comprometa sus cambios antes de trabajar en un proyecto diferente. Pero esa es una gran cantidad de gastos generales con los que cada persona de su equipo tendría que lidiar, en comparación con simplemente hacerlo de la manera correcta: un repositorio de Git por proyecto.