Git subrepo

Das git-subrepo-Projekt existiert schon lange, es gibt jedoch nur wenige Hinweise darauf. Der Autor von git-subrepo ist Ingy döt Net .

Wenn Sie sich die Geschichte der Commits des Hauptzweigs des Projekts ansehen, scheint es, dass das Projekt vor 2 Jahren in der Entwicklung gestoppt wurde. Die Arbeiten an dem Projekt sind jedoch im Gange und ich hoffe, dass Version 0.4.0 bald veröffentlicht wird.

Eine wichtige Eigenschaft dieses Tools ist, dass der Benutzer git-subrepo erst installieren muss, wenn der Benutzer festlegt , Commits im Upstream-Repository von Teilprojekten durchzuführen . Darüber hinaus erhält der Benutzer zum Zeitpunkt des Kopierens des Hauptrepositorys mit dem Standardbefehl git-clone (1) einen vollständig vorbereiteten und konfigurierten Quellbaum .

Bei der Auswahl der Mittel zur Unterstützung von Submodulen / Teilbäumen / Teilprojekten des Hauptcontainer-Repositorys bestimmt der Entwickler zunächst den Funktionsumfang, den dieser oder jener Mechanismus bietet, und beantwortet die folgenden Fragen:

• ob es notwendig ist, den vollständigen Verlauf des Teilprojekts im Haupt-Repository oder genügend gequetschte Commits zu speichern;
• ob die Fähigkeit erforderlich ist, Änderungen vom Teilprojekt an das vorgelagerte Repository des Teilbaums zu liefern;
• Müssen feste Tags des Upstream-Repositorys des Teilprojekts verbunden werden, oder können Zweige verbunden werden?
• ob es notwendig sein wird, sowohl die Teilprojekte selbst als auch, was unnötig geworden ist, einen Teil der Geschichte dieser Teilprojekte weiter zu entfernen;
• ob der Benutzer nach dem Klonen des Repositorys des Hauptprojekts Maßnahmen ergreifen muss, um Teilprojekte manuell zu konfigurieren;
• Wie mühsam wird die Frage sein, die Geschichte der Verbindung von Teilprojekten und spezifischen Revisionen, aus denen das Teilprojekt stammt, zu analysieren?
• Wie sich dieses oder jenes Tool auf die Quellkonfigurationsverwaltungsrichtlinie auswirkt und wie sehr dieses Tool die tägliche Arbeit der Ingenieure erschwert.

Natürlich kann diese Liste von Fragen nicht die Fülle der Eingabeparameter widerspiegeln, die für die richtige Auswahl erforderlich sind, aber für eine vorläufige Überprüfung der vorhandenen Tools ist sie völlig ausreichend, und wenn wir vom git-subrepo-Projekt sprechen , fordern wir den Leser auf, dieses Projekt von diesen Positionen aus zu betrachten.

Git-Subrepo-Installation

Das git-subrepo-Paket kann auf Entwicklerseite sowohl lokal, in seinem Home-Verzeichnis als auch auf Systemebene installiert werden.

Im ersten Fall reicht es aus, das git-subrepo-Repository in das gewünschte Verzeichnis zu klonen, z. B. ~ / bin :

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

und Umgebungsvariablen einrichten

 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 

Wenn Sie sich die im Makefile von git-subrepo definierten Variablen ansehen :

 # 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 ist leicht herauszufinden, dass git-subrepo auf Systemebene in dem Verzeichnis installiert ist , in dem sich Git befindet:

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

So kann der Befehl zum Installieren von git-subrepo beispielsweise wie folgt aussehen:

 bash-4.4$ make PREFIX=/usr install 

Das Vorhandensein der DESTDIR- Variablen ermöglicht es ohne zusätzlichen Aufwand (natürlich, wenn wir uns nicht in einer Umgebung befinden), ein Paket für jede Linux- Distribution zu erstellen, das für DevOps-Ingenieure nützlich sein kann.

Installieren Sie git-subrepo als 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$ 

Um die Fähigkeiten von git-subrepo zu analysieren , benötigen wir eine einfache Testumgebung, in der wir Standardbetriebsszenarien reproduzieren können.

Testumgebung

Wir erstellen drei Verzeichnisse Eigentümer , Remote , Benutzer , in denen wir Modelle von Upstream- und lokalen Repositorys des Entwicklers und Benutzers platzieren.

 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$ 

Hier

Der Autor des Projekts und die Benutzer haben ihre eigenen Kopien der vorgelagerten Repositorys auf ihren Computern, die in unserem Beispiel im Eigentümer- bzw. Benutzerverzeichnis dargestellt werden.

Die Aufgabe des Autors besteht darin, die folgenden Funktionen in den Hauptbaum der Plattform aufzunehmen, indem das Teilprojekt builld-system in den Hauptbaum aufgenommen wird:

• Klonen Sie das Haupt-Repository mit dem in seiner Struktur enthaltenen Build-System- Teilprojekt und sorgen Sie sich nicht um das Einrichten von Versionen oder Revisionen. Das heißt, jeder Zweig des Plattform- Repositorys sollte einer bestimmten Revision eines bestimmten Zweigs des Build-System- Repositorys entsprechen, und der Benutzer sollte einen angepassten Quellbaum in einer git-clone (1) -Operation ohne zusätzliche Aktionen erhalten.
• Übermitteln Sie ihre Änderungen an das vorgelagerte Projekt-Repository, sowohl im Haupt- als auch im Hilfsprojekt.
• Sie erhalten natürlich Änderungen, die von anderen Projektteilnehmern oder Benutzern vorgenommen wurden, wenn diese über die entsprechenden Rechte verfügen.

Berücksichtigen Sie die Aktionen des Autors, die er implementieren muss, um diese Anforderungen zu implementieren.

Teilprojektverbindung

Verwenden Sie zum Verbinden eines neuen Teilbaums den Befehl git subrepo clone , der in seinem Zweck dem Befehl git-clone (1) ähnelt. Der erforderliche Parameter für den Befehl ist die URL des Remote-Repositorys. Sie können auch das Verzeichnis angeben, in dem sich das Teilprojekt und der Remote-Repository-Zweig befinden. Wir werden mit Hauptzweigen arbeiten, daher lassen wir in unserem Beispiel unnötige Befehlsparameter weg.

Der Autor des Projekts kann also auf seinem Arbeitscomputer das Build-System- Teilprojekt mit dem Befehl git subrepo clone verbinden ./../remote/build-system.git/ build-system Befehl :

 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$ 

Überlegen Sie, welche Änderungen im lokalen Plattform- Repository vorgenommen wurden:

 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$ 

Der Verlauf des Build-System- Teilprojekts wird nicht an den Hauptbaum übergeben, es gibt nur ein Squashed-Commit, das von Hintergrundinformationen begleitet wird. Diese Informationen unterliegen der Versionskontrolle in der Datei ./build-system/.gitrepo/config :

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

Informationen zu Teilprojekten können mit dem Befehl git subrepo config abgerufen werden, um beispielsweise die Revision des Upstream-Projekts remote / build-system.git , das gerade im Hauptrepository eingetroffen ist, mithilfe des folgenden Befehls zu ermitteln:

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

Es sollte erwähnt werden, dass das ursprüngliche git-subrepo- Paket keine Informationen zu Teilprojekten in der .gitrepo / config- Datei, sondern in der .gitrepo- Datei speichert.

Wir haben also die neueste Version des Hauptzweigs des Upstream-Repositorys remote / build-system.git erhalten und im Unterverzeichnis build-system des Hauptplattformprojekts abgelegt.

Um diese Änderungen an das Upstream-Repository remote / platform.git zu senden , muss der Autor den Befehl git push ausführen:

 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$ 

Weitere Informationen zu git subrepo-Befehlen erhalten Sie in der ReadMe.pod- Datei oder in der Befehlszeile

 bash-4.4$ git subrepo help <command> 

zum Beispiel:

 bash-4.4$ git subrepo help clone 

Betrachten Sie nun alles, was seitens des Benutzers passiert.

Code von Benutzern abrufen

In dem Moment, in dem der Benutzer noch kein Update für die Upstream-Repository- Plattform.git erhalten hat , enthält seine Kopie eine README-Datei

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

mit einer Zeile:

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

Nach dem Aufbrechen von Upstream-Repository-Änderungen

 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$ 

Dem Benutzer steht der Code des Build-System- Teilprojekts zur Verfügung, der genau der vom Autor des Projekts festgelegten Revision entspricht. Der Benutzer kann die aktuelle Version jederzeit mit dem Befehl config aktualisieren:

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

Es ist bemerkenswert, dass der Benutzer keine zusätzlichen Einstellungen vornehmen muss und sich darauf verlassen kann, dass der Autor des Projekts ihm genau die Build-System- Revision gegeben hat, die erforderlich ist, damit die aktuelle Version der Plattform funktioniert.

Das hat der Autor des Projekts gesucht.

Stellen Sie Änderungen an einem vorgelagerten Projekt bereit

Angenommen, unser Benutzer ist jetzt Mitglied des Projekts und darf Änderungen nicht nur am Upstream-Repository remote / platform.git , sondern auch am Upstream-Repository des Teilprojekts remote / build-system.git vornehmen .

Wenn der Benutzer dann die Änderungen vornimmt:

 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$ 

Er kann sie wie folgt in vorgelagerte Repositories stellen:

 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$ 

Direkte Arbeit mit dem Upstream-Repository

Betrachten Sie nun, was im Upstream-Repository remote / build-system.git passiert ist

 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$ 

Das heißt, der Autor des Projekts hat die vom Projektteilnehmer vorgenommenen Änderungen erhalten.

Natürlich kann der Autor Änderungen direkt am Upstream-Repository des Build-System- Projekts vornehmen:

 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$ 

Alle Teilnehmer sowie Benutzer des Hauptprojekts können diese Änderungen mit dem Befehl git subrepo pull erhalten

 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$ 

Schlussfolgerungen

Wenn der Entwickler den Verlauf von Teilprojekten nicht im Haupt-Repository speichern muss und bei der Bereitstellung des Codes eher mit Zweigen als mit festen Tags arbeitet, eignet sich git-subrepo gut für die Organisation der täglichen Arbeit.

Bedingt ist einer der Nachteile von git-subrepo die Tatsache, dass die git-subrepo -Klonoperation nur in Bezug auf die Teilprojektzweige möglich ist. Mit anderen Worten, der Benutzer kann das Teilprojekt nicht unter Bezugnahme auf sein festes Tag oder eine bestimmte Revision verbinden, dh Befehle wie

 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 

nicht gültig.

LITERATUR:

• Git - Subtree Merging
• Git-Teilbäume beherrschen
• Git-Submodule beherrschen
• Git subrepo
• Das Verwaltungsmodell für Verzweigungs- und Git-Module für ein großes Projekt