tag - submodulos git

¿Submódulos, subárboles u otra cosa para las dependencias en Git?

Question

Tengo una situación con un proyecto más grande que tiene muchos módulos / bibliotecas con sus respectivos repositorios. La mayoría de estos módulos son dependencias de otros módulos que son dependencias de un proyecto. Y ahora ha llegado al punto en que el proyecto principal tiene varios subproyectos y muchos de los módulos se comparten. Algunas dependencias tienen más de 3-4 niveles de profundidad.

He leído que es posible actualizar / extraer submódulos dentro de un proyecto, pero eso funciona solo para el primer nivel de submódulos. Digamos que esos submódulos tienen sus propios submódulos (segundo nivel) y que algunos submódulos de primer nivel comparten los mismos submódulos de segundo nivel. Además, los submódulos de 2nd lvl tienen sus submódulos (lvl3), etc. Ahora lo que debo hacer es presionar primero los cambios realizados en el 3er nivel, que actualizar los módulos en los módulos de 2º nivel e impulsarlos, ahora puedo pasar al 1er nivel, actualizar y presione y finalmente actualice los submódulos de mi proyecto y presione esos.

Esto ahora no solo es más trabajo, pero aún no resuelve mi problema por qué necesito algo como esto y eso es poder empujar y tirar fácilmente varios repositorios cuando se realizan cambios en aquellos que dependen el uno del otro. Puede suceder fácilmente que alguien en un equipo presione cambios en 4 de 5 repositorios, y cuando otros miembros extraen todos, excepto ésta, la línea de producción se detiene hasta que se encuentra un error.

¿Qué puedo hacer sobre esto? Tal vez algunos consejos sobre el flujo de trabajo, ¿alguien más ha encontrado este problema o hay alguna característica en Git que resuelve esto?

Answer 1

Yo recomendaría la herramienta de repositorio que usa Android. Es lo suficientemente genérico como para funcionar con cualquier entorno de hospedaje de git, y no requiere compromisos de superproyectos para actualizar subproyectos como lo hacen los submódulos.

Primero, instale el cliente como se describe aquí: https://source.android.com/source/downloading.html#installing-repo

Luego crea un repositorio de manifiesto. Un manifiesto es un archivo xml que describe las ubicaciones del repositorio git y las rutas a las que se deben prestar. Me gusta esto:

mkdir manifests
cd manifests
git init

Crea un archivo de manifiesto default.xml :

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <remote name="github" fetch="ssh://[email protected]" />
  <default remote="github" revision="master" />
  <project name="git/git.git" path="git" />
  <project name="libgit2/libgit2.git" path="vendor/libgit2" />
</manifest>

A continuación, agregue, envíe el manifiesto y presione en algún lugar:

git add default.xml
git commit -m "My first try at a manifest file"
git push [email protected]:myusername/manifests.git master

Ahora está listo para usar el comando repo .

mkdir myproject
cd myproject
repo init -u [email protected]:myusername/manifests.git
repo sync -j2

Sus repositorios git serán clonados. Ahora puedes trabajar en cada uno de manera normal. Después de presionar en cualquiera de los proyectos, todo lo que los demás deben hacer es una repo sync y se actualizarán a la última revisión (también vea el repo start ).

Advertencias

Es posible que deba reorganizar su proyecto. Normalmente, puede tener otros módulos como subdirectorios ( myproject/vendor/dependency ). Si bien puede mantener este diseño utilizando repo, hará que un repositorio de git se saque con otro repositorio. Con el truco de .gitignore podría funcionar, pero recomendaría reorganizar tu proyecto para que los repositorios no necesiten ser revisados ​​uno dentro del otro.

Una breve explicación sobre los archivos manifiestos

Consulte https://gerrit.googlesource.com/git-repo/+/master/docs/manifest-format.txt para obtener una explicación completa de cada elemento en el archivo xml.

Consulte https://source.android.com/source/using-repo.html para obtener una referencia de comando simple. repo help también es muy útil. Nota: debe ignorar la repo upload menos que esté usando Gerrit.

<remote name="github" fetch="ssh://[email protected]" />

Esto es como agregar un control remoto en git . Significa que podemos referirnos a la url con un nombre de pila.

<default remote="github" revision="master" />

El elemento predeterminado especifica las opciones predeterminadas para los proyectos. Esto es equivalente a agregar elementos remote y de revision en cada proyecto. Esto solo ahorra algo de tipeo.

<project name="git/git.git" path="git" />

Aquí es donde está sucediendo el trabajo real. repo sync tomará el nombre y lo agregará al control remoto con una barra inclinada. En este caso, el control remoto es el github predeterminado, por lo que obtendrá el url ssh://[email protected]/git/git.git . Verificará el proyecto en la ruta de acceso de la revisión especificada (en este caso, el valor predeterminado es master ). Las subsiguientes repo sync verificarán la última revisión (en el caso de una sucursal).