Mi proyecto usa más de 100 submodules de git, cuya alternativa de submodule puede manejar muchos repositorys con gracia

He estado investigando el subtree de git y otras alternativas a los submodules de git. Mi proyecto tiene más de 100 submodules y es muy difícil administrarlos todos.

¿Alguien puede recomendar un flujo de trabajo que funcione realmente bien con una gran cantidad de repositorys que deben mantenerse sincronizados?

Si el proyecto tiene más de 100 submodules de git de componentes y dependencies, su administración será difícil de manejar, independientemente del enfoque que utilice 🙂 Sugiero que busque forms de crear scripts y automatizar tantas partes como sea posible. Créanme, la novedad de jugar con y encadenar commands de git se desgasta muy rápido para la mayoría de las personas, especialmente cuando se acercan los ploops. Ya hay una muy buena respuesta aquí en la comparación de los diferentes enfoques para administrar los subproyectos de git.

Con respecto al flujo de trabajo, primero separaré repositorys que están bajo su control de aquellos que no son repositorys de terceros.

Para los repositorys de terceros que no cambian con frecuencia (ya sea mediante fusiones o PR previos), aún puede usar submodules. Normalmente, apuntará estos submodules a la CABEZA de algunas tags estables. Sincronizarlos es solo cuestión de ejecutar (o git submodule update --recursive --remote scripts) la git submodule update --recursive --remote . Si estas dependencies de terceros se pueden especificar en herramientas de administración de packages como bundler (para proyectos de ruby) , le ayudará a simplificar la administración de sus subproyectos.

Para repositorys propios y que cambian a menudo, ya sea gitslave o git-subtree son dos alternativas, según las preferences de su equipo.

gitslave multiplexa las operaciones de git en múltiples twigs. IOW, cuando twigs, fusiona, compromete, empuja, tira etc., cada command se ejecutará en el proyecto principal y todos los esclavos sucesivamente. Esto obliga al equipo a trabajar de arriba hacia abajo, comenzando desde el superproyecto hasta los esclavos.

gitsubtree usa la funcionalidad de subtree merge subtítulos de Git para lograr un efecto similar a los submodules, al almacenar los files en el repository principal y fusionarse en los cambios directamente en ese repository. El resultado final es un repository canónico con la opción de include el historial de todos los subproyectos. En cierto modo, esto permite a los miembros del equipo centrarse más en los subtreees de los que son responsables, pero requerirá trabajo adicional para fusionarse con el tree padre.

Como desarrollador, mi preference es trabajar en el nivel inferior de subproyectos (para hacer mi ciclo "rojo, verde, refactor" ) y tocar los proyectos principales solo cuando sea necesario. Pero independientemente de si elige un flujo de trabajo de arriba hacia abajo o de abajo hacia arriba, intente identificar los pasos repetitivos propensos a errores en su estrategia de bifurcación y fusión, y guíelos tanto como sea posible.