Submodules de git altamente acoplados

Tengo un proyecto que debe dividirse en dos repositorys: un set de models comunes y una simulación basada en esos models, con código adicional. En última instancia, puede haber múltiples simulaciones utilizando el mismo set de models, por lo que tenerlos en un repository separado es un requisito definitivo. La solución obvia es tener los models comunes como un submodule de la simulación.

Desafortunadamente, los dos repositorys estarán muy acoplados. Las personas agregarán con mucha frecuencia algo a sus models comunes y luego lo usarán de inmediato en la simulación. Me imagino que esto provocará muchos dolores de cabeza en el process de integración del repository de simulación. Para fusionar los cambios de muchos desarrolladores en la simulación, el integrador tendrá que realizar fusiones paralelas en el submodule de models comunes. Por otro lado, también hace que sea esencial usar submodules: la simulación realmente necesita saber qué versión de los models comunes debería usar.

El proyecto es trabajado por un número considerable de personas. La mayoría de los desarrolladores solo tienen un conocimiento muy superficial de git: agregan files, se comprometen y extraen mucho del origen, y con suerte tienen una twig dev y estable. El integrador naturalmente ha aprendido un poco más, pero cualquier cosa que involucre submodules será definitivamente nuevo para él. Bonificación adicional: estoy a punto de tomarme un mes de vacaciones, por lo que no podré apagar ningún incendio. El resultado es que hay un gran incentivo para hacer que el flujo de trabajo sea realmente difícil de arruinar, y para minimizar la diferencia con los flujos de trabajo previos de las personas.

Entonces, mis preguntas son: ¿me arrepentiré de recomendar que usemos submodules para esto? (¿Hay una mejor idea?) ¿Qué tipo de errores puedo esperar que hagan las personas, así que puedo advertirles de antemano? ¿Hay alguna buena estrategia de flujo de trabajo para tener en count?

Editar: Acabo de encontrar git slave , que también podría valer la pena en este context. Todavía no se puede dar una buena evaluación de las habilidades / limitaciones más allá de lo que está en su website.

El submodule es una buena opción para asegurarse de hacer reference a la revisión precisa de los diferentes componentes involucrados.
Como detallé en "la verdadera naturaleza de los submodules ", aún puedes actualizar cualquiera de los submodules, siempre que los confirmes primero (y luego ve al repository principal y confirma también)

Sin embargo, para los modules estrechamente acoplados, trataría de evitar:

"Me imagino que esto generará muchos dolores de cabeza en el process de integración del informe de simulación".

No veo un process de integración central que funcione de manera eficiente: solo debe registrar nuevas evoluciones de avance rápido.
Para que eso suceda, cualquier usuario que desee presionar algo debe tirar primero y volver a establecer sus cambios en base a los cambios que ya se hayan introducido allí.
El desarrollador es más apto para resolver cualquier conflicto y / o le pregunta a sus colegas el origen de algunas modificaciones con las que tiene que lidiar durante la rebase.

Esto (pull, rebase, push) no siempre es posible debido a:

  • operaciones "avanzadas" (less básicas) de Git involucradas (y un flujo de trabajo no exactamente idéntico al actual)
  • trabajo involucrado (teniendo en count las evoluciones de otros contribuyentes)
  • configuration del entorno (puede ser preferible configurar un entorno adicional para hacer esa rebase, que de nuevo es "no tan básica")

Pero esa seguiría siendo la dirección que trataría.

(… pero tal vez no solo antes de un mes de vacaciones;)
Por otra parte, ¿quién se lleva todo un mes de vacaciones? Nunca he oído hablar de ese concepto antes)

¡Algunas notas para cualquier persona que pase por esto!

El mayor error que cometerán los novatos es comprometerse con HEAD separado en el submodule, después de haber hecho una actualización de submodule. Voy a tratar de contrarrestar esto con fuertes advertencias de los ganchos.

El siguiente más grande probablemente fallará al hacer una actualización de submodule después de hacer un pago que requiere uno. Nuevamente, los ganchos pueden verificar esto y advertir.

En cuanto al process de desarrollo, esta configuration hace que sea mucho más importante tener una buena infraestructura de testing en el submodule, por lo que, si es posible, puede trabajar en él sin tener que trabajar en el principal y evitar el problema por completo.

Trataré de publicar un código de muestra de los ganchos que termine usando, y un mes después con historias de terror verdaderas (con suerte no demasiadas).

Editar:

Aquí están los primeros borradores de los ganchos. ¡Tenga en count que este es un trabajo urgente y no me moleste!

En el repository principal:

Para la fusión posterior y posterior a la salida, advertimos al usuario si el submodule no está sincronizado. (la fusión posterior se incluye en particular para fusiones rápidas, extracción desde el origen). También tenga en count que querrán consultar una twig, aunque el gancho posterior al check-in del submodule también lo hará cuando ejecuten la actualización del submodule. Cuantos más recordatorios, mejor.

#!/bin/bash if git submodule status | grep '^+' > /dev/null; then echo "WARNING: common model submodule now out of sync. You probably want to run" 1>&2 echo " git submodule update, then make sure to check out an appropriate branch" 1>&2 echo " in the submodule." 1>&2 fi 

Para la confirmación posterior, si hay cambios de submodules, advertimos al usuario que puede haber olvidado includelos en su confirmación. En este caso altamente acoplado, esta es una muy buena suposition. Es poco probable que el usuario haya modificado la simulación y los models comunes por separado .

 #!/bin/bash if git submodule status | grep '^+' > /dev/null; then echo "WARNING: common model submodule has changes. If the commit you just made depends" 1>&2 echo " on those changes, you must run git add on the submodule, and then run" 1>&2 echo " git commit --amend to fix your commit." 1>&2 fi 

Y en el submodule, un gancho post-checkout para advertir fuertemente sobre HEAD separado:

 #!/bin/bash get_ppid() { ps --no-headers -o ppid $1 } # Check to see if this checkout is part of a submodule update # git submodule calls git checkout, which calls this script, so we need to # check the grandparent process. if ps --no-headers -o command $(get_ppid $(get_ppid $$)) | grep 'submodule update' &> /dev/null; then if ! git symbolic-ref HEAD &> /dev/null; then echo "WARNING: common model submodule entering detached HEAD state. If you don't know" 1>&2 echo " what this means, and you just ran 'git submodule update', you probably" 1>&2 echo " want to check out an appropriate branch in the submodule repository." 1>&2 echo # escape the asterisk from SO's syntax highlighting (it sees C comments) branches=($(git for-each-ref --format='%(objectname) %(refname:short)' refs/heads/\* | grep ^$(git rev-parse HEAD) | cut -d\ -f2)) case ${#branches} in 0 ) ;; 1 ) echo "Branch '${branches[0]}' is at HEAD" ;; * ) echo "The following branches are at HEAD: ${branches[@]}" ;; esac fi echo fi 

También estoy agregando un enlace precompromiso para simplemente abortar confirmaciones hechas con HEAD separado (a less que sea una rebase). Estoy bastante aterrorizado de get el clásico "desaparecieron todos mis compromisos". Siempre puede omitirlo con --no-verify si sabe lo que está haciendo.