git resetse trata de mudarse HEAD, y generalmente la rama ref .
Pregunta: ¿qué pasa con el árbol de trabajo y el índice?
Cuando se emplea con --soft, movimientos HEAD, más a menudo posible actualizar el árbitro rama, y sólo elHEAD .
Esto difiere de commit --amendcomo:
- no crea una nueva confirmación.
- en realidad puede mover HEAD a cualquier confirmación (ya
commit --amendque solo se trata de no mover HEAD, mientras permite rehacer la confirmación actual)
Acabo de encontrar este ejemplo de combinación:
- una fusión clásica
- una fusión de subárbol
todo en uno (pulpo, ya que hay más de dos ramas fusionadas) cometer fusión.
Tomas "wereHamster" Carnecky explica en su artículo "Subtree Octopus merge" :
- La estrategia de fusión de subárbol se puede usar si desea fusionar un proyecto en un subdirectorio de otro proyecto y, posteriormente, mantener el subproyecto actualizado. Es una alternativa a los submódulos git.
- La estrategia de combinación de pulpo se puede utilizar para combinar tres o más ramas. La estrategia normal puede fusionar solo dos ramas y si intentas fusionar más que eso, git vuelve automáticamente a la estrategia de pulpo.
El problema es que solo puedes elegir una estrategia. Pero quería combinar los dos para obtener un historial limpio en el que todo el repositorio se actualiza atómicamente a una nueva versión.
Tengo un superproyecto, llamémoslo projectA, y un subproyecto projectB, que fusioné en un subdirectorio projectA.
(esa es la parte de combinación de subárbol)
También mantengo algunos compromisos locales.
ProjectAse actualiza regularmente, projectBtiene una nueva versión cada dos días o semanas y generalmente depende de una versión particular de projectA.
Cuando decido actualizar ambos proyectos, no me limito a retirarlos projectAy projectB eso crearía dos confirmaciones para lo que debería ser una actualización atómica de todo el proyecto .
En cambio, creo una única confirmación de combinación que combina projectA, projectBy mis confirmaciones locales .
La parte difícil aquí es que se trata de una fusión de pulpo (tres cabezas), pero projectBdebe fusionarse con la estrategia de subárbol . Entonces esto es lo que hago:
# Merge projectA with the default strategy:
git merge projectA/master
# Merge projectB with the subtree strategy:
git merge -s subtree projectB/master
Aquí el autor usó un reset --hard, y luego read-treepara restaurar lo que las dos primeras fusiones habían hecho en el árbol de trabajo y el índice, pero ahí es donde reset --softpuede ayudar:
Cómo rehacer esas dos fusiones , que han funcionado, es decir, mi árbol de trabajo e índice son bien, pero sin tener que grabar esos dos commits?
# Move the HEAD, and just the HEAD, two commits back!
git reset --soft HEAD@{2}
Ahora, podemos reanudar la solución de Tomás:
# Pretend that we just did an octopus merge with three heads:
echo $(git rev-parse projectA/master) > .git/MERGE_HEAD
echo $(git rev-parse projectB/master) >> .git/MERGE_HEAD
# And finally do the commit:
git commit
Entonces, cada vez:
- está satisfecho con lo que termina (en términos de árbol de trabajo e índice)
- que está no satisfecho con todas las confirmaciones que se ha tomado en llegar:
git reset --soft es la respuesta.
git reset --soft: stackoverflow.com/questions/6869705/…