Git-Submodul nicht in Produktion geschoben
Habe gerade ein neues Repository mit zwei Submodulen erstellt. Es funktioniert gut auf lokaler Ebene, aber wenn Sie zur Produktion gehen, sind die Submodule nicht vorhanden. Jedes Submodul-Stammverzeichnis ist vorhanden, es befinden sich jedoch keine Dateien darin
git version 2.27.0
Erstellen Sie ein Repo für die Produktion
git --bare init
cd hooks && touch post-receive && chmod +x post-receive
cat hooks/post-receive
#/bin/sh
git --work-tree=/var/www/repo --git-dir=/var/git_repos/repo.git checkout -f
Pushing zur Produktion von dev / local
git push production master
git statussagt, dass alles auf dem neuesten Stand ist. Auch wenn es im Submodul-Ordner aufgerufen wird. Haben versucht, den Submodul-Ordner im lokalen Repository zu löschen, Commit / Push zum Repository. Dann wurde git push production masterder Stamm-Submodul-Ordner auf dem Produktionsserver gelöscht. Versuchen Sie dann erneut, es hinzuzufügen
# git submodule add [email protected]:alias/repo_name.git php/repo/repo_name
Cloning into '/var/www/project/php/repo/repo_name'...
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 19 (delta 8), reused 19 (delta 8), pack-reused 0
Receiving objects: 100% (19/19), 8.62 KiB | 8.62 MiB/s, done.
Resolving deltas: 100% (8/8), done.
Dann Commit zum Repository und dann git push production master. Dasselbe Problem. In der Produktion sind die Stammordner der Submodule vorhanden, aber keine Dateien in den Verzeichnissen.
Wenn ich das Repository auf Github durchsuche, sind die Submodule korrekt verknüpft.
Alles funktioniert im lokalen Repository
Antworten
Die Submodul-Ordner sind auf Github (oder im lokalen Repo) nicht leer, aber wenn sie in die Produktion verschoben werden, sind sie leer
Das wird erwartet: Ein Submodul besteht aus:
- eine URL, die in der registriert ist
.gitmodules - a gitlink, ein spezieller Eintrag im Index, der den SHA1 des Stammbaums des Submodul-Repositorys darstellt.
Wenn Sie ein Remote-Repository mit Submodulen klonen (mit dieser git clone --recurse-submodulesOption werden diese Submodul-Repositorys selbst geklont und an der durch diesen Gitlink dargestellten SHA1 ausgecheckt.
"Pushing to Production" ist schwierig, da Sie nicht in ein ausgechecktes (nicht nacktes) Repository pushen sollen (auch wenn Sie dies technisch tun können ).
Es ist besser, in der Produktion auf ein nacktes Repository zu pushen, das einen Post-Receive-Hook verwendet , um die Dateien (einschließlich des Inhalts des Submoduls git restore --recurse-submodules) wiederherzustellen.
Nach der Diskussion :
Für den Produktionsserver muss ein öffentlicher SSH-Schlüssel in Ihrem Konto registriert sein, da die Submodule in der
.gitmodulesmit einer SSH-URL registriert sind .Das Post-Receive-Skript lautet:
#!/bin/bash cd /var/www/repo git --git-dir=/var/git_repos/repo.git --work-tree=. restore --recurse-submodules :/
Mit git submodulekönnen Sie den Arbeitsbaum anscheinend nicht festlegen
Das heißt, wenn Submodule beteiligt sind, muss Ihr aktueller Ordner der Arbeitsbaum sein.
Dann können Sie Befehle wie git checkout/ git restoremit --recurse-submodulesoder git submodule update --initsogar mit einem anderen Git-Verzeichnis ( --git-dir=/path/to/bare/repo.git) ausführen .
Die Submodule werden aktualisiert, da Ihr aktueller Arbeitsbaum der richtige ist.
Wenn Sie sich irgendwo befinden /var/www/repo, selbst wenn Sie dies angeben git --work-tree=/var/www/repo ..., keiner der oben genannten Befehle git checkout/ git restoremit --recurse-submodulesoder git submodule update --initfür die Submodule Ihres Repos funktioniert.
Das heißt: Ihre /var/www/repoDateien werden wiederhergestellt, aber die Submodule bleiben leer.