git - the - ¿Qué es un buen flujo de trabajo para las horquillas de submódulos?

git submodules commands

Question

Supongamos que tenemos la siguiente estructura de repositorio en github:

company:project.git
/- company:submodule.git

Un desarrollador en mi empresa bifurca el proyecto de la compañía, haciendo que su espacio de trabajo se vea así:

developer:project.git
/- company:submodule.git

Esto está bien para el 90% de los desarrolladores, ya que no cambian la biblioteca de submódulos, solo trabajan en el proyecto. Ahora supongamos que hay una nueva característica que requiere mejoras en el submódulo. El desarrollador encargado de esto convierte su espacio de trabajo a esto:

developer:project.git
/- developer:submodule.git

Llegar allí no es trivial, ya que necesita reemplazar un submódulo con otro submódulo (para git, el original y la bifurcación del submódulo son dos cosas diferentes).

Si este desarrollador trabaja en la biblioteca un poco más, confirma esta estructura a su rama maestra, por lo que su fork en github siempre usa el submódulo bifurcado.

Una vez que esté listo con el desarrollo, creará una solicitud de extracción. El problema es que al fusionar la solicitud de extracción, el repositorio principal se verá así:

company:project.git
/- developer:submodule.git

Esto es problemático ya que ahora todos los desarrolladores que rastrean la sucursal de la empresa terminarán con el submódulo del desarrollador.

Para solucionar el problema, antes de que el desarrollador realice una solicitud de extracción, su rama maestra debe trasladarse a la empresa: submodule.git, lo cual es muy incómodo, especialmente porque localmente siempre querrá trabajar con el desarrollador: submodule. git

Hemos intentado varios flujos de trabajo, y el problema anterior es el único en el que aún no tenemos un buen flujo de trabajo.

Answer 1

Ahora supongamos que hay una nueva característica que requiere mejoras en el submódulo.

La contribución que se realiza en el submódulo, solo las confirmaciones en el submódulo git repo se deben solicitar, como de costumbre.

Con el fin de empujar en su horquilla de submódulo,

• La configuración de .gitmodules del proyecto se puede cambiar en su bifurcación clonada (pero se mantiene de su lado)
• o su horquilla de submódulo se puede agregar como un control remoto

Answer 2

Cuando el desarrollador crea una confirmación con el submódulo en una versión particular, es una afirmación firme de que el supermódulo funciona con el submódulo en esa versión exacta. Si su código realmente funciona con la versión del submódulo de la empresa, creo que lo correcto es que el desarrollador:

1. ramificar el supermódulo
2. Comprobación de la versión de la empresa en el submódulo.
3. actualice .gitmodules en el .gitmodules , si el desarrollador cambió eso de la versión anterior
4. Etapa y compromete ese cambio.
5. prueba todo
6. emitir la solicitud de extracción

Luego puede volver a su rama de desarrollo normal en el supermódulo.

Una cosa que no entiendo de tu pregunta es la siguiente:

Llegar allí no es trivial, ya que necesita reemplazar un submódulo con otro submódulo (para git, el original y la bifurcación del submódulo son dos cosas diferentes).

Por el contrario, el submódulo puede ser cualquier repositorio git siempre que contenga el compromiso al que apunta el supermódulo. Si hay dos repositorios remotos diferentes, solo puede agregar un control remoto adicional en el submódulo. (El desarrollador también debería cambiar .gitmodules si va a compartir su repositorio con cualquier otra persona).

En respuesta a su comentario a continuación, quizás valga la pena analizar cómo cambiar un submódulo de señalar una versión a otra. Supongamos que el desarrollador está utilizando sus propios repositorios para el súper y submódulo, pero ambos se clonan a partir de las versiones de la compañía (es decir, la mayor parte de la historia es la misma), y el submódulo se encuentra en la ruta lib . El desarrollador ahora quiere cambiar el submódulo para que apunte a la versión de la compañía. Pueden hacer lo siguiente:

1. Edite el parámetro url para el submódulo en .gitmodules para que apunte al repositorio de la empresa.
2. cd lib
3. git remote add company developer@company:/srv/git/lib.git
4. git fetch company
5. git checkout -b upstream-master company/master
6. cd ..
7. git add .gitmodules lib
8. git commit -m "Switch the lib submodule to point back to the company''s version"

Los pasos del 3 al 5 solo se pueden cambiar a git checkout <whatever> una vez que se configuren el control remoto y la sucursal.

Answer 3

Otra solución simple es decirle a git que ignore .gitmodules y que los elimine del seguimiento. Como se dijo anteriormente, .gitmodules se usa solo para inicializar submódulos, por lo que solo se necesita una vez, al revisar los submódulos.

Answer 4

Para que se desarrolle en él, el desarrollador no necesita cambiar el submódulo, ya que podrían agregar otro control remoto y empujar hacia él.

Ejemplo:

developer:project.git
/- company:submodule.git
Origins: company/submodule.git
developer/submodule.git

Flujo de trabajo:

cd path/to/submodule
git remote add developer git@gitserver/developer/submodule.git

// hackear el proyecto

cd path/to/submodule
git push developer branchname

Definitivamente no es perfecto y puede causar problemas si una solicitud de extracción en el desarrollador / proyecto llega a la empresa / proyecto antes de que el desarrollador / submódulo llegue a la compañía / submódulo.

Sólo mis pensamientos rápidos.