Diferencias

Muestra las diferencias entre dos versiones de la página.

--- informatica:programacion:cursos:control_version_git_avanzado:commits [2023/05/31 20:09] – tempwin
+++ informatica:programacion:cursos:control_version_git_avanzado:commits [2023/06/16 17:11] (actual) – tempwin
@@ Línea 75: / Línea 75: @@
 git reset HEAD archivo1
 </code>
+<WRAP center round tip 60%>
+También se puede emplear ''git restore %%--%%staged <RUTA_FICHERO>''
+</WRAP>
 Si queremos quitar todos los cambios que haya en el stage:
@@ Línea 503: / Línea 508: @@
 <WRAP center round tip 60%>
-Esto es muy útil cuando Git no nos deja movernos de rama (''checkout'') porque esos cambios machacarían nuestros ficheros.
+Esto es muy útil cuando Git no nos deja cambiarnos de rama o commit (''checkout'') porque esos cambios machacarían nuestros ficheros.
 </WRAP>
@@ Línea 532: / Línea 537: @@
 </code>
-Para sacar los cambios del stash y colocarlos en el working directory  o stage:
+Para sacar los cambios del stash y colocarlos en el working directory (git stash siempre los colocará ahí):
 <code>
@@ Línea 551: / Línea 556: @@
 ===== Cómo deshacer =====
+Algo muy importante de Git es que casi todo se puede deshacer. Todo lo que vaya a un commit quedará para la historia (hasta que llegue el recolector de basura).
+Repasemos varias maneras de deshacer cambios.
+==== Cambios en el working directory ====
+Deshacer cambios en el **working directory** (todos los cambios):
+<code>
+git checkout -- .
+</code>
+<WRAP center round important 60%>
+Recordemos que el anterior comando es de las pocas cosas en git que no se pueden deshacer.
+</WRAP>
+==== Cambios en el stage ====
+Deshacer lo que haya en el **stage**:
+<code>
+git reset HEAD .
+</code>
+<WRAP center round info 60%>
+Ahora sabemos que el uso principal de ''git reset'' es para volver a commits anteriores. Sin embargo, lo usamos también para quitar cambios del stage porque ''git reset HEAD .'' vuelve al commit actual (el mismo), pero como por defecto se aplica el modificador ''%%--%%mixed'', esto hace que quite los cambios del stage y los coloque en el working directory.
+</WRAP>
+==== Deshacer commits ====
+<code>
+git reset <COMMIT>
+</code>
+Deshacer un ''commit %%--%%amend'':
+<code>
+git reflog
+</code>
+Así vemos los commits ocultos porque vemos los movimientos de HEAD. Cuando lo hayamos identificado, para recuperarlo:
+<code>
+git checkout <COMMIT>
+</code>
+Esto nos pondrá en el modo "detached HEAD". Falta que la rama apunte también al mismo commit que HEAD. Para mover la referencia de una rama:
+<code>
+git branch -f master
+</code>
+Suponiendo que la rama ''master'' sea rama que nos interesa mover. De esta forma ya tendríamos tanto HEAD como ''master'' apuntando al commit que recuperamos. El último paso es hacer un checkout para que HEAD esté apuntando a master:
+<code>
+git checkout master
+</code>
+Podemos pensar que para recuperar un commit "oculto" lo que hacemos es meterlo en un itinerario existente, es decir, en una rama.
+==== Deshacer un reset ====
+Tras hacer un reset, los commits desaparecen de nuestra vista, pero podemos recuperarlos. Los podemos ver con:
+<code>
+git reflog
+</code>
+E identificamos el último commits de los que queremos recueprar.
+Ahora nos llevaremos HEAD y master del momento actual a ese último commit que queremos recuperar:
+<code>
+git checkout <COMMIT>
+</code>
+Ahora llevaremos la rama:
+<code>
+git branch -f master
+</code>
+Para enlazar HEAD con master (y salir de "detached HEAD"):
+<code>
+git checkout master
+</code>
+<WRAP center round todo 60%>
+Poner ejemplos de todo lo anterior
+</WRAP>
+==== Resolver problemas derivados del detached HEAD ====
+Cuando por ejemplo estamos haciendo commits en estado "detached HEAD", no avanza la rama. Las ramas avanzan solo si HEAD la hace avanzar.
+<code>
+git log --oneline --graph
+</code>
+No ponemos ''%%--%%branches'' para poder ver HEAD.
+Para solucionarlo, tenemos que mover la rama a donde esté HEAD:
+<code>
+git branch -f master
+</code>
+Nos quedaría la asociación de HEAD con master, es decir pasar de ''(HEAD, master)'' a ''(HEAD -> master)'':
+<code>
+git checkout master
+</code>
+<WRAP center round todo 60%>
+Poner ejemplos de todo lo anterior
+</WRAP>
+Otra situación que se nos puede dar es que hagamos un commit en un estado anterior al commit en el que está la rama master.
+Eso origina un nuevo itinerario, pero es un itinerario que está fuera de la rama master (no tiene ninguna referencia de rama asociada). Si nos cambiamos de rama, el itinerario anterior quedará oculto a la vista.
+Para recuperar, nos ayudamos de:
+<code>
+git reflog
+</code>
+Identificamos el commit que nos interesa y
+<code>
+git checkout commit
+</code>
+Hemos vuelto al "itinerario sin nombre". Para resolver esto, crearemos una referencia de rama:
+<code>
+git branch experimento
+</code>
+Ahora ya aparece el itinerario en los logs.
+Seguimos en "detached HEAD", así que para que se enlacen HEAD con experimento:
+<code>
+git checkout experimento
+</code>
+==== Ignorar archivos que ya están siendo versionados ====
+Borrar del repositorio, pero no del working directory:
+<code>
+git rm --cached <RUTA_FICHERO>
+</code>
+El archivo dejará de estar versionado. Luego podremos añadirlo a un ''.gitignore'' para que de ahí en el futuro git deje de tenerlo en cuenta.
 ===== Conclusión =====
+Hemos visto cómo se preparan los commits: en el stage. Al hacer un commit, "hacemos una foto" al stage.
+Los commits no se hacen periódicamente, solo cuando es necesario que vaya a haber cambios en el log.
+''git reflog'' es muy útil para cuando queramos deshacer cambios o investigar los cambios que ha habido en nuestro repositorio.
 ===== Recursos =====