La wiki de TempWin

Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.
====== Commits ======

Sección perteneciente al curso [[informatica:programacion:cursos:control_version_git_avanzado|Control de versiones con Git Avanzado]].

===== Introducción =====

Una de las unidades más importantes. Veremos cómo preparar un commit. Un commit no es un backup sino un momento concreto en la historia de cambios de nuestro proyecto. Una de las características más potentes de Git es que nos permite preparar el commit, qué ficheros van a ir a un commit y cuáles no.

También veremos cómo ver commits del pasado y cómo deshacerlos.

===== Preparación de un commit por etapas =====

==== Trabajando con el stage ====

Tanto para añadir nuevos archivos al repositorio (empezar a //versionar//) como para añadir modificaciones en archivos ya existentes, tendremos que "subirlos al stage":

<code>
git add <RUTA>
</code>

<WRAP center round info 60%>
Para inicializar un repositorio, es decir, que Git pueda empezar a trabajar con él, ejecutamos dentro del directorio el comando ''git init''. A partir de entonces ya podremos usar git.
</WRAP>

Cuando queremos "subir al stage" un archivo:

<code>
git add archivo
</code>

Si queremos añadir más de un archivo:

<code>
git add archivo1 archivo2 archivo3
</code>

Si queremos añadir un tipo de ficheros:

<code>
git add *.html
</code>

Para subir todos los archivos y modificaciones pendientes de pasar al stage y que estén en la carpeta actual (y todas las carpetas hijas):

<code>
git add .
</code>

Para ver información sobre las 3 zonas que usamos en Git, usamos el siguiente comando:

<code>
''git status''
</code>

Podemos ver un resumen de los ficheros que están en el stage y los que no están siendo controlados (versionados) por git. Los primeros aparecen en color verde y los segundos en color rojo. Otra forma de decirlo sería que lo que está en verde es lo que está en el stage y lo que está en rojo es lo que está en el working directory.

<WRAP center round todo 60%>
Poner captura con ejemplo de lo anterior
</WRAP>

<WRAP center round tip 60%>
''git status'' es un comando muy útil y es recomendable lanzar cada vez que ejecutemos algún comando de git. También ofrece "pistas".
</WRAP>


Si queremos **quitar modificaciones del stage** (por algún error):

<code>
git reset HEAD <RUTA_FICHERO>
</code>

Por ejemplo, si queremos quitar el fichero ''fichero1'':

<code>
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:

<code>
git reset HEAD .
</code>

<WRAP center round tip 60%>
En realidad, el comando ''git reset'' sirve para otra cosa que se verá más adelante.
</WRAP>

Para deshacer cambios en el working directory, es decir, para que Git deje los archivos modificados como estaban en el último commit:

<code>
git checkout -- <RUTA_FICHERO>
</code>

Por ejemplo, si queremos volver al estado anterior de todos los archivos del working directory:

<code>
git checkout -- .
</code>

<WRAP center round important 60%>
Esta operación es irreversible, no se puede deshacer. 
</WRAP>

Finalmente, si queremos borrar un archivo tenemos dos opciones. Si el borrado lo hacemos mediante las operaciones del sistema operativo, Git lo entiende como una modificación del proyecto y podremos subirlo al stage para luego hacer un commit con ese borrado.

Si usamos el método Git:

<code>
git rm <RUTA_FICHERO>
</code>

Git lo borra del sistema de ficheros y añada esa modificación al stage, ahorrándonos un paso respecto a la versión usando el sistema operativo.

Si queremos quitar un archivo del repositorio sin borrarlo del working directory:

<code>
git rm --cached <RUTA_FICHERO>
</code>

Esto es útil cuando llegado un momento queremos empezar a ignorar un fichero que antes estábamos siguiendo (el ''.gitignore'' aquí no serviría).

Tras "desversionar" lo que queremos, ahora sí podremos modificar el ''.gitignore'' para añadir ese fichero o ficheros que no queremos que Git versione.

==== Realizando el commit ====

Un commit siempre necesita un mensaje descriptivo (es obligatorio):

<code>
git commit -m "Mensaje"
</code>

Si queremos que abra el editor por defecto para que luego añadamos el comentario:

<code>
git commit
</code>

<WRAP center round info 60%>
El commit siempre se hace sobre lo que hay en el **stage**
</WRAP>

Como recomendación, en los mensajes de commit habría que evitar genéricos como "Cambios", "Nuevo archivo", "Correcciones", "CSS", "Merge"... A la hora de escribir un mensaje, tenemos que explicar bien qué modificaciones sufre el proyecto y de forma muy breve. El propósito es que cuando se quiera ver el log, se pueda entender perfectamente los cambios que ha sufri oel proyecto:

<code>
git log --oneline --branches --graph
</code>

Si queremos **modificar el último commit** (solo el último) que hemos hecho:

<code>
git commit --amend
</code>

Esto lo haremos tras añadir cambios al stage.

Al ejecutar el comando anterior, se abrirá el mensaje del último commit (el que queremos modificar) dándonos la posibilidad de modificarlo, si queremos.

<WRAP center round important 60%>
Si el commit ya se había subido al repositorio remoto, no se debe hacer ''%%--%%amend''. Las correcciones en los commits hay que hacerlas en el repositorio local.
</WRAP>

Otra cosa que suele pasar mucho es que hayamos hecho un commit con un mensaje incorrecto o incompleto. Si queremos corregir este mensaje, pero no tenemos más cambios, no hace falta subir nada al stage, basta con ejecutar el siguiente comando:

<code>
git commit --amend -m "Nuevo mensaje"
</code>

<WRAP center round info 60%>
Si no le pasamos el mensaje por línea de comandos, git abrirá el editor por defecto.
</WRAP>

Esta modificación cambia el hash del commit. Esto es normal porque este hash se genera a partir del contenido del título y otras cosas.


==== Ejemplos de commits por etapas ====

<WRAP center round todo 60%>
Añadir capturas de pantalla con las zonas de git y cómo se mueven los archivos cuando se preparan los commits.
</WRAP>

Iniciamos un repositorio git:

<code>
git init
</code>

<code>
git status
</code>

Subiremos al stage el fichero ''despedidas-en.json'':

<code>
git add despedidas-en.json
</code>

<code>
git status
</code>

Hacemos commit:

<code>
git commit -m "Commit inicial"
</code>

<WRAP center round info 60%>
Es práctica habitual incluir el mensaje "Commit inicial" en el primer commit de un proyecto
</WRAP>

<code>
git log --oneline --branches
</code>

<code>
git status
</code>

Subimos el fichero ''saludos-en.json'' al stage:

<code>
git add saludos-en.json
</code>

Hacemos el commit:

<code>
git commit -m "Añadidas traducciones de saludos"
</code>

<code>
git log --oneline --branches
</code>

Modificamos el fichero ''saludos-en.json''. Ahora git reconocerá que hay un cambio en el working directory:

<code>
git status
</code>

Subimos el fichero al stage:

<code>
git add saludos-en.json
</code>

Hacemos el commit:

<code>
git commit -m "Añadida despedida"
</code>

Vemos el log:

<code>
git log --oneline --branches
</code>

Creamos un nuevo fichero en el working directory: ''lugares-en.json''. También hacemos modificaciones en el fichero ''saludos-en.json''. Git nos avisará de estos cambios.

<code>
git status
</code>

Añadiremos al stage solo dos ficheros:

<code>
git add lugares-en.json despedidas-en.json
</code>

Hacemos commit:

<code>
git commit -m "Añadido fichero de lugares y añadido saludo"
</code>

Vemos el log:

<code>
git log --oneline --branches
</code>

Subimos al stage ''saludos-en.json'' modificado.

<code>
git add saludos-en.json
</code>

Pero nos arrepentimos, y lo quitamos del stage:

<code>
git reset HEAD saludos-en.json
</code>

Git nos dirá que aún está pendiente el cambio de ese fichero en el working directory:

<code>
git status
</code>

Pero si queremos volver a la versión del último commit del fichero ''saludos-en.json'':

<code>
git checkout -- .
</code>

<WRAP center round important 60%>
Recordad que este último comando es irreversible
</WRAP>

=====  Partes de un commit =====

Hasta ahora hemos visto qué es un commit. Ahora veremos los datos que llevan asociados los commits:

  * **Autor** / "committer": nombre y correo electrónico de quien realiza el commit.
  * **Fecha y hora**
  * **Mensaje**
  * **Padre**/s: un commit puede tener un padre o 2 (es raro que haya más).
  * **Hash** de 40 caracteres: se obtieen al aplicar SHA-1 al autor, fecha, mensaje y contenido del commit.

<code>
git log
</code>

<WRAP center round todo 60%>
Poner ejemplo de todo lo anterior
</WRAP>

===== El log =====

El log es el listado de commits a lo largo del tiempo.

==== Comandos para trabajar con el log ====

Ver el histórico de commits:

<code>
git log [rama]
</code>

Si no se indica la rama, ''git log'' nos mostraría el nombre de la rama en la que nos encontremos.

Para ver el log de forma compacta:

<code>
git log --oneline
</code>

Así veremos un commit por línea. No mostrará autor ni fecha.

Ver el log de todas las ramas:

<code>
git log --branches
</code>

Ahora podemos mezclar los modificadores para ver el log en formato compacto y de todas las ramas:

<code>
git log --oneline --branches
</code>

Al trabajar con ramas, es útil tener una representación gráfica de las divergencias, cómo se ha bifurcado el código:

<code>
git log --graph --branches
</code>

Podemos crear **alias** para comandos largos que usemos habitualmente:

<code>
git config --global alias.milog "log --oneline --branches --graph"
</code>

Habremos creado un alias llamado ''milog'', y para usarlo:

<code>
git milog
</code>

Para ver el contenido de un commit:

<code>
git show <HASH_COMMIT>
</code>

<WRAP center round todo 60%>
Poner ejemplo del comando anterior
</WRAP>

Con el comando anterior podremos ver las diferencias con el commit anterior. El formato que es usa es el de los parches (//patch//)

Podemos referenciar un commit de varias maneras:

  * Por su identificador hash SHA-1 (lo que vimos anteriormente)
  * Su posición respecto al HEAD
  * Por el nombre de una rama
  * Por su posición en el listado de reflog: ''HEAD@{n}''

<code>
git show HEAD
</code>

Commit anterior al commit apuntado por HEAD:

<code>
git show HEAD~1
</code>

Es lo mismo que 
<code>
git show HEAD~
</code>

Dos commits antes:

<code>
git show HEAD~2
</code>

Es lo mismo que 
<code>
git show HEAD~~
</code>

Esto es muy útil cuando queremos deshacer commits. 

Si un commit tiene más de un padre, usamos la notación siguiente:

<code>
git show HEAD^1
</code>

Haremos referencia al primer padre.

<code>
git show HEAD^2
</code>

Haremos referencia al segundo padre.

Referenciando un commit por la rama que apunta:

<code>
git show nombre_rama
</code>

''git reflog'' nos enseña una secuencia de movimientos de la referencia **HEAD**. Esto es útil si hemos "perdido" un commit.

<code>
git checkout HEAD@{1}
</code>

Nos habremos ido al commit al que apuntaba HEAD en cierto momento.

<WRAP center round todo 60%>
Poner gráfico con detached HEAD
</WRAP>

==== Saltos entre commits, reset y reflog ====

Saltar a otro commit o rama:

<code>
git checkout <COMMIT o RAMA>
</code>

Para el nombre el commit podemos usar las referencias que vimos en el apartado anterior.

El ''checkout'' hará dos cosas: moverá el HEAD de donde esté al que estamos indicando ; la segunda cosa es que va a coger el working directory tal cual está y lo va a transformar al estado en el que estaba en el commit al que nos movemos.

Para "borrar" commits:

<code>
git reset <COMMIT>
</code>

Realmente no se borran, sencillamente desaparecen de nuestra vista. Esto permite que podamos recuperarlos en cualquier momento (si no ha pasado demasiado tiempo y ha pasado el recolector de basura de Git).

Por ejemplo, si quremos deshacer los últimos 3 commits:

<code>
git reset HEAD~3
</code>

El comando ''reset'' tiene 3 modificadores:

  * ''%%--%%soft'': los cambios hechos en los commits que borramos, git los coloca en el stage. Este método se suele usar para comprimir commits.
  * ''%%--%%mixed'': los cambios hechos en los commits que borramos, git los coloca en el working directorio. Es la opción por defecto.
  * ''%%--%%hard'': los cambios hechos en los commits que borramos, desaparecen (de la vista).

Cuando desarrollamos en un equipo y queremos ver quién fue la última persona que hizo cada cambio:

<code>
git blame <RUTA>
</code>

Es útil para seguir una traza y poder encontrar quién hizo qué cosa.

===== Apartar cambios con stash =====

**stash** sirve para apartar cambios (en el working directory o en el stage) temporalmente.

<WRAP center round tip 60%>
Esto es muy útil cuando Git no nos deja cambiarnos de rama o commit (''checkout'') porque esos cambios machacarían nuestros ficheros.
</WRAP>

**stash** es una pila, lo que entra queda en la parte superior.

''git stash'' siempre va acompañado de un comando. 

Para coger unos cambios y meterlos en la pila de "stashes":

<code>
git stash [push -m "Mensaje"]
</code>

Listar todo lo que hay en el stash:

<code>
git stash list
</code>

<WRAP center round todo 60%>
Poner ejemplos del comando anterior
</WRAP>

Si queremos ver el contenido  de cierto stash:

<code>
git stash show [stash@{n}] [-p]
</code>

Para sacar los cambios del stash y colocarlos en el working directory (git stash siempre los colocará ahí):

<code>
git stash apply [stash@{n}]
</code>

El comando anterior no quita el stash de la pila. Si además queremos quitarlo de la pila, usaremos este otro comando:

<code>
git stash pop [stash@{n}]
</code>

Si queremos borrar de la pila un stash sin aplicarlo:

<code>
git stash drop [stash@{n}]
</code>

===== 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 =====

  * [[https://chris.beams.io/posts/git-commit/|Artículo "How to Write a Git Commit Message" ("Cómo escribir el mensaje de un commit en Git")]]
  * [[https://jasonmccreary.me/articles/when-to-make-git-commit/|Artículo "When to make a Git commit" ("Cuándo hacer un commit en Git")]]
  * Capítulo del libro Pro Git con una explicación sobre el comando git reset: 
    * [[https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified|Inglés]]
    * [[https://git-scm.com/book/es/v2/Herramientas-de-Git-Reiniciar-Desmitificado|Castellano]]
  * Capítulo del libro Pro Git con una explicación sobre el Working Directory, el stage y el repositorio local:
    * [[https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository|Inglés]]
    * [[https://git-scm.com/book/es/v2/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio|Castellano]]
  * Capítulo del libro Pro Git con un resumen sobre cómo deshacer cosas en el Working Directory y en el stage:
    * [[https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things|Inglés]]
    * [[https://git-scm.com/book/es/v2/Fundamentos-de-Git-Deshacer-Cosas|Castellano]]