Git subrepo

El proyecto git-subrepo ha existido durante mucho tiempo, sin embargo, hay pocas referencias a él. El autor de git-subrepo es Ingy döt Net .

Si observa la historia de los compromisos de la rama maestra del proyecto, puede parecer que el proyecto se detuvo en el desarrollo hace 2 años. Sin embargo, el trabajo en el proyecto está en marcha y espero que la versión 0.4.0 se lance pronto.

Una propiedad importante de esta herramienta es que no es necesario que el usuario instale git-subrepo hasta que el usuario decida realizar confirmaciones en el repositorio ascendente de subproyectos. Además, el usuario recibe un árbol de origen totalmente preparado y configurado al momento de copiar el repositorio principal utilizando el comando estándar git-clone (1) .

Al elegir los medios para admitir submódulos / subárboles / subproyectos del repositorio principal del contenedor, el desarrollador primero determina el rango de posibilidades que proporciona este o aquel mecanismo y da respuestas a las siguientes preguntas:

• si es necesario mantener el historial completo del subproyecto en el repositorio principal o suficientes confirmaciones aplastadas;
• si se necesita la capacidad de entregar cambios desde el subproyecto al repositorio ascendente del subárbol;
• ¿Es necesario conectar etiquetas fijas del repositorio ascendente del subproyecto o es posible conectar ramas?
• si será necesario eliminar aún más los subproyectos en sí mismos y, lo que se ha vuelto innecesario, parte de la historia de estos subproyectos;
• si el usuario tendrá que tomar alguna medida para configurar manualmente los subproyectos después de clonar el repositorio del proyecto principal;
• cuán laborioso será la cuestión de analizar la historia de la conexión de subproyectos y revisiones específicas de las cuales se origina el subproyecto;
• cómo esta o aquella herramienta afectará la política de Gestión de la configuración de origen y cuánto complicará esta herramienta el trabajo diario de los ingenieros.

Por supuesto, esta lista de preguntas no puede reflejar la totalidad de los parámetros de entrada necesarios para la elección correcta, pero para una revisión preliminar de las herramientas existentes, es bastante suficiente y, hablando del proyecto git-subrepo , instamos al lector a considerar este proyecto desde estas posiciones.

Instalación de Git-subrepo

El paquete git-subrepo , en el lado del desarrollador, se puede instalar localmente, en su directorio de inicio y en el nivel del sistema.

En el primer caso, es suficiente clonar el repositorio git-subrepo en el directorio deseado, por ejemplo, ~ / bin :

bash-4.4$ cd ~/bin bash-4.4$ git clone https://github.com/ingydotnet/git-subrepo.git 

y configurar variables de entorno

 bash-4.4$ vim subrepo-env.sh #!/bin/sh export GIT_SUBREPO_ROOT="/home/username/bin/git-subrepo" export PATH="/home/username/bin/git-subrepo/lib:$PATH" export MANPATH="/home/username/bin/git-subrepo/man:$MANPATH" :wq bash-4.4$ source ./subrepo-env.sh 

Si observa las variables definidas en el Makefile git-subrepo :

 # Install variables: PREFIX ?= /usr/local INSTALL_LIB ?= $(DESTDIR)$(shell git --exec-path) INSTALL_EXT ?= $(INSTALL_LIB)/$(NAME).d INSTALL_MAN1 ?= $(DESTDIR)$(PREFIX)/share/man/man1 

es fácil descubrir que, a nivel del sistema, git-subrepo está instalado en el directorio donde se encuentra Git :

 bash-4.4$ bash-4.4$ git --exec-path /usr/libexec/git-core bash-4.4$ 

Por lo tanto, el comando para instalar git-subrepo puede verse, por ejemplo, de la siguiente manera:

 bash-4.4$ make PREFIX=/usr install 

La presencia de la variable DESTDIR nos permite hacer un paquete para cualquier distribución de Linux sin esfuerzos adicionales (por supuesto, si no estamos en un entorno cruzado), lo que puede ser útil para los ingenieros de DevOps.

Instale git-subrepo como root:

 bash-4.4$ bash-4.4$ cd git-subrepo/ bash-4.4$ make PREFIX=/usr install install -C -d -m 0755 /usr/libexec/git-core/ install -C -m 0755 lib/git-subrepo /usr/libexec/git-core/ install -C -d -m 0755 /usr/libexec/git-core/git-subrepo.d/ install -C -m 0755 lib/git-subrepo.d/help-functions.bash lib/git-subrepo.d/bash+.bash /usr/libexec/git-core/git-subrepo.d/ install -C -d -m 0755 /usr/share/man/man1/ install -C -m 0644 man/man1/git-subrepo.1 /usr/share/man/man1/ bash-4.4$ 

Para analizar las capacidades de git-subrepo, necesitamos un entorno de prueba simple donde podamos reproducir escenarios operativos estándar.

Entorno de prueba

Creamos tres directorios propietario , remoto , usuario , en el que colocamos modelos de repositorios locales y ascendentes del desarrollador y usuario.

 bash-4.4$ vim _init.sh #!/bin/sh CWD=`pwd` mkdir remote owner user cd remote git init --bare build-system.git git init --bare platform.git cd ../owner git clone $CWD/remote/build-system.git git clone $CWD/remote/platform.git cd build-system echo -e "\n[master] build-system 1.0.0\n" >README git add README git commit -m "init build-system master 1.0.0" git push cd ../platform echo -e "\n[master] platform 1.0.0\n" >README git add README git commit -m "init platform master 1.0.0" git push cd ../../user git clone $CWD/remote/build-system.git git clone $CWD/remote/platform.git cd $CWD :wq bash-4.4$ bash-4.4$ ./_init.sh bash-4.4$ 

Aqui

El autor del proyecto y los usuarios tienen sus propias copias de repositorios ascendentes en sus máquinas, presentados en nuestro ejemplo en los directorios de propietarios y usuarios , respectivamente.

La tarea del autor es incluir las siguientes características en el árbol principal de la plataforma al incluir el subproyecto del sistema builld en el árbol principal:

• clone el repositorio principal con el subproyecto del sistema de compilación incluido en su estructura y no se preocupe por configurar versiones o revisiones. Es decir, cada rama del repositorio de la plataforma debe corresponder a una revisión específica de una rama particular del repositorio del sistema de compilación y el usuario debe recibir un árbol fuente personalizado en una operación git-clone (1) , sin ninguna acción adicional.
• entregar sus cambios al repositorio de proyectos aguas arriba, tanto en el principal como en el auxiliar.
• recibir los cambios realizados por otros participantes o usuarios del proyecto, por supuesto, si tienen los derechos correspondientes.

Considere las acciones del autor que debe implementar para implementar estos requisitos.

Conexión de subproyecto

Para conectar un nuevo subárbol, use el comando git subrepo clone , que en su propósito es similar al comando git-clone (1) . El parámetro requerido para el comando es la URL del repositorio remoto. También puede especificar el directorio en el que se ubicarán el subproyecto y la rama del repositorio remoto. Trabajaremos con ramas maestras, por lo tanto, en nuestro ejemplo, omitimos parámetros de comando innecesarios.

Entonces, el autor del proyecto, en su máquina de trabajo, puede conectar el subproyecto del sistema de compilación utilizando el clon git subrepo ../../remote/build-system.git/comando del sistema de compilación :

 bash-4.4$ bash-4.4$ cd owner/platform/ bash-4.4$ git subrepo clone ../../remote/build-system.git/ build-system Subrepo '../../remote/build-system.git' (master) cloned into 'build-system'. bash-4.4$ 

Considere qué cambios se han producido en el repositorio de la plataforma local:

 bash-4.4$ bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ bash-4.4$ bash-4.4$ git subrepo status 1 subrepo: Git subrepo 'build-system': Remote URL: ../../remote/build-system.git Upstream Ref: b2f5079 Tracking Branch: master Pulled Commit: b2f5079 Pull Parent: b5e76a7 bash-4.4$ 

El historial del subproyecto del sistema de compilación no se entrega al árbol principal; solo tenemos una confirmación aplastada, que se acompaña de información de fondo. Esta información se encuentra bajo control de versión en el archivo ./build-system/.gitrepo/config :

 [subrepo] remote = ../../remote/build-system.git branch = master commit = b2f507918f2821cb7dd90c33223ed5cc3c9922a2 parent = b5e76a713f895565b06ee3ccfa29f19131ba06dd method = merge cmdver = 0.4.1 

Se puede obtener información sobre los subproyectos usando el comando git subrepo config , por ejemplo, para averiguar la revisión del proyecto ascendente remote / build-system.git , que acaba de llegar al repositorio principal, usando el comando:

 bash-4.4$ bash-4.4$ git subrepo config build-system commit Subrepo 'build-system' option 'commit' has value 'b2f507918f2821cb7dd90c33223ed5cc3c9922a2'. bash-4.4$ 

Cabe mencionar que el paquete git-subrepo original no guarda información sobre subproyectos en el archivo .gitrepo / config , sino en el archivo .gitrepo .

Entonces, obtuvimos la última versión de la rama maestra del repositorio ascendente remote / build-system.git y la colocamos en el subdirectorio del sistema de compilación del proyecto de plataforma principal.

Para entregar estos cambios en el repositorio ascendente remote / platform.git , el autor debe ejecutar el comando git push :

 bash-4.4$ bash-4.4$ git push Enumerating objects: 7, done. Counting objects: 100% (7/7), done. Delta compression using up to 4 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 849 bytes | 849.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git <font color="#8b0000">b5e76a7..6b831e4</font> master -> master bash-4.4$ 

Se puede obtener más información sobre los comandos de git subrepo desde el archivo ReadMe.pod o en la línea de comandos

 bash-4.4$ git subrepo help <command> 

por ejemplo:

 bash-4.4$ git subrepo help clone 

Considere ahora todo lo que sucede por parte del usuario.

Obteniendo código por los usuarios

En este momento, cuando el usuario aún no ha recibido una actualización de la plataforma de repositorio up.git , su copia contiene un archivo README

 bash-4.4$ bash-4.4$ cd user/platform/ bash-4.4$ ls README bash-4.4$ 

que contiene una línea:

 bash-4.4$ bash-4.4$ cat README [master] platform 1.0.0 bash-4.4$ 

Después de romper los cambios del repositorio aguas arriba

 bash-4.4$ bash-4.4$ git pull remote: Enumerating objects: 7, done. remote: Counting objects: 100% (7/7), done. remote: Compressing objects: 100% (4/4), done. remote: Total 6 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (6/6), done. From /home/prog/0.4.1/remote/platform b5e76a7..6b831e4 master -> origin/master Updating <font color="#8b0000">b5e76a7..6b831e4</font> Fast-forward build-system/.gitrepo/config | 12 ++++++++++++ build-system/README | 3 +++ 2 files changed, 15 insertions(+) create mode 100644 build-system/.gitrepo/config create mode 100644 build-system/README bash-4.4$ 

el usuario tendrá a su disposición el código del subproyecto del sistema de construcción de exactamente la revisión que determinó el autor del proyecto. El usuario puede actualizar la revisión actual en cualquier momento usando el comando config :

 bash-4.4$ bash-4.4$ git subrepo config build-system/ commit Subrepo 'build-system' option 'commit' has value 'b2f507918f2821cb7dd90c33223ed5cc3c9922a2'. bash-4.4$ 

Es de destacar que el usuario no necesita realizar ajustes adicionales y puede confiar en el hecho de que el autor del proyecto le dio exactamente la revisión del sistema de compilación que es necesaria para que funcione la versión actual de la plataforma .

Esto es exactamente lo que buscaba el autor del proyecto.

Entregar cambios a un proyecto aguas arriba

Supongamos ahora que nuestro usuario es miembro del proyecto y puede realizar cambios no solo en el repositorio ascendente remote / platform.git , sino también en el repositorio ascendente del subproyecto remote / build-system.git .

Entonces, si el usuario realiza los cambios:

 bash-4.4$ bash-4.4$ cd build-system/ bash-4.4$ vim README bash-4.4$ cat README [master] build-system 1.0.1 bash-4.4$ bash-4.4$ git commit -a -m "update BS version to 1.0.1" [master d30b001] update BS version to 1.0.1 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ bash-4.4$ cd .. bash-4.4$ git log commit d30b001286b08708f5c30c1f5346a90e4339f969 (HEAD -> master) Author: user <___@_____> Date: Tue Oct 30 10:49:32 2018 +0300 update BS version to 1.0.1 . . . bash-4.4$ 

podrá colocarlos en repositorios aguas arriba de la siguiente manera:

 bash-4.4$ bash-4.4$ git subrepo push build-system/ Subrepo 'build-system' pushed to '../../remote/build-system.git' (master). bash-4.4$ 

 bash-4.4$ bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ bash-4.4$ git push Enumerating objects: 14, done. Counting objects: 100% (14/14), done. Delta compression using up to 4 threads Compressing objects: 100% (7/7), done. Writing objects: 100% (9/9), 992 bytes | 992.00 KiB/s, done. Total 9 (delta 1), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git d00be9f..deccb66 master -> master bash-4.4$ 

Trabajo directo con repositorio ascendente

Ahora considere lo que sucedió en el repositorio ascendente remote / build-system.git

 bash-4.4$ bash-4.4$ cd owner/build-system/ bash-4.4$ bash-4.4$ git pull remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /home/prog/0.4.1/remote/build-system b2f5079..d229920 master -> origin/master Updating b2f5079..d229920 Fast-forward README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ bash-4.4$ git log commit d229920c7de34405bc7b8d47f36d420987687908 (HEAD -> master, origin/master) Author: user <___@_____> Date: Tue Oct 30 10:49:32 2018 +0300 update BS version to 1.0.1 commit b2f507918f2821cb7dd90c33223ed5cc3c9922a2 Author: user <___@_____> Date: Tue Oct 30 10:05:30 2018 +0300 init build-system master 1.0.0 bash-4.4$ 

Es decir, el autor del proyecto recibió los cambios realizados por el participante del proyecto.

Por supuesto, el autor puede realizar cambios directamente en el repositorio ascendente del proyecto del sistema de compilación :

 bash-4.4$ bash-4.4$ cd owner/build-system/ bash-4.4$ bash-4.4$ vim README bash-4.4$ cat README [master] build-system 1.0.2 bash-4.4$ git commit -a -m "update build-system version to 1.0.2" [master 8255f59] update build-system version to 1.0.2 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Writing objects: 100% (3/3), 281 bytes | 281.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To /home/prog/0.4.1/remote/build-system.git d229920..8255f59 master -> master bash-4.4$ 

Y todos los participantes, así como los usuarios del proyecto principal, podrán recibir estos cambios utilizando el comando pull de git subrepo

 bash-4.4$ bash-4.4$ cd owner/platform/ bash-4.4$ bash-4.4$ git subrepo pull build-system/ Subrepo 'build-system' pulled from '../../remote/build-system.git' (master). bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ git push Enumerating objects: 11, done. Counting objects: 100% (11/11), done. Delta compression using up to 4 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 670 bytes | 670.00 KiB/s, done. Total 6 (delta 1), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git 6b831e4..b6f4a7b master -> master bash-4.4$ 

Conclusiones

Si el desarrollador no necesita almacenar el historial de subproyectos en el repositorio principal y, al entregar el código, opera con ramas en lugar de etiquetas fijas, entonces git-subrepo es bastante adecuado para organizar el trabajo diario.

Condicionalmente, una de las desventajas de git-subrepo es el hecho de que la operación de clonación de git subrepo solo es posible en relación con las ramas de subproyectos. En otras palabras, el usuario no puede conectar el subproyecto haciendo referencia a su etiqueta fija o una revisión específica, es decir, comandos como

 bash-4.4$ git subrepo clone ../../remote/build-system.git build-system -t 1.0.1 bash-4.4$ git subrepo clone ../../remote/build-system.git build-system 7f5d1113eb0bc6 

no valido

LITERATURA

• Git: fusión de subárbol
• Dominar git subtrees
• Dominar los submódulos git
• Git subrepo
• El modelo de gestión de módulos de ramificación y git para un proyecto grande