Capitulo 5 ➜ El ciclo de vida de los archivos en #git | Capitulo 5 | parte 2

• Comando: git log [nombre de archivo]
• Comando: git reset --soft [id del commit]
• Comando: git reset --hard [id del commit]
• Áreas de trabajo en Git: Repositorio local
• Comando: git rm

Comando: git log [nombre de archivo]

Revisen sus commits con “git log” tendríamos dos commits, el que hicimos al final de la lección tres “archivos vacíos” y el multilinea que hicimos al final de la lección 4 “cambios en el archivo A”, que era un comit de prueba, si recuerdan ese commit solo afectaba a un archivo, el archivo A.txt, tanto B como C están tal como los dejamos en el commit “archivos vacíos”, esto de ver cual es el último commit en el que aparece X archivo lo puedes hacer con el git log, agregando al final el nombre del archivo que quieres ver, como se ve en la imagen a continuación, de esa forma puedes notar que la última aparición del archivo B, fue en el commit archivos vacíos, ahora si hacemos lo mismo con A.txt, verán que te salen todos los commits en los que aparece este archivo, para nuestro caso los únicos dos commits hechos; a diferencia de B.txt, que solo sale en “archivos vacíos” A.txt también aparece en “cambios en el archivo A”; y Bueno, como quiero retomar desde la lección 3, es decir desde “archivos vacíos”, voy a aprovechar para enseñarles un comando que dependiendo del caso te puede servir o no, se trata de borrar commits, quiero borrar el último commit “cambios en el archivo A”, y eso se logra con el comando “git reset”, el cual tiene dos opciones, un borrado suave o “soft” y uno duro “hard” haciendo referencia a lo irreversible que puede llegar a ser el comando reset.

Comando: git reset --soft [id del commit]

Escriban “git reset --soft” seguido del id del segundo commit, porque queremos hacer el reseteo hacia el segundo commit, para así volver a él, borrando el que está por encima; una vez lo ejecutes, el comando deshará el último commit y moverá tus cambios al index, es decir a stage, por lo que realmente nada se ha borrado, si abrimos el archivo A aun estara ahi la línea de prueba que pusimos en la lección pasada, se conserva, pero actualmente este cambio está en stage, es decir, en tu “git status” aparecerá como un cambio, es decir lo que antes era el commit “cambios en el archivo A”, regresa a stage para que tu ahora puedas decidir si hacerlo un commit nuevamente o borrarlo de forma definitiva, de ahí que esto sea un borrado “soft”, aun puedes recuperar lo hecho, caso contrario es con el subcomando hard.

Comando: git reset --hard [id del commit]

Vamos a volver a hacer nuestro commit, “git commit -m [mensaje]”, no importa el mensaje que pongan, lo vamos a borrar, entonces si hacen un “git log” no está el “cambios en el archivo A” solo esta hasta borrador, pero ahora probemos la contraparte, el borrado duro, escribimos el comando: “git reset --hard” de nuevo apuntando al id del commit “archivos vacíos”, al ejecutarlo nos responderá que el commit “archivos vacíos” está ahora a la cabeza o que es el head, y si abrimos el archivo A, ahora si que no hay nada está vacío, tal como estaba en “archivos vacíos”, si hacemos un “git log”, no hay rastro del commit que acabamos de hacer, el reset hard lo borro, ni de “cambios en el archivo A” que se borró con el reset soft, y si hacemos un git status, todo está en orden porque básicamente, se igualaron las 3 áreas de trabajo, el stage o index y el working area se igualan al commit “archivos vacíos” que habita en tu repositorio local; ¿cuál repositorio local? Tal como existe el working área y el stage área, también existe un área llamada repositorio local, donde están tus commits, bueno de hecho al final todo tu carpeta es un repositorio, pero donde habitan tus commits, tiene el nombre de repositorio local. 

Áreas de trabajo en Git: Repositorio local

La imagen anterior viene del sitio web que les presente en la lección tres, en aquella lección, cuando tus archivos estaban vacíos y tú hacías un git add pasabas tus archivos al index; luego en un segundo momento, editamos los archivos con lorem ipsum, provocando que index y workspace no coincidan, (la imagen anterior esta en ese punto) de esa forma el git status se da cuenta que tienes cambios y nos avisaba que tenemos que agregar ese cambio a index o deshacer tal cambio con git restore, al hacer eso último, perdemos el cambio hecho, (el párrafo de lorem ipsum) pero volvemos a como teníamos los archivos en el index, que era lo que quería para terminar el video con el commit “archivos vacíos” de aquí en adelante, el siglo de vida sigue su flujo variando de área según qué comandos uses, y por cierto, tus archivos ya en un commit, están en este estado “unmodifai” porque acabamos de hacer un commit, si editamos generariamos un cambio, que sería detectado por git y pasariamos al estado “modifai”, que luego tendríamos que mover a stage mejor conocido como index area, y luego hacerlo commit y el ciclo sigue y sigue de esa forma; ahora ya sabes cómo actuar cada que tienes que hacer un commit, vamos a cosas mas profundas ¿que pasa si quiero quitar algo de stage?

Comando: git rm

Hagamos un cambio (un párrafo de lorem ipsum) en los tres archivos para que estén iguales, y usa “git add .” y “git rm - - cached C.txt” para aplicarlo solo en el archivo C, ahora veamos qué nos dice el “git status”, A y B tienen cambios listos para pasar a un commit y el cambio que había en C ha sido borrado, recuerden que al pasar a todos los archivos a stage con git add punto, tambien entro C, por eso que al sacarlo git lo detecta como “deleted”, es decir que lo quitaste de stage, y como cualquier cambio fuera de stage, git status te avisa en rojo que debes agregarlo. Resumiendo básicamente pasó que de tres archivos que pasamos a index, con el “git add .” Ahora solo tenemos dos; tú puedes hacer un commit así dejando afuera el cambio en C, pero queda a deber que en algún momento conviertas en commit el cambio que dejaste fuera. Hagan un commit con el mensaje: “un párrafo en A y B” esta vez solo se guardaran A y B, pero la parte roja del mensaje del git status aún nos seguiría saliendo, así sería hasta que agreguemos C a stage y lo pongamos en un commit, aprovechamos y metamos otro párrafo en A y B, ojo que C sigue con un párrafo; ahora si revisamos el “git status” nos detectara el cambio de A y B, por lo que ahora en el siguiente commit no estará solo C sino que estarán también A y B, cabe aclarar que C al ser eliminado de stage, necesita volver a ser traqueado, como si fuera el primer git add que se le hace al archivo, ahora hagan un nuevo commit con el mensaje “dos párrafos en A y B pero uno en C” pero no olviden el git add.

Bueno, con eso terminamos lo referente al siglo de vida, ya conocés todos los estados por los que pasa tu archivo al momento de moverlo entre las diversas áreas de trabajo que tenemos en git, así que doy por terminado este apartado, a partir de de la siguiente lección, dado que ya Tenemos una cantidad de commits suficientes, vamos a empezar con las ramas y todo lo referente a las mismas.