tag - qué tipos de etiquetas existen en git

Git se compromete a un submódulo común(rama maestra)

Question

Tengo dos o más proyectos (llamémoslos ProjectFoo y ProjectBar ) teniendo algún código común que coloco en un submódulo .

Mi entendimiento es que si realizo cambios en un submódulo desde ProjectFoo , será en un encabezado separado que solo todos los clones de ProjectFoo pueden ver:

(master) $ cd ProjectFooBarCommoneSubmodule/
(master) $ git commit -am "Common code fix."
(56f21fb0...) $ git push
Everything up-to-date

Eso es probablemente porque la rama master no ha cambiado. Probablemente podría hacer algo como git checkout master && git merge Everything up-to-date pero eso parece bastante feo. Puede ser un git reset --hard master haría lo mismo pero parece aún más feo.

¿Cómo tener un código común compartido por proyecto, actualizado desde los proyectos que lo usan? En otras palabras, comprometerse a ese submódulo debería actualizar todos los diversos repositorios ( repositorios, no solo clones ) que usan este mismo submódulo.

---- EDITAR ----

Visiblemente mi repositorio desprotegido estaba en mal estado y roto. Debería haber funcionado así desde el principio (en ProjectFoo en este ejemplo):

(master) $ cd ProjectFooBarCommoneSubmodule/
(master) $ git commit -am "Common code fix."
(master) $ git push
....
   fbfdd71..0acce63  master -> master
(master) $ cd ..
(master) $ git add ProjectFooBarCommoneSubmodule
(master) $ git commit -m "Submodule update."

Luego, para obtener ese cambio en otros proyectos, como ProjectBar :

(master) $ cd ProjectFooBarCommoneSubmodule/
(master) $ git pull

Se actualizaría al último código común. Es posible que se requiera un git checkout master si está en una cabeza separada.

Answer 1

Darse cuenta:

git submodule foreach ''git commit -a''

fallará si uno de los submódulos no contiene ningún compromiso.

Para deshacerte de esto, debes forzar el resultado del comando a 0.

git submodule foreach "git commit -am ''your comment'' || echo '' ''"

Al usar el canal de eco, obliga a que todo el comando regrese con 0 y continúe ejecutando el comando de confirmación en los otros submódulos

Answer 2

En el submodule : git push origin HEAD:master

Answer 3

Para fusionar el cambio de HEAD desconectado en maestro, ejecute:

git rebase HEAD master

luego checkout master (use -f para forzar):

git checkout master

Si tiene que tratar con varios submódulos, use: git submodule foreach , por ejemplo

git submodule foreach git pull origin master -r

Answer 4

Respuesta corta:

cd ProjectFooBarCommoneSubmodule
git checkout master
<Do your editing>
git commit --all -m "Lots of fixes"
git push submodule_origin master
cd ..

git add ProjectFooBarCommoneSubmodule
git commit -m "Bumped up the revision of ProjectFooBarCommoneSubmodule"
git push origin master

El más largo:

Los submódulos de Git son un mecanismo de dependencia, donde el proyecto principal (por ejemplo, A) define una revisión específica en un subproyecto (por ejemplo, B), que se usará en el proyecto de construcción A. Para que la herramienta sea útil, el comportamiento debe ser predecible Desde el punto de vista A: s. Las dependencias no pueden cambiar, a menos que alguien decida incorporar el cambio al proyecto A. Pueden ocurrir todo tipo de cosas desagradables, si los cambios del proyecto B se importan automáticamente, de los cuales los errores de compilación son probablemente los mejores, ya que A notaría los fallos de inmediato. Es por esto que B: s cabeza se mantiene en estado separado.

El estado de B se almacena en A (verifique el git submodule status ), y se debe hacer un cambio de revisión y confirmar en A, para que tenga algún efecto. Esto es lo que sucede en el ejemplo anterior, A cambia el número de revisión almacenado en el repositorio y aumenta la versión a la más reciente. El proceso también tendrá que repetirse en el otro repositorio principal, por lo que no habrá un conmutador automático de "uso maestro" AFAIK.

Por cierto El capítulo del libro de Git sobre submódulos y la página de manual de submódulos contienen mucha información útil acerca de los submódulos, como uso normal y también las dificultades típicas. Vale la pena echarle un vistazo.

EDIT: voy a tratar de explicar esto mejor

Me tomé la libertad de crear proyectos de ejemplo en mi cuenta de github . Las confirmaciones no tienen sentido y contienen basura, pero la configuración debería estar bien. Por favor, compruébelo para seguir.

Tanto ProjectFoo como ProjectBar comparten el código en el submódulo común.

ProjectFooBarCommoneSubmodule: master is 6850e4e4c1fac49de398

En ProjectFoo:

git submodule status

-6850e4e4c1fac49de39890703f21486ca04b87a0 común

En ProjectBar:

git submodule status

-6850e4e4c1fac49de39890703f21486ca04b87a0 común

Así que ambos apuntan a la misma revisión, ¿verdad? El truco aquí es ver que ProjectFoo y ProjectBar apuntan a la revisión (6850e4e4c1fac49de39890703f21486ca04b87a0) no a la rama (maestra), aunque son lo mismo. El primero es una cabeza separada, y el otro una rama con nombre.

Si desea realizar algunas correcciones en ProjectFooBarCommoneSubmodule, puede ir al subdirectorio en, por ejemplo, ProjectFoo, y elegir la rama en lugar de la revisión :

git checkout master 
<Do your coding and pushing here>

Luego vaya a un directorio hacia arriba y verifique el estado del submódulo de git. Debería decirte que ahora no estás sincronizado. P.ej

git submodule status

+ e24bd2bf45d52171a63b67ac05cd4be0ac965f60 common (heads / master-1-ge24bd2b)

Ahora puede hacer un agregado de git, para establecer la referencia a este commit en particular (ge24bd ...), hacer un commit, y después de esto, el submódulo de referencia apunta a esta revisión, que también es maestra en ProjectFooBarCommoneSubmodule.

Ahora necesitas actualizar la referencia en ProjectBar también. Vaya a ProjectBar / common, y haga git fetch origin (esta es una combinación de avance rápido), do

git checkout master 
cd ..
git add common
git commit -m "Bumped up the revision"
git push origin master # to publish the revision bump to everybody else

Por lo tanto, al igual que con cualquier repositorio de git, no es necesario trabajar en una cabeza separada. Puede trabajar en el maestro o crear una rama con nombre. De cualquier manera, asegúrate de que upstream contenga los cambios del modulo ProjectFooBarCommone, o romperás tanto ProjectFoo como ProjectBar, si hacen referencia a algo que no existe. Espero que esto lo explique mejor.

Answer 5

Si quieres comprometer y empujar todos los submódulos a la vez haz:

git submodule foreach ''git commit -a'' ;
git submodule foreach ''git push --all'' ;
git commit -a && /
git push --all --recurse-submodules=on-demand

Answer 6

Solamente lo hago:

git submodule foreach git push -u origin master