Quiero dividir la primera confirmación en mi repositorio git, pero no puedo usar rebase para hacerlo porque se necesita un nodo principal. Encontré Edit the root commit in Git? útil para modificar el primer compromiso, pero no para dividirlo. ¿Cómo puedo dividirlo?División de la primera confirmación en git
Respuesta
Puede seguir exactamente el mismo proceso en la pregunta que ha vinculado, pero después de verificar la confirmación raíz puede usar git commit --amend
para modificar la confirmación original y luego git commit
para realizar una confirmación adicional antes de continuar con la rebase el comando.
Dependiendo de la forma en que desea dividir el commit puede utilizar git rm --cached
para eliminar archivos que desea añadir en la segunda cometer antes de la primera git commit --amend
y editar los archivos que desea tener un aspecto diferente antes de llamar git add
en esos archivos, nuevamente antes de llamar al git commit --amend
.
Después de llamar git commit --amend
, para asegurarse de que usted se compromete con exactitud el estado de la raíz original de comprometerse puede llamar:
git checkout <sha1-of-original-root> -- .
antes de llamar git commit
para hacer el segundo cometen de la raíz dividida comprometerse.
Usted puede utilizar la opción --root
para contar rebase
que desea volver a escribir la raíz/primera comprometerse:
$ git rebase --interactive --root
A continuación, la raíz cometen se mostrará en la lista de rebase TODO, y se puede seleccionar para editar que:
edit <root commit sha> <original message>
pick <other commit sha> <message>
...
Ésta es la explicación de --root
de the Git rebase docs:
Rebase todos los commits accesibles desde
<branch>
, en lugar de limitarlos con<upstream>
. Esto le permite volver a establecer la base de la (s) confirmación (es) raíz (es) en una rama.
- 1. División en la primera aparición
- 2. ¿Es posible especificar el nombre de la rama en la primera confirmación en git?
- 3. ¿Cómo deshacer git rm -rf dirname sin una primera confirmación?
- 4. Usando git diff en el mismo archivo entre la primera y la última confirmación
- 5. Git deshacer última confirmación
- 6. ¿Cómo eliminar la confirmación de git-notes?
- 7. obtener mensaje de confirmación en git hook
- 8. Git restablecer a la confirmación anterior
- 9. Git: ver mi última confirmación
- 10. Restaurar archivo de la confirmación anterior en git
- 11. ¿Cómo respaldo una confirmación en git?
- 12. Git excluye una confirmación en una rama
- 13. Amend una confirmación de que no era la confirmación anterior
- 14. ¿Volver a una confirmación específica basada en la identificación de confirmación con Git?
- 15. Cómo fusionar una confirmación específica en Git
- 16. (git): ¿Cómo llevar la confirmación específica de la rama ascendente?
- 17. Git-Svn dcommit provoca división de ramas
- 18. ¿Restaurar una confirmación previa de git?
- 19. git: mejor forma de revertir git sin confirmación revertida adicional
- 20. Pagar la confirmación anterior y convertirla en una confirmación nueva
- 21. Revertir parte de una confirmación con git
- 22. Git: volver al estado de confirmación anterior
- 23. ¿Puedo eliminar la confirmación inicial de un repositorio de Git?
- 24. Git: cómo eliminar el archivo de la confirmación histórica?
- 25. Obtener la última confirmación del repositorio de Git
- 26. Git revertir última confirmación y sacarlo de la historia
- 27. Error de Git: Cambios no realizados para la confirmación
- 28. jQuery agregue la primera parte de div, luego agregue la última parte de la división div
- 29. Mensaje de confirmación de impresión de una confirmación determinada en git
- 30. Git - retroceso a una confirmación anterior
(reescrito) Usted no quiere 'git reset --hard' aquí. Puede usar 'git reset - .', pero eso no" restaurará "el árbol de trabajo, solo el índice. Probablemente la mejor idea es 'git checkout - .' que actualizará el índice y el árbol de trabajo pero no HEAD (dejándote listo para comprometer la segunda parte de la confirmación de división (raíz original)) . La idea principal aquí es que tanto * reset * como * checkout * cambiarán HEAD excepto cuando les proporcione un argumento de ruta. –
@Chris Johnsen: Tiene toda la razón. Estaba pensando en un reinicio en dos etapas, luego en el camino '--hard' pero en realidad no escribí eso. La solución de pago es mejor. –