the - ¿Cuál es el punto de ''git submodule init''?
gitlab submodules (2)
Fondo
Para rellenar los submódulos de un repositorio, uno invoca típicamente :
git submodule init
git submodule update
En este uso, git submodule init
parece hacer solo una cosa: llenar .git/config
con información que ya está en .gitmodules
.
¿Cuál es el punto de esto?
¿No podría git submodule update
simplemente usar la información de .gitmodules
? Esto evitaría tanto:
- un comando innecesario (
git submodule init
); y - una duplicación innecesaria de datos (contenido de
.gitmodules
en.git/config
).
Pregunta
Ya sea:
- hay casos de uso para
git submodule init
que no conozco (en cuyo caso, ¡por favor, escúcheme!); si no -
git submodule init
es cruft que podría ser desaprobado en Git sin ningún daño.
¿Cuál de estos es verdad?
Al leer la documentation git submodule
, hay un caso de uso que justifica aparentemente la existencia de git submodule init
como un comando independiente.
Si un usuario que ha clonado un repositorio desea usar una URL diferente para un submódulo que el especificado por el repositorio ascendente, ese usuario puede:
git submodule init
vim .git/config # Alter submodule URL as desired, without changing .gitmodules
# or polluting history.
git submodule update
Imagine que el repositorio tiene 10 submódulos y está interesado en solo 2 submódulos de estos. En tal caso, es posible que desee obtener actualizaciones de solo estos 2 submódulos del repositorio remoto de vez en cuando. git init
funciona bien para esto, porque una vez que ejecute el comando git init
para estos 2 submódulos, git submodule update --remote
solo se aplica a ellos.
Si a alguien le gusta mi respuesta, corrija mis errores en inglés.
Se adjuntan dos flujos de trabajo de demostración.
Workflow1: Los submódulos son bibliotecas que utilizan varios proyectos.
Creo que este es uno de los casos de uso más comunes.
Acabas de clonar "mi proyecto".
git clone https://example.com/demo/my-project
Y la superficie de su estructura es como abajo.
Los contenidos de .gitmodules.
[submodule "lib1"]
path = lib1
url = https://example.com/demo/lib1
[submodule "lib2"]
path = lib2
url = https://example.com/demo/lib2
[submodule "lib3"]
path = lib3
url = https://example.com/demo/lib3
[submodule "lib4"]
path = lib4
url = https://example.com/demo/lib4
Desea refactorizar el código code1.js
que hace referencia a lib1 y lib2, lo que significa que no necesita clonar y desproteger lib3 y lib4. Así que simplemente ejecuta el siguiente comando.
git submodule init lib1 lib2
Ahora veamos los contenidos de .git/config
...
[submodule "lib1"]
active = true
url = https://example.com/demo/lib1
[submodule "lib2"]
active = true
url = https://example.com/demo/lib2
Esto significa algo así como "Listo para actualizar lib1 y lib2 desde example.com/demo".
En este punto, los directorios lib1 y lib2 están vacíos.
Puede clonar y desproteger lib1 y lib2 con un solo comando.
git submodule update
Ahora puede refactorizar code1.js
sin errores de importación.
Los submódulos son solo referencias a ciertos compromisos. Entonces, cuando desee actualizar las bibliotecas a nuevas versiones, debe actualizar las referencias. Puedes hacerlo por el siguiente comando.
git submodule update --remote
Ahora puede ver lo útil que es inicializar solo los submódulos que necesita.
Flujo de trabajo 2: cada submódulo es un proyecto y un gran proyecto superior los incluye.
Soy un fan de esto.
Se clona "proyecto principal".
git clone https://example.com/demo/main-project
Y la superficie de su estructura es como abajo.
Puedes ver un directorio llamado "compartido". Hay una regla en este flujo de trabajo: si desea utilizar códigos compartidos del proyecto principal en su proyecto, debe crear el proyecto como un submódulo de proyecto principal.
Me gusta poner las clases de entidad en un directorio compartido como el siguiente.
De vuelta al flujo de trabajo del submódulo, el contenido de .gitmodules es como el siguiente.
[submodule "sub-project1"]
path = sub-project1
url = https://example.com/demo/sub-project1
[submodule "sub-project2"]
path = sub-project2
url = https://example.com/demo/sub-project2
[submodule "sub-project3"]
path = sub-project3
url = https://example.com/demo/sub-project3
[submodule "sub-project4"]
path = sub-project4
url = https://example.com/demo/sub-project4
Esta vez desea refactorizar algún código en el directorio compartido del proyecto principal y sabe que solo el subproyecto1 y el subproyecto2 hacen referencia al código compartido, lo que significa que no necesita clonar y retirar el subproyecto3 y el subproyecto4. . Así que simplemente ejecuta el siguiente comando.
git submodule init sub-project1 sub-project2
Y como mencioné en workflow1, debe ejecutar el siguiente comando para clonar y desprotegerlos.
git submodule update
¿Tendría que git submodule update --remote
en este caso? ¿O incluso tengo que iniciar y actualizar los submódulos para refactorizar el código en el directorio compartido? Sí, debido a que tiene que ejecutar pruebas en los submódulos después de refactorizar el código compartido y si alguna actualización de los submódulos se confirma y se envía al repositorio remoto mientras está refactorizando, entonces necesita obtenerlos mediante la git submodule update --remote
.
Si a alguien le gusta mi respuesta, corrija mis errores en inglés.