Tengo 2 commits, A y B, listos para ser empujados. Me doy cuenta de que olvidé agregar algo en A.
¿Cómo puedo agregar este cambio a A usando Magit? Ni siquiera sé qué parte de la documentación de Git debería mirar.
Tengo 2 commits, A y B, listos para ser empujados. Me doy cuenta de que olvidé agregar algo en A.
¿Cómo puedo agregar este cambio a A usando Magit? Ni siquiera sé qué parte de la documentación de Git debería mirar.
Respuestas:
Supongamos por un momento que desea agregar algo a la HEAD
confirmación, es decir, "la segunda confirmación B" en su ejemplo.
La ventana emergente de confirmación cpresenta un enlace " aEnmendar". Al presionar esa tecla "enmendará" los cambios organizados en la HEAD
confirmación. Como las confirmaciones no son mutables en Git, esto reemplazará la confirmación anterior por una nueva confirmación. Aparecerá un búfer con el mensaje de confirmación anterior, para que pueda modificarlo en caso de que el cambio agregado también requiera que ajuste el mensaje. Como siempre, presione C-c C-ccuando haya terminado de editar el mensaje. Esto es equivalente a correr git commit --amend
en la línea de comando.
HEAD
y edite su mensaje de confirmaciónComo a menudo sucede que solo tiene que ajustar el cambio o el mensaje, Magit ofrece dos variantes adicionales:
HEAD
sin editar el mensaje de confirmaciónHEAD
sin agregarle los cambios por etapasCuando desee editar una confirmación que no lo es HEAD
, entonces lo anterior no funcionará. Estos comandos siempre "modifican" (es decir, reemplazan) el HEAD
commit. Git no proporciona un solo comando para modificar una confirmación que no sea, HEAD
por lo que esto es un poco más complicado.
Magit qué proporciona un comando tal, sino porque hay situaciones en las que es preferible hacer esto en varios pasos, vamos a hablar de eso en primer lugar.
La modificación de una confirmación que no HEAD
se puede dividir en tres pasos:
A
) el HEAD
.HEAD
(como se describe anteriormente), lo que resulta en confirmación A'
.A
, pero además A'
.Esto se puede hacer usando un rebase interactivo. Escriba rpara mostrar la ventana emergente de rebase. Luego escriba mpara invocar la variante de rebase "editar un compromiso". Aparece un búfer con confirmaciones recientes. Vaya a la confirmación que desea modificar y escriba C-c C-cpara seleccionarla. Git luego rebobina el historial a esa confirmación y muestra información sobre el cambio continuo en el búfer de estado.
Modifique HEAD
como se describe arriba. Luego dile a Git que has terminado escribiendo r r. If A'
y B
conflict, rebase se detendrá B
y tendrá que resolver el conflicto. Después de hacerlo, presione r rpara continuar.
Si sabe que sus cambios A
darán lugar a conflictos con B
, proceda como se describe anteriormente; de lo contrario, utilice el siguiente enfoque.
Git permite crear "confirmaciones de reparación" usando git commit --fixup A
. Esto crea una nueva confirmación, que registra los cambios que "deberían haberse realizado en otra confirmación". Ese compromiso se convierte en lo nuevo HEAD
. También existe una --squash
variante. Para obtener información sobre las diferencias, consulte la git-commit
página del manual.
Para combinar realmente el A
commit y el nuevo commit A'
y luego volver B
a aplicar, debes usar rebase. Magit proporciona un comando conveniente para hacerlo r f.
La principal diferencia con el enfoque anterior es que aquí primero creamos una nueva confirmación y luego la reformulamos para combinarla con el "objetivo" y volver a aplicar B
. Arriba comenzamos con rebase en lugar de comprometernos.
En Magit, tanto la --fixup
y las --squash
variantes están disponibles en la ventana emergente de confirmación, en fy s. Pero Magit también proporciona variantes "instantáneas" de los comandos de reparación y squash en Fy S. Estas variantes crean una nueva confirmación como las variantes "no instantáneas", pero luego combinan instantáneamente la confirmación de reparación con la confirmación de destino utilizando rebase, sin que tenga que invocar otro comando.
"Arreglo instantáneo" ( c F) es esencialmente lo mismo que "extender HEAD
" ( c e), excepto que funciona para cualquier confirmación, no solo HEAD
.
Otras lecturas:
git-commit(1)
git-rebase(1)
git-commit
La página man redirige a la git-rebase(1)
que tiene estas líneas: El mensaje de confirmación sugerido para la confirmación plegada es la concatenación de los mensajes de confirmación de la primera confirmación y de aquellos con el comando "squash", pero omite los mensajes de confirmación con la "reparación" mando. IOW, use la reparación si solo quiere arreglar el código en el commit anterior, use squash si también quiere arreglar el mensaje de commit.
git commit --amend –C HEAD
es el comando Git que deseas buscar, y puedes hacer reparaciones en Magit con C-c C-a
.
C-c C-a
es de una versión anterior (creo). Además, no veo ningún rastro de "enmendar" en el búfer de ayuda ( ?
).
Entonces, un flujo de trabajo es:
Luego
El autoquash moverá automáticamente todas las confirmaciones de reparación al lugar correcto y las configurará para aplastarlas en la re-base.
i
me rinde Cannot rebase: Your index contains uncommitted changes. Please commit or stash them.
. Excepto que no tengo ningún cambio sin confirmar. : /
Proceed despite merge in rebase range? [c]ontinue, [s]elect other, [a]bort
. ¿Está tratando de decirme que mi reparación podría cagar en la próxima fusión?
merge in rebase
vea ERRORES debajo git help rebase
. Sugiero hacer la reparación antes de subir.
Para enmendar el último commit, es "c a". La reparación es para enmendar algunas confirmaciones anteriores.