Git subrepo

Le projet git-subrepo existe depuis longtemps, cependant, il y a peu de références. L'auteur de git-subrepo est Ingy döt Net .

Si vous regardez l'historique des commits de la branche master du projet, il peut sembler que le projet s'est arrêté en développement il y a 2 ans. Cependant, le travail sur le projet est en cours et j'espère que la version 0.4.0 sera bientôt disponible.

Une propriété importante de cet outil est qu'il n'est pas nécessaire pour l'utilisateur d'installer git-subrepo jusqu'à ce que l'utilisateur décide de faire des commits dans le référentiel en amont des sous-projets. De plus, l'utilisateur reçoit une arborescence source entièrement préparée et configurée au moment de la copie du référentiel principal à l'aide de la commande git-clone (1) standard.

Lors du choix des moyens de prise en charge des sous-modules / sous-arbres / sous-projets du référentiel de conteneurs principal, le développeur détermine tout d'abord la gamme de capacités que tel ou tel mécanisme fournit et répond aux questions suivantes:

• s'il est nécessaire de conserver l'historique complet du sous-projet dans le référentiel principal ou suffisamment de validations écrasées;
• si la capacité à apporter des modifications du sous-projet au référentiel en amont du sous-arbre est nécessaire;
• Est-il nécessaire de connecter des balises fixes du référentiel en amont du sous-projet ou est-il possible de connecter des branches;
• s'il faudra supprimer à la fois les sous-projets eux-mêmes et, ce qui est devenu inutile, une partie de l'histoire de ces sous-projets;
• si l'utilisateur devra prendre des mesures pour configurer manuellement les sous-projets après le clonage du référentiel du projet principal;
• combien sera laborieuse la question de l'analyse de l'historique des sous-projets de connexion et des révisions spécifiques dont le sous-projet est issu;
• comment tel ou tel outil affectera la politique de gestion de la configuration de la source et dans quelle mesure cet outil compliquera le travail quotidien des ingénieurs.

Bien sûr, cette liste de questions ne peut pas refléter la totalité des paramètres d'entrée nécessaires pour le bon choix, mais pour un examen préliminaire des outils existants, elle est tout à fait suffisante et, en parlant du projet git-subrepo , nous invitons le lecteur à considérer ce projet à partir de ces positions.

Installation de Git-subrepo

Le paquet git-subrepo , du côté du développeur, peut être installé à la fois localement, dans son répertoire personnel et au niveau du système.

Dans le premier cas, il suffit de cloner le référentiel git-subrepo dans le répertoire souhaité, par exemple, ~ / bin :

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

et configurer des variables d'environnement

 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 vous regardez les variables définies dans le 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 

il est facile de découvrir qu'au niveau du système, git-subrepo est installé dans le répertoire où se trouve Git :

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

Ainsi, la commande d'installation de git-subrepo peut ressembler, par exemple, à ce qui suit:

 bash-4.4$ make PREFIX=/usr install 

La présence de la variable DESTDIR permet sans efforts supplémentaires (bien sûr, si nous ne sommes pas dans un environnement croisé) de créer un package pour n'importe quelle distribution Linux, ce qui peut être utile pour les ingénieurs DevOps.

Installez git-subrepo en tant que 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$ 

Pour analyser les capacités de git-subrepo, nous avons besoin d'un environnement de test simple où nous pouvons reproduire des scénarios de fonctionnement standard.

Environnement de test

Nous créons trois répertoires propriétaire , distant , utilisateur , dans lesquels nous plaçons des modèles de référentiels amont et local du développeur et de l'utilisateur.

 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$ 

Ici

L'auteur du projet et les utilisateurs ont leurs propres copies des référentiels en amont sur leurs machines, présentées dans notre exemple dans les répertoires propriétaire et utilisateur , respectivement.

La tâche de l'auteur est d'inclure les fonctionnalités suivantes dans l'arborescence principale de la plateforme en incluant le sous- projet builld-system dans l'arborescence principale:

• clonez le référentiel principal avec le sous - projet build-system inclus dans sa structure et ne vous inquiétez pas de la configuration des versions ou des révisions. Autrement dit, chaque branche du référentiel de plate - forme doit correspondre à une révision spécifique d'une branche particulière du référentiel du système de génération et l'utilisateur doit recevoir une arborescence source personnalisée en une seule opération git-clone (1) , sans aucune action supplémentaire.
• livrer leurs modifications au référentiel de projet en amont, à la fois dans le principal et dans l'auxiliaire.
• recevoir les modifications apportées par d'autres participants ou utilisateurs du projet, bien sûr, s'ils disposent des droits appropriés.

Considérez les actions de l'auteur qu'il doit mettre en œuvre pour mettre en œuvre ces exigences.

Connexion au sous-projet

Pour connecter un nouveau sous-arbre, utilisez la commande git subrepo clone , qui dans son but est similaire à la commande git-clone (1) . Le paramètre requis pour la commande est l' URL du référentiel distant. Vous pouvez également spécifier le répertoire dans lequel le sous-projet et la branche du référentiel distant seront situés. Nous travaillerons avec des branches principales, par conséquent, dans notre exemple, nous omettons les paramètres de commande inutiles.

Ainsi, l'auteur du projet, sur sa machine de travail, peut connecter le sous - projet build-system à l'aide de la commande git subrepo clone ../../remote/build-system.git/ build-system :

 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$ 

Tenez compte des changements survenus dans le référentiel de la plateforme locale:

 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$ 

L'historique du sous - projet build-system n'est pas livré à l'arborescence principale; nous n'avons qu'une seule validation écrasée, qui est accompagnée d'informations générales. Ces informations relèvent du contrôle de version dans le fichier ./build-system/.gitrepo/config :

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

Des informations sur les sous-projets peuvent être obtenues en utilisant la commande git subrepo config , par exemple, pour connaître la révision du projet en amont remote / build-system.git , qui vient d'arriver dans le référentiel principal, en utilisant la commande:

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

Il convient de mentionner que le package git-subrepo d'origine n'enregistre pas d'informations sur les sous-projets dans le fichier .gitrepo / config , mais dans le fichier .gitrepo .

Nous avons donc obtenu la dernière version de la branche principale du référentiel en amont remote / build-system.git et l' avons placée dans le sous - répertoire build-system du projet de plate - forme principale.

Pour apporter ces modifications au référentiel en amont remote / platform.git , l'auteur doit exécuter la commande 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$ 

Plus d'informations sur les commandes git subrepo peuvent être obtenues à partir du fichier ReadMe.pod ou sur la ligne de commande

 bash-4.4$ git subrepo help <command> 

par exemple:

 bash-4.4$ git subrepo help clone 

Considérez maintenant tout ce qui se passe de la part de l'utilisateur.

Obtention de code par les utilisateurs

Pour le moment, lorsque l'utilisateur n'a pas encore reçu de mise à jour du référentiel amont platform.git , sa copie contient un fichier README

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

contenant une ligne:

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

Après avoir interrompu les modifications du référentiel en amont

 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$ 

l'utilisateur aura à sa disposition le code du sous - projet build-system de cette révision exactement, qui a été déterminé par l'auteur du projet. L'utilisateur peut mettre à jour la révision actuelle à tout moment en utilisant la commande config :

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

Il est à noter que l'utilisateur n'a pas besoin de faire de réglages supplémentaires et il peut compter sur le fait que l'auteur du projet lui a donné exactement la révision du système de construction nécessaire au fonctionnement de la version actuelle de la plateforme .

C'est ce que cherchait l'auteur du projet.

Apporter des modifications à un projet en amont

Supposons maintenant que notre utilisateur soit membre du projet et qu'il soit autorisé à apporter des modifications non seulement au référentiel amont remote / platform.git , mais également au référentiel amont du sous-projet remote / build-system.git .

Ensuite, si l'utilisateur effectue les modifications:

 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$ 

il pourra les placer dans des référentiels amont comme suit:

 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$ 

Travail direct avec le référentiel en amont

Considérez maintenant ce qui s'est passé dans le référentiel en amont 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$ 

Autrement dit, l'auteur du projet a reçu les modifications apportées par le participant au projet.

Bien sûr, l'auteur peut apporter des modifications directement au référentiel amont du projet build-system :

 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$ 

Et tous les participants, ainsi que les utilisateurs du projet principal, pourront recevoir ces modifications à l'aide de la commande git subrepo pull

 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$ 

Conclusions

Si le développeur n'a pas besoin de stocker l'historique des sous-projets dans le référentiel principal et, lors de la livraison du code, il fonctionne avec des branches plutôt qu'avec des balises fixes, alors git-subrepo est tout à fait approprié pour organiser le travail quotidien.

Conditionnellement, l'un des inconvénients de git-subrepo est le fait que l'opération de clonage de git subrepo n'est possible que par rapport aux branches de sous-projet. En d'autres termes, l'utilisateur ne peut pas connecter le sous-projet en se référant à sa balise fixe ou à une révision spécifique, c'est-à-dire des commandes comme

 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 

non valide.

LITTÉRATURE:

• Git - Fusion de sous-arborescences
• Maîtriser les sous-arbres git
• Maîtriser les sous-modules Git
• Git subrepo
• Le modèle de gestion des modules de branchement et git pour un grand projet