submódulo git no enviado a producción
Acabo de crear un nuevo repositorio con dos submódulos. Funciona bien en local, pero cuando se envía a la producción, los submódulos no están allí. Cada directorio raíz de submódulo está presente, pero no hay archivos dentro
git version 2.27.0
Crear repositorio en producción
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
Empujar a producción desde dev / local
git push production master
git statusdice que todo está actualizado. Incluso si se llama en la carpeta del submódulo. Intenté eliminar la carpeta del submódulo en el repositorio local, enviar / enviar al repositorio. Luego, git push production masterla carpeta del submódulo raíz se eliminó en el servidor de producción. Luego tratando de agregarlo nuevamente
# 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.
Luego comprometerse con el repositorio y luego git push production master. El mismo problema. En producción, las carpetas raíz de los submódulos están presentes pero no hay archivos en los directorios.
Cuando navego por el repositorio en github, los submódulos están correctamente vinculados.
Todo funciona en el repositorio local.
Respuestas
Las carpetas de los submódulos no están vacías en github (o en el repositorio local), pero al pasar a producción están
Eso es lo esperado: un submódulo se compone de:
- una URL registrada en el
.gitmodules - a gitlink, una entrada especial en el índice que representa el SHA1 del árbol raíz del repositorio de submódulos.
Cuando clona un repositorio remoto con submódulos (usando la git clone --recurse-submodulesopción, esos repositorios de submódulos se clonan ellos mismos y se revisan en el SHA1 representado por ese gitlink.
"Empujar a producción" es complicado porque no se supone que debe empujar a un repositorio verificado (no desnudo) (incluso aunque técnicamente puede hacerlo ).
Es mejor enviar a un repositorio vacío en producción, que usará un enlace posterior a la recepción para restaurar los archivos (incluido el contenido del submódulo, usando git restore --recurse-submodules)
Después de la discusión :
Necesita que el servidor de producción tenga una clave SSH pública registrada en su cuenta, ya que los submódulos están registrados en el
.gitmodulescon una URL SSH.El script posterior a la recepción se convierte en:
#!/bin/bash cd /var/www/repo git --git-dir=/var/git_repos/repo.git --work-tree=. restore --recurse-submodules :/
Con git submodule, aparentemente no puede configurar el árbol de trabajo
Eso significa que, si hay submódulos involucrados, su carpeta actual debe ser el árbol de trabajo.
Entonces puede hacer comandos como git checkout/ git restorecon --recurse-submodules, o git submodule update --initincluso con un git-dir ( --git-dir=/path/to/bare/repo.git) diferente.
Los submódulos se actualizarán porque su árbol de trabajo actual es el correcto.
Si está en cualquier lugar que /var/www/repo, incluso si especifica git --work-tree=/var/www/repo ..., ninguno de los comandos mencionados anteriormente git checkout/ git restorecon --recurse-submodules, o git submodule update --initfuncionará para los submódulos de su repositorio.
Es decir: sus /var/www/repoarchivos se restaurarán, pero los submódulos permanecerán vacíos.