Podmoduł git nie został przeniesiony do produkcji
Właśnie utworzyłem nowe repozytorium z dwoma modułami podrzędnymi. Działa dobrze na lokalnym, ale podczas wypychania do produkcji podmodułów nie ma. Każdy katalog główny modułu podrzędnego jest obecny, ale nie zawiera żadnych plików
git version 2.27.0
Utwórz repozytorium na produkcji
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
Przechodzenie do produkcji z dev / local
git push production master
git status
mówi, że wszystko jest aktualne. Nawet jeśli jest wywoływany w folderze modułu podrzędnego. Próbowałem usunąć folder modułu podrzędnego w repozytorium lokalnym, zatwierdzić / wypchnąć do repozytorium. Następnie git push production master
główny folder modułu podrzędnego został usunięty na serwerze produkcyjnym. Następnie spróbuj dodać go ponownie
# 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.
Następnie zatwierdzam do repozytorium, a następnie git push production master
. Ten sam problem. W produkcji istnieją foldery główne modułów podrzędnych, ale w katalogach nie ma plików.
Kiedy przeglądam repozytorium na githubie, podmoduły są poprawnie połączone.
Wszystko działa w lokalnym repozytorium

Odpowiedzi
Foldery podmodułów nie są puste na githubie (lub w lokalnym repozytorium), ale podczas wypychania do produkcji są
To jest oczekiwane: podmoduł składa się z:
- adres URL zarejestrowany w
.gitmodules
- a gitlink, specjalny wpis w indeksie, który reprezentuje SHA1 drzewa głównego repozytorium podmodułów.
Kiedy klonujesz zdalne repozytorium za pomocą git clone --recurse-submodulesmodułów podrzędnych (używając tej opcji, te repozytoria modułów podrzędnych są klonowane same i wypisywane na SHA1 reprezentowanym przez ten gitlink.
„Wypychanie do produkcji” jest trudne, ponieważ nie powinno się wypychać do wyewidencjonowanego (nie-nagiego) repozytorium (nawet jeśli technicznie można to zrobić ).
Jest lepiej pchnąć do gołego repozytorium na produkcję, która będzie używać posta-otrzymywać hak do przywracania plików (w tym zawartości modułem za pomocą git restore --recurse-submodules)
Po dyskusji :
Serwer produkcyjny musi mieć publiczny klucz SSH zarejestrowany na koncie, ponieważ moduły podrzędne są zarejestrowane w
.gitmodules
adresie URL SSH.Skrypt po odbiorze staje się:
#!/bin/bash cd /var/www/repo git --git-dir=/var/git_repos/repo.git --work-tree=. restore --recurse-submodules :/
Dzięki git submodule, to nie można ustawić drzewa pracuje widocznie
Oznacza to, że jeśli chodzi o moduły podrzędne, bieżący folder musi być drzewem roboczym.
Następnie możesz wykonywać polecenia takie jak git checkout
/ git restore
with --recurse-submodules
lub git submodule update --init
nawet z innym git-dir ( --git-dir=/path/to/bare/repo.git
).
Podmoduły zostaną zaktualizowane, ponieważ bieżące drzewo robocze jest właściwe.
Jeśli jesteś w dowolnym miejscu niż /var/www/repo
, nawet jeśli określisz git --work-tree=/var/www/repo ...
, żadne z wyżej wymienionych poleceń git checkout
/ git restore
z --recurse-submodules
lub nie git submodule update --init
będzie działać dla podmodułów twojego repozytorium.
To znaczy: Twoje /var/www/repo
pliki zostaną przywrócone, ale moduły podrzędne pozostaną puste.