delete - git tag
¿Cuándo dividir un repositorio grande de Git en otros más pequeños? (5)
Cuando esté trabajando en un entorno distribuido, dando las características de git, debe evitar agrupar directamente diferentes componentes en un único repositorio si esos componentes son utilizados por otros proyectos o si planea hacerlo. O si es probable o deseable, sucederá en el futuro.
Esto se debe a que los desarrolladores / colaboradores podrán centrarse en su parte sin la necesidad de descargar el historial completo de todos los demás componentes que no van a usar / cambiar. Pensar en eso también es crucial si está trabajando con colaboradores de países / áreas donde la velocidad de Internet es más lenta que la que usamos en.
Cuando probó y comprendió varios métodos, no se queda estancado con poco conocimiento y no debería ser una tarea difícil. Por lo que sé, tienes todas las alternativas posibles.
No me preocuparé por tener docenas o potencialmente cientos de repositorios más pequeños si son de alguna manera independientes del repositorio principal. Tener tantos repositorios solo aumentará el tiempo de la primera configuración de su nuevo repositorio principal.
Debe favorecer la solución de repositorio grande solo si necesita migrar "inmediatamente" desde Subversion. O alguien con o ningún conocimiento de alternativas.
Yo usaría git subtree porque está disponible con git como características estándar: no se requerirá que los usuarios instalen nada más que git, y continuará hasta que git lo haga.
Estoy trabajando en hacer una migración de SVN a Git. Ya he usado git-svn para obtener el historial en un solo repositorio de git, y ya sé cómo usar git-subtree para dividir ese repositorio en otros más pequeños. Esta pregunta no es sobre cómo realizar la migración, sino sobre cuándo dividir y cuándo no.
Quiero dividir el repositorio grande porque algunos de los directorios son bibliotecas independientes que también se comparten con otros proyectos. Anteriormente, se realizaba una svn checkout en la biblioteca sin la necesidad de verificar todo el proyecto. Durante todo esto descubrí que probablemente hay docenas de directorios que tienen sentido estar en su propio repositorio porque son 1) independientes y 2) compartidos entre proyectos.
Una vez que llegue por encima de un puñado de repositorios git, parece prudente utilizar una herramienta que facilite el trabajo con muchos repositorios. Algunos ejemplos son el repo de Google, los git submodules , el git subtree y la creación de un script personalizado (parece que el cromo hace esto). He explorado estos diversos métodos y entiendo cómo usarlos.
Entonces la pregunta es acerca de la dirección para la transición desde la subversión.
¿Debo tratar de adherirme a un gran repositorio de git, solo dividirlo en partes más pequeñas cuando sea absolutamente necesario o debería dividirlo en docenas o potencialmente cientos de repositorios más pequeños? ¿Con cuál sería más fácil trabajar? ¿Hay alguna otra solución que me haya perdido? Si voy con los muchos repositorios, ¿qué herramienta debo usar? ¿Qué factores harán que alguien favorezca un método sobre otro?
Nota: la fuente se debe verificar en Windows, MacOS y Linux.
Cuando tenga un buen caso de reutilización para múltiples proyectos, entonces considere dividirlo en un subproyecto. Evitaría crear un proyecto compartido antes de que tenga dos proyectos que lo utilicen.
Criterios que usaría para considerar hacer un repositorio de subproyecto:
- ¿Es utilizado por múltiples proyectos?
- ¿Es autónomo?
- ¿Cambia frecuentemente?
Considero que los subárboles son los más fáciles de administrar, ya que puedo desarrollar la biblioteca como parte de un proyecto y luego separarla cuando surge la necesidad.
También me gustaría señalar que está perfectamente bien que dos proyectos divergan en bibliotecas comunes, y a menudo se prefiere para mantenerlos en un estado estable. Siempre que sea fácil converger el código común, no veo ningún daño en adoptar un enfoque perezoso para compartir bibliotecas.
En cualquier caso, es una buena señal para tener este problema; significa que has hecho un buen trabajo al hacer código reutilizable. :)
Ese proceso puede guiarse por un enfoque de componentes , donde identificó un conjunto coherente de archivos (una aplicación, un proyecto, una biblioteca)
En términos de historia (en una herramienta de control de origen), un conjunto coherente significa que se etiquetará, se ramificará o se fusionará como un todo, independientemente del otro conjunto de archivos.
Para un sistema de control de versiones distribuido (como git), cada uno de esos conjuntos de archivos es un buen candidato para su propio repositorio git, y luego puede agrupar los que necesita para un proyecto específico en un repositorio principal con submodules .
Describo este enfoque por ejemplo en;
- " Configuración de repositorio Git para un proyecto que tiene un servidor y un cliente " (el servidor y el cliente son dos conjuntos separados obvios y coherentes que se benefician de tener su propio repositorio)
- " ¿Qué es el desarrollo impulsado por componentes? "
Lo contrario (mantener todo en un repositorio) se llama " enfoque basado en el sistema ", pero puede llevar a un enorme repositorio de Git, que, como mencioné en " Rendimiento para Git ", no es compatible con la forma en que se implementa Git.
El pregunta en los comentarios :
¿Podría incluir más información sobre las sutilezas de los componentes de identificación?
Este proceso (de identificación de "componentes", que a su vez se convierten en repositorios git) está guiado por la arquitectura de software de su sistema.
Cualquier subconjunto que actúe como un conjunto de archivos independiente es un buen candidato para su propio repositorio. Puede ser una biblioteca o dll, pero también es parte de una aplicación (una GUI, un cliente frente a un servidor, un despachador, ...)
Cada vez que identifique un grupo de archivos estrechamente vinculados (lo que significa que modificar uno probablemente afectará a otros), debería haber parte del componente, o en git, el mismo repositorio.
Personalmente, me gustan los repositorios pequeños: funcionan bien cuando se tiene un buen sistema de administración de dependencia como Composer for PHP.
Quita el dolor al administrar el proceso de extracción y también rastrea las versiones, etc.
También permite que los repositorios sean alojados por diferentes proveedores. Utilizamos una combinación de código a medida y repositorios de código abierto.
Yo diría, vaya con subárboles la mayoría del tiempo, si no todo el tiempo, y siéntase libre de hacer subárboles libremente cuando lo considere necesario.
Con muchas y muchas dependencias, los submodules comienzan a volverse dolorosos. Si tiene algún efecto en el desarrollo de esas dependencias, entonces eso va doblemente. El submódulo podría estar bien si tiene una biblioteca de terceros que no cambia las versiones muy a menudo, y que nunca desarrollaría activamente como parte de su proyecto más grande.
Los submódulos están demasiado separados del super-repo para las dependencias en las que realmente trabaja.
Ejemplo: Si realiza un cambio en un submódulo, debe confirmar en el submódulo, subir, subir hasta el super repo, agregar el submódulo al índice / etapa, confirmar y volver a subir. Es una molestia de un flujo de trabajo. Sin mencionar la molestia de eliminar, mover o renombrar un submódulo.
Los subárboles de Git son mucho mejores. Las historias están interrelacionadas, pero puede dividir un directorio como un subárbol a cualquier antojo. Si decide que ya no desea que algo sea un subárbol ... simplemente deje de realizar la división o los empujes del subárbol.
La desventaja de los subárboles es que no están rastreados en absoluto. Por lo tanto, debe recordar todos los caminos y su relación con sus repositorios, y cualquier otra persona que trabaje en el proyecto también debe saber si desea realizar operaciones de subárbol. La buena noticia es que la mayoría de los desarrolladores pueden trabajar en cualquier código en cualquiera de las dependencias sin preocuparse de cómo se enviará a esos repositorios. Además, como usted dijo, algunos scripts de bash pueden automatizar las tareas manuales.