Utilizando Git en Linux: comandos locales

¡Es momento de perder el miedo a las Apps de Terminal, y aprender a usar Git!

¿Qué diablos es Git y por qué debería usarlo? Bueno pues Git es algo conocido como un Software de Control de Versiones, en inglés es común encontrar este tipo de software mencionado con las siglas VCS (Version Control Software). Git fue diseñado por Linus Torvalds (el creador del kernel Linux). El funcionamiento de este VCS llamado Git tiene que ver con la gestión de cambios que van realizandose sobre de proyectos escritos en lenguajes de programación, es decir, Git es una especie de bitácora de cambios.

Pero esto no es todo, pues esta bitácora no solo registra los cambios, sino que nos va a permitir volver sobre nuestros pasos a los "estados" anteriores registrados en esa bitácora. Esto nos permite restaurar estados anteriores en caso de que en un "estado" más reciente algo haya salido muy mal. Además nos permite crear "ramas", es decir, variantes de un tronco común, para así poder trabajar sobre versiones alternativas al código principal, y posteriormente fusionar todas las ramas en el proyecto principal. De esta manera podemos proteger el código base de modificaciones riesgosas o experimentales, y solo en el caso de que estos experimentos resulten totalmente funcionales, los fusionamos, de otro modo podemos simplemente eliminarlos sin afectar el código principal. Estas son solo unas de las características de Git, y en esta serie de tutoriales vamos a conocer, poco a poco, muchas de las características y funcionalidades de Git.

Antes que nada Git es una aplicación que corre de manera local, es decir, un software que instalamos en nuestro ordenador personal y que mientras no elijamos conectarlo a un servicio de internet, podemos disfrutar de sus beneficios sin necesidad de servicios en-línea. Usar Git de manera local permite al usuario, como ya dije antes, mantener un historial de los cambios que va creando en su proyecto, crear ramas y revertir cambios en caso de necesitarlo. Por otro lado, si utilizamos Git en conjunción con un servicio en-línea de hospedaje de repositorios como lo es GitHub (Ojo: Git y GitHub son dos cosas muy distintas, que pueden trabajar en conjunto pero son totalmente independientes), esto nos permitirá no solo mantener un control de modificaciones localmente, sino además publicar este historial en internet ya sea para presumirlo o bien en caso de necesitarlo, trabajar en equipo sobre un mismo proyecto de manera remota: cada participante es capaz de crear archivos, modificarlos, descargar todos los cambios que las demás integrantes hayan realizado, crear “ramas” y fusionarlas con el tronco común.  Durante este primer tutorial revisaremos solamente los comandos locales de Git, y prepararemos el camino para entender los comandos en línea en una posterior publicación.

A lo largo de este tutorial usaremos diferentes términos que pueden parecer algo confusos al inicio, por lo que hasta el final de este tutorial he añadido un "Glosario" con términos comunes. En caso de confundirte o atorarte con los términos, visita el Glosario para ver si eso te ayuda a aclarar dudas.

Instalando Git

Nota: es muy probable que si estas usando Linux este ya traiga Git pre-instalado. Revisaremos primero si ya lo tiene instalado.

Abrimos nuestra terminal y usaremos el comando « which », por lo cual escribiremos: which git

usuario@terminal:~$ which git
/usr/bin/git

Si ya tenemos « git » instalado, el comando « which » nos mostrará el directorio en donde se encuentra instalado Git. Si por otro lado, luego de usar el comando no nos arroja ningún resultado, significa que Git no está instalado en nuestro sistema.

En caso de no tenerlo pre-instalado, lo instalamos con el comando de « aptitude-get », abreviado como « apt-get ». Hacemos primero nuestro update de repositorios con « sudo apt-update », y posteriormente hacemos uso de « sudo apt-get install » para instalar Git, de la siguiente manera:

usuario@terminal:~$ sudo apt-get install git

Nota: Una vez instalado Git no es necesario "ejecutarlo" antes de comenzar a usarlo, por decirlo de una manera, digamos que este reposa inactivo ya en nuestro sistema hasta el momento en el que lo invoquemos por medio de la Terminal.

I. Designar un directorio de trabajo

Primero que nada necesitamos designar un directorio (recordemos que «Directorio» es básicamente un sinónimo de Folder o Carpeta) para avisarle a Git en dónde debe comenzar a registrar los cambios de nuestro proyecto. Dentro de este directorio vamos a estar haciendo todos los cambios necesarios.

Podemos crear un nuevo directorio por medio de la interfaz gráfica de nuestro OS de Linux (ya sabes, hacer clic en folders y clic en "crear nuevo folder") o bien hacerlo todo desde la Terminal. Para hacer esto último, simplemente abrimos una Terminal, primero nos movemos a nuestro directorio base de usuario con « cd ~ », acto siguiente nos movemos al directorio de Documentos con « cd Documentos », y hacemos una creación de directorio (Folder/Carpeta) usando « mkdir », finalmente agregamos el nombre del directorio, por ejemplo Web, es decir « mkdir Web », de esta manera:

Nota: recuerden que el comando « ls » lo único que hace es listar todo lo que contiene nuestro directorio actual.

usuario@terminal:~$ cd ~
usuario@terminal:~$ ls 
 Descargas Games Musica 
 Documentos Imagenes Escritorio 
 Plantillas 
usuario@terminal:~$ cd Documentos 
usuario@terminal:~/Documentos$ mkdir Web 
usuario@terminal:~/Documentos$ ls 
 Proyectos Notes PycharmProjects 
 Web 
usuario@terminal:~/Documentos$ cd Web 
usuario@terminal:~/Documentos/Web$

Una vez creado nuestro directorio nuevo, en este caso Web, accedemos a el con « cd Web ».

Ya que nos encontramos dentro de nuestro directorio que convertiremos en nuestro directorio principal, le avisaremos a Git para que lo convierta en nuestro centro de operaciones, esto lo logramos ejecutando una vez dentro de nuestro directorio Web, en la misma Terminal, el comando de « git init »:

Nota: este comando lo utilizaremos solamente una sola vez en nuestro proyecto actual, no es necesario volverlo a invocar.

usuario@terminal:~/Documentos/Web$ git init

Nota: no es obligatorio saberlo ─pues Git controlará todo automáticamente desde ahora─ pero lo que este comando hace en realidad es crear una carpeta oculta, dentro de nuestra carpeta principal (en nuestro ejemplo, se llama Web), y dentro de esa carpeta oculta que crea Git (llamada ".git"), se encuentran todos los archivos que se necesitan para que Git almacene un historial de todos nuestros cambios en nuestro proyecto y de esta manera va controlando el flujo del mismo, así que no borres el Folder llamado « .git » dentro de tu directorio del proyecto si te lo llegas a encontrar.

II. Conocer el estatus de tu proyecto

Siempre es importante saber en qué lugar estamos, para esto haremos uso del comando « git status ». Hay que recordar siempre estar situadas dentro del directorio de trabajo en nuestra Terminal, es decir, si nos encontramos en cualquier otro directorio que no sea nuestro directorio previamente registrado en Git (como hicimos en el paaso anterior) simplemente Git no sabrá en dónde está nuestro proyecto, es por esto que hicimos un « git init » dentro de nuestro folder de trabajo, y es justo desde ahí que debemos ejecutar cualquier comando de Git.

Nota: claro que puedes hacer « git init » en diferentes folders que contengan diferentes proyectos, y así cada folder tendrá su sesión de git propia, su bitácora propia digamos, pero estas no son intercambiables, es decir, si ejecutas acciones de git desde dentro de un directorio que contiene un proyecto, esto no afectará a tus otros proyectos.

Recordemos las lecciones básicas de Terminal en Linux, para saber en qué directorio estamos, desde nuestra Terminal usamos el comando « pwd » (present working directory, por sus siglas en inglés) y de no encontrarnos justo dentro de nuestro directorio de trabajo que ya habíamos designado con « git init » simplemente nos trasladamos a él con los comandos de « cd » (change directory, por sus siglas en inglés):

usuario@terminal:~$ pwd 
 /home/principal 
usuario@terminal:~$ cd Documentos 
usuario@terminal:~/Documentos$ cd Web 
usuario@terminal:~/Documentos/Web$ pwd 
 /home/principal/Documentos/Web

En este ejemplo nos encontramos primero en el directorio llamado "principal", que no es nuestro directorio de trabajo, que en este ejemplo se llama "Web", por lo cual tuvimos que desplazarnos hacia él. Ahora sí, dentro de nuestro directorio llamado "Web" ya podemos hacer uso de nuestro comando « git status ».

usuario@terminal:~/Documentos/Web$ git status 
 En la rama master
  nada para hacer commit, el árbol de trabajo está limpio

Cuando no hemos realizado ningún cambio en lo absoluto, git nos devolverá este mensaje; nos dirá que nos encontramos en la rama "master" que es la rama principal (ya veremos más adelante como crear ramas, cómo fusionarlas y como cambiar de una rama a otra, no entren en pánico) y que no hay ningún cambio registrado dentro de nuestro Folder de trabajo. Por otro lado, si hemos realizado algún cambio, por ejemplo, en este caso siguiente, lo que he hecho es crear un archivo “style.css” y luego he ejecutado « git status », ahora me dice que existe un nuevo cambio, que ahora existe un archivo nuevo llamado “style.css” que se encuentra en nuestro directorio de trabajo pero que aún no ha sido declarado para ser trasladado al Index (en unos instantes veremos qué es el Index) con el comando « git add », por lo cual no podemos aún hacer un commit (en unos momentos veremos qué es un commit) de este cambio para consolidarlo en el historial permanente de cambios:

usuario@terminal:~/Documentos/Web$ git status
 En la rama master 
 Archivos sin seguimiento: 
    (usa "git add …" para incluirlo a lo que se será confirmado) 
      style.css 
 no hay nada agregado al commit pero hay archivos sin 
 seguimiento presentes (usa "git add" para hacerles seguimiento)

III. Lógica de flujo del proyecto

La manera en la que fluyen los archivos modificados dentro de la estructura de trabajo de Git es la siguiente:

1. Tenemos un área de trabajo, que viene siendo el directorio que ya designamos como nuestra base con el comando « git init ».
2. Cuando realicemos cambios en los archivos dentro de esta área de trabajo, debemos anunciarle a Git estos cambios: esto lo haremos con otro comando, que veremos a continuacíón, llamado « git add ».
3. « git add » agrega los archivos sobre los cuales hemos realizado cambios (o que hayamos recién creado), y que elijamos individualmente o en masa, a una plataforma intermedia llamada "stage” (stage significa escenario). Este stage, formalmente se llama “Index”, y ahí se preparan los archivos modificados para ser consolidados en la fase final que viene a continuación.
4. Todos los archivos que agreguemos al stage, o mejor dicho “Index”, tenemos que darle la orden a Git para que los consolide en una nueva versión, dentro de nuestro esquema de versiones, y que así almacene estos cambios en su sistema de historial o bitácora. Este ultimo paso se logra con la operación « git commit » que veremos también más adelante.
5. Todos los cambios que hayan llegado al esquema de versiones a través del comando « git commit » quedan registrados en un historial/bitácora, a partir de la cual podemos navegar con otros comandos para ir hacia atrás o hacia adelante en los cambios. Todo commit va acompañado de un texto descriptivo el cual nos ayudará aún más a identificar los cambios que hemos hecho con cada commit.

Nota: los nombres de estas 3 plataformas de trabajo son “directorio de trabajo” para nuestro folder local que designamos con « git init »; el siguiente se llama “Index” (aunque también lo encontraremos siendo llamado “área de stage”) que es al que transferimos los archivos modificados con ayuda del comando « git add »; la última plataforma, la de los cambios registrados en historial/bitácora de Git se conoce como “HEAD”, y a ella trasladamos los cambios con el comando « git commit ».

IV. Pasar del directorio de trabajo a Index, y de Index a HEAD

Luego de que hemos ejecutado « git status » y sabemos, por ejemplo, que ya creamos un nuevo archivo, digamos un archivo “style.css“, ya estamos listas y listos para hacer « git add » y pasar nuestros archivos nuevos al Index, para luego hacer un commit y dejar estos cambios consolidados dentro del historial de Git:

usuario@terminal:~/Documentos/Web$ git status
 En la rama master
 Archivos sin seguimiento:
  (usa "git add …" para incluirlo a lo que se será confirmado) 
    style.css 
 no hay nada agregado al commit pero hay archivos sin seguimiento presentes 
 (usa "git add" para hacerles seguimiento) 
usuario@terminal:~/Documentos/Web$ git add style.css 
usuario@terminal:~/Documentos/Web$ git status 
 En la rama master 
 Cambios a ser confirmados:
  (usa "git restore --staged …" para sacar del área de stage)
    nuevo archivo: style.css

Nota: « git add » es un comando que requiere de un parámetro, es decir, la sintaxis vendría siento « git add parámetro », en esta sintaxis de ejemplo tendríamos que sustituír la palabra "parámetro" por alguno de los parámetros que Git está programado para leer. Es decir, si intentamos ejecutar « git add » por sí solo, sin un parámetro, Git nos dirá que no estamos escribiendo correctamente el comando, que es necesario agregar exactamente sobre qué parámetro exactamente queremos hacer el git add.

En este ejemplo le hemos dicho a nuestra Terminal que ejecute « git add » y agregamos "style.css" como el parámetro sobre el cuál ejecutar « git add », es decir, le pedimos que lo ejecute sobre el archivo “style.css“, de este modo la sintaxis de nuestra orden completa queda así: « git add style.css ». De esta manera hemos pasado nuestro archivo “style.css” de nuestro directorio de trabajo a nuestro Index, a esta acción se le conoce como hacer un "staging". Ahora sí, ya está listo para ser consolidado en el control de versiones permanente de Git, llamado HEAD:

usuario@terminal:~/Documentos/Web$ git status 
 En la rama master 
 Cambios a ser confirmados: 
  (usa "git restore --staged …" para sacar del área de stage)
    nuevo archivo: style.css 
usuario@terminal:~/Documentos/Web$ git commit -m "agregué un style.css" 
 [master 3e0bb94] agregué un style.css 
  1 file changed, 0 insertions(+), 0 deletions(-) 
  create mode 100644 style.css

Como podemos ver primero hicimos un « git status » para asegurarnos de que nuestro archivo “style.css” ya se encontrara previamente registrado en nuestro Index, y de ser cierto esto, simplemente ejecutamos « git commit -m “comentario” », lo cual nos avisa “1 file changed” es decir “1 archivo ha cambiado”.

Ahora sí, hemos trasladado nuestro cambios del directorio de trabajo al Index y de ahí a HEAD.

Nota: el comentario dentro de la orden ejecutada « git commit -m “comentario” » es obligatorio pues nos ayuda a saber qué exactamente hemos cambiado en cada commit, en nuestro ejemplo, el comentario que hice fue “agregué un style.css”, y como podemos ver en la primera línea luego de ejecutar el commit, nos dice “[master 3e0bb94] agregué un style.css” lo que significa que nuestro comentario fue registrado junto con nuestro commit.

Cualquier cambio es registrado, si creamos un archivo nuevo, si modificamos uno ya existente o si borramos algun archivo. Por ejemplo, si ahora borro mi archivo “style.css”, y hago « git status », la Terminal me dirá lo siguiente:

usuario@terminal:~/Documentos/Web$ git status
 En la rama master 
  Cambios no rastreados para el commit: 
    (usa "git add/rm …" para actualizar a lo que se 
     le va a hacer commit) 
    (usa "git restore …" para descartar los cambios 
     en el directorio de trabajo) 
      borrado: style.css 
  sin cambios agregados al commit (usa "git add" y/o 
  "git commit -a")

Lo que me indica ahora es que he borrado “style.css” de mi área de trabajo, pero nos anuncia que aún no he hecho "staging" de ese cambio con « git add », es decir, para llevar ese cambio a mi Index, para lograr esto voy a nombrar el archivo que acabo borré, aunque ya lo haya eliminado en el área de trabajo, es decir que lo estoy nombrando solo para avisarle a Git que eliminé un archivo con ese nombre.

Hago entonces « git add style.css », lo cual claramente no añadirá ningún archivo en sí, sino que registrará el cambio realizado (es decir, que ya lo borré) sobre el archivo que tenía ese nombre, y que la misma Terminal me lo está indicando al decirme “borrado: style.css”.

usuario@terminal:~/Documentos/Web$ git add style.css 
usuario@terminal:~/Documentos/Web$ git status 
 En la rama master 
 Cambios a ser confirmados: 
   (usa "git restore --staged …" para sacar del área de stage) 
     borrado: style.css 
usuario@terminal:~/Documentos/Web$ git commit -m "borre style"
 [master fcafd4b] borre style 
   1 file changed, 0 insertions(+), 0 deletions(-)
   delete mode 100644 style.css

Nota: como podemos ver ahora, la opreación « git add » no “añade” archivos al Index, sino que añade cambios sobre archivos, cuando los creamos, cuando los modificamos, y hasta cuando los eliminamos. En este sentido el comando de commit lo que hace es consolidar estos cambios sobre el HEAD (es decir, sobre el esquema permanente de Git, su historial de cambios).

En este apartado hemos aprendido a utilizar « git add » de una manera selectiva, es decir, si realizamos un cambio en un archivo llamado “style.css“, cuando hacemos « git add » lo escribimos de esta manera « git add style.css », pero digamos que hemos realizados varios cambios más, por ejemplo, creamos un folder llamado “imágenes“, cambiamos el nombre de “index.html” por “index.php“, y además modificamos el contenido de “style.css“, ¿esto significa que manualmente tendríamos que hacer una operación « git add » por cada uno de estos cambios? es decir, « git add imágenes » « git add index.php » « git add style.css » … y así con cada cambio para agregarlo al Index. ¿No existe otra forma resumida? ¡claro que sí!

Si tenemos varios cambios y tenemos mucha seguridad de añadir todos esos cambios de golpe a nuestro staging de Index, entonces utilizamos « add . », esto es, “add” seguido de un espacio y luego un punto “.“, y con ese comando añadiremos de una sola vez todos los archivos a nuestro Index.

Nota: el espacio entre "add" y "." es importante: « add . »

En este apartado también hemos revisado la manera resumida de hacer un commit utilizando el comando « git commit -m “comentario” », no obstante existe otra manera de realizar un commit, que realmente resulta exactamente en lo mismo, pero viene siendo la versión no-resumida. Esta se forma "extensa" se logra escribiendo « git commit » sin la “-m” y sin el comentario entre comillas. Así, cuando ejecutamos « git commit » a secas, lo que ocurre es que en nuestra Terminal se ejecutará un editor de textos y que dirá lo siguiente:

Por favor ingresa el mensaje del commit para tus cambios. Las
líneas que comiencen con '#' serán ignoradas, y un mensaje 
vacío aborta el commit. 
# 
En la rama master 
Cambios a ser confirmados: 
renombrado: style.css -> inc/style.css 
#

Nota: las distribuciones de Linux casi siempre traen un editor de textos por defecto para la Terminal. Algunas distribuciones traen pre-instalado el editor de textos Nano,  otros traen Vim, otros traen Emacs, y al usar « git commit » a secas, como vimos en el ejemplo anterior, se ejecutará alguno de estos editores, dependiendo de cuál venga pre-instalado en tu Linux distro.

El resultado final entre « git commit -m “comentario del commit” » y « git commit » es exactamente el mismo, solamente que la “-m” del primero nos resume la parte de abrir el editor de textos en Terminal y simplemente guarda el comentario entre comillas que le sigue.

Nota: Si no sabes utilizar el editor de textos desde Terminal simplemente evita usar « git commit », y en su lugar siempre utiliza « git commit -m “comentario del commit” ».

V. Deshacer un staging al Index y recuperar archivos eliminados

Digamos que nos hemos arrepentido de haber borrado el archivo “style.css” y que aún no hemos realizado nisiquiera el comando « git add », y obviamente tampoco el « git commit ». Para restaurar el archivo perdido desde Git lo que haremos es usar el comando « git restore », así que vamos a la Terminal y nombramos el archivo eliminado dentro del comando de « git restore »:

usuario@terminal:~/Documentos/Web$ git restore style.css

Esto provoca que inmediatamente vuelva a aparecer en nuestro folder de trabajo el archivo que habíamos borrado.

Ahora, digamos que nos hemos arrepentido de haber borrado el archivo “style.css”, pero ya habíamos agregado ese cambio al Index con « git add », es decir, ya habíamos hecho staging. Lo que haremos es utilizar el comando « git restore --staged », que es el mismo comando “restore” pero agregamos el parámetro “--staged” (Nota: son dos guiones -- antes de "staged"), lo cual especifica al comando “restore” que no queremos restaurar en sí el archivo eliminado (como en el ejemplo anterior) sino que solamente queremos remover la modificación que hicimos al registro del Index. Una vez removido este “staging” que no deseamos, es decir la modificación al Index, ya podemos proceder a restaurar el archivo en sí mismo como en el primer ejemplo con « restore ».

usuario@terminal:~/Documentos/Web$ git restore --staged style.css 
usuario@terminal:~/Documentos/Web$ git status 
 En la rama master 
 Cambios no rastreados para el commit: 
  (usa "git add/rm …" para actualizar a lo que se le va a hacer commit)
  (usa "git restore …" para descartar los cambios en el directorio de trabajo)
     borrado: style.css
 sin cambios agregados al commit (usa "git add" y/o "git commit -a") 
usuario@terminal:~/Documentos/Web$ git restore style.css

Ahora que si por accidente hiciste « git add . » y añadiste una lista larga de archivos al Index y no quieres ir uno por uno haciendo « git restore --staged», puedes simplemente hacer « git reset » y todos los cambios que hayas añadido para hacer staging al Index serán revertidos. Ojo, esto no borrará tus archivos ni los cambios que hayas realizado sobre ellos, solo elimina el paso de "staging" y conserva todos los cambios hechos a tus archivos, repito, solamente deshace el paso de staging que hacemos al utilizar « git add »

VI. Administrando las ramas

Una rama es un escenario alternativo para un mismo proyecto. La rama por defecto es siempre la rama principal, o “master“, cuando creamos otras ramas estas se generan a partir de la rama principal. Estas ramas nos permiten trabajar sobre módulos, por decirlo de alguna manera, experimentales o alternativos a nuestro proyecto principal, que de resultar exitosas podemos fusionar, o hacer “merge” que es lo mismo, con la rama “master”; si por el contrario, resultara en un experimento fallido siempre podemos borrar esta rama alternativa que creamos y de esta manera nunca modificamos ni afectamos nuestra rama “master”.

Para crear una rama, nos situamos en nuestra carpeta principal, y en Terminal escribimos el comando « git checkout -b » y a continuación el nombre de la nueva rama, en este caso se llamará “alterna_01“, por lo que escribimos la orden « git checkout -b alterna_01 » , y a continuación la ejecutamos:

usuario@terminal:~/Documentos/Web$ git checkout -b alterna_01 
 Cambiado a nueva rama 'alterna_01'

Como vemos, hemos creado una nueva rama, y además de eso, nos hemos desplazado a ella. Si hacemos « git status » nos debe avisar que estamos en la nueva rama.

Nota: Es muy importante siempre asegurarnos en qué rama estamos actualmente. Para lograrlo podemos hacer un « git status » o también podemos hacer « git branch » y nos mostrará todas nuestras ramas y marcará con asterisco la rama en la que estamos.

usuario@terminal:~/Documentos/Web$ git status 
 En la rama alterna_01 
 nada para hacer commit, el árbol de trabajo está limpio 

usuario@terminal:~/Documentos/Web$ git branch 
 * alterna_01 
 master

Para movernos a la rama “master”, o a cualquier otra rama que hayamos creado, simplemente ejecutamos el comando « git checkout » seguido del nombre de la rama a la que queremos ir, en este caso “master“, por lo que hacemos un « git checkout master ».

usuario@terminal:~/Documentos/Web$ git checkout master
 Cambiado a rama 'master'

Si lo que queremos ahora es borrar una de las ramas, ejecutamos el comando « git branch -d » seguida del nombre de la rama a eliminar, en este caso “alterna_01“, por lo que escribimos « git branch -d alterna_01 ».

Nota: debemos estar fuera de la rama que deseamos eliminar.

usuario@terminal:~/Documentos/Web$ git checkout master 
 Cambiado a rama 'master'
usuario@terminal:~/Documentos/Web$ git branch -d alterna_01 
 Eliminada la rama alterna_01 (era fcafd4b)..

¿En qué escenario podría ser necesario crear una rama? Digamos que quieres agregar a tu proyecto un sistema de registro para usuarios, pero tienes dos métodos diferentes que quieres probar, para ver cual de ambos resulta adaptarse mejor a tu proyecto puedes crear en este caso dos ramas (en este ejemplo tendremos dos ramas, una llamada “version_registro_uno” y otra “version_registro_dos“), y en cada una dedicarte a programar uno de los dos diferentes sistemas, sin afectar en lo más mínimo ninguno de los archivos de la rama "master" y tampoco los archivos de la otra rama (recuerda que creamos 2 ramas experimentales).

Luego de terminar de experimentar programando los dos métodos diferentes para tu (hipotético) sistema de registro de este ejemplo, y que encuentres uno de los dos como la mejor opción, simplemente borramos la rama del sistema que no resultó óptima con « git branch -d », en este ejemplo haremos de cuenta que “version_registro_uno” fue la mejor opción, así que borraremos “version_registro_dos“.

Una vez que hemos confirmado que resulta completamente funcional nuestra “version_registro_uno”, entonces lo que haremos con esta rama exitosa será fusionarla con nuestra rama “master”, esto lo haremos moviéndonos a la rama sobre la cual vamos a invocar la fusión, con el comando « git checkout », y una vez ya dentro de la rama "master" haremos « git merge » y escribimos la rama que deseamos fusionar con la rama activa, de esta manera quedaría la sintaxis completa para el merge: « git merge version_registro_uno ».

Nota: recuerda que debemos siempre consolidar nuestros cambios utilizando « git add » y « git commit » y posteriormente hacemos el merge. Si tu creas una nueva rama, y trabajas sobre ella, pero nunca haces commits, al momento de intentar hacer "merge" no habrá cambios que fusionar porque no habrá commits registrados dentro de tu nueva rama.

Entonces, resumiendo el ejemplo de código siguiente: primero eliminamos la rama que ya no necesitamos, en este ejemplo será “version_registro_dos”. Posteriormente vamos a fusionar, es decir, hacer "merge" de la rama que seleccionamos como nuestra opción exitosa que en este ejemplo será “version_registro_uno”, para lo cual nos aseguramos primero de cambiarnos a nuestra rama "master" y desde ahí ejecutamos el "merge".

usuario@terminal:~/Documentos/Web$ git checkout master 
 Cambiado a rama 'master' 
usuario@terminal:~/Documentos/Web$ git branch -d version_registro_dos 
 Eliminada la rama version_registro_dos (era fcafd4b).. 
usuario@terminal:~/Documentos/Web$ git merge version_registro_uno 
 Actualizando 15f8e98..1b286bf 
  Fast-forward 
   registro.php | 0 
   1 file changed, 0 insertions(+), 0 deletions(-) 
   create mode 100644 registro.php

Listo, de este modo hemos fusionado (“merge” es el termino en inglés) los archivos que hemos modificado dentro de una de las dos ramas experimentales, en este caso “version_registro_uno“, con la rama “master“. Cabe mencionar que esto no elimina la rama experimental, solamente traslada los cambios, posteriormente podemos eliminar la rama experimental existosa pues los cambios ya se copiaron a nuestra rama principal. Para eliminar esta otra rama simplemente usamos, como hicimos con “version_registro_dos”, el comando « git branch -d » seguido del nombre de la rama a eliminar.

Nota: a veces, si no trabajamos con suficiente orden puede ocurrir que se genere un error de conflicto entre las dos o más ramas a fusionar, lo que nos resultará en un mensaje de error. Para resolver esto podemos utilizar « git merge --abort » que dará un paso atrás en el proceso de fusión, regresando al commit anterior a la fusión, y es por esto que es importante siempre realizar los commits dentro de cada rama correctamente antes de fusionar, de otro modo el comando no sabrá a qué estado anterior regresar y la fusión resultará en un fracaso.

VII. Restaurar un estado previo de nuestro proyecto grabado en el historial de Git

Si has llegado hasta este punto es probable que ya hayas incluso olvidado que Git es un “sistema de control de versiones”, pero aguanta un poco más, de cualquier manera puedes siempre regresar a este tutorial para refrescarte la memoria. El punto de un sistema de control de versiones es justamente poder explorar los cambios que hemos realizado en nuestro proyecto ¿cierto?

Bien, para esto existe el comando « git log », con el cual vamos a conocer todos y cada uno de los commits que hemos realizado desde que iniciamos el proyecto, recordemos que todo queda guardado en el historial de Git. Aparecerá un listado en donde cada entrada comienza con un código único de cada commit, una serie larga de números y letras, esa cadena alfanumérica se le conoce como el “hash” del commit.

usuario@terminal:~/Documentos/Web$ git log 
commit 15f52352343252356326
Author: usuario email@email.com 
 Date: Fri Jun 4 20:34:25 2021 -0500 ultimo 

commit en donde fusione una branch con master 

commit 32487390482394j23492
Author: usuario email@email.com 
 Date: Wed Feb 3 15:37:50 2021 -0600 

en este commit yo borré el archivo style.css 

commit dc0ac8234h23i42342fr
Author: usuario email@email.com 
 Date: Thu Jan 21 18:11:29 2021 -0600 

en este commit he creado el archivo index.html 

(END)

Nota: podemos hacer scroll con el botón de flacha-abajo del teclado para explorar los commits más antiguos (recuerda que Git almacena absolutamente todos los commits que hayas hechos, de inicio a fin), y una vez que llegamos al final de nuestros commits aparecerá la palabra (END). Para salir de ahí, ya sea que estemos al inicio, en algun punto intermetio o en el (END) de nuestro log, oprimimos la tecla del caracter «q» del teclado, lo cual nos saca de la vista de revisión de commits de regreso a nuestra pantalla de comandos.

Gracias a Git, podemos revertir el estado actual de nuestro proyecto a cualquier momento previo de nuestro log, esto lo hacemos con diferentes comandos que actuan similar pero tienen algunas diferencias, en este tutorial vamos a ver solamente dos opciones, pues las posibilidades son bastante extensas y ameritan un tutorial específico para todos los métodos de restauración de pasos anteriores, pero por el momento estos dos métodos son los más sencillos y que hacen lo básico: regresar a un estado anterior rápidamente.

1. « git revert » elimina el commit que especifiques a través de su hash, y además genera un commit nuevo, señalando que se revirtió la bitácora de cambios justo hasta un punto anterior al que señalaste. Por ejemplo, digamos que tienes 100 commits hasta este momento, es decir 100 estados diferentes de actualizaciones que has ido registrando; y digamos que ahora que estás en el commit #100 que es obviamente el más nuevo, te arrepentiste de los últimos 30 commits más recientes y quieres regresar al estado de tu proyecto #70, así que primero haces « git log » para abrir tu listado de commits, de desplazas hasta el commit #71, ojo no el #70 sino el #71, revisas su marcador alfanumérico o "hash", y entonces haces « git revert » seguido por el hash, digamos el hash "32487390482394j23492", con lo que nuestra sintaxis completa sería « git revert 32487390482394j23492 ». Con esto anterior lo que va a ocurrir es que tu proyecto va a descartar los cambios del commit que elegiste y te dejará en el estado del commit anterior a ese, por eso no elegimos el #70, sino el #71, para borrar ese commit #71 y así quedarte en el estado anterior que viene siento el commit #70.
2. « git reset » funciona un poco diferente a revert en el sentido de seleccionar a qué punto vas a regresar. Con « git reset » lo que va a ocurrir es que se eliminarán todos los cambios, incluyendo commits, desde el punto actual hasta el punto que elijas regresar, y no se hará ningún commit con respecto a este cambio como con « git revert », simplemente daremos pasos atras, borrando todo lo que esté a su paso, incluyendo archivos y commits. Pongamos un ejemplo similar al anterior: estamos en el commit #100 y queremos regresar al estado del #70, así que vamos a ejecutar « git reset --hard », noten que agregamos "--hard" (Nota: son dos guiones antes de "hard"), seguido del hash del estado al que queremos regresar, el #70, que digamos que es "dc0ac8234h23i42342fr", así que la sintaxis completa sería así « git reset --hard dc0ac8234h23i42342fr ». Ojo, aquí estamos señalando el hash del commit #70, no el del #71 como haríamos en « git revert » sino que directamente ingresamos el hash del estado al que queremos regresar. Esto nos regresará exactamente al estado de nuestro proyecto tal cual como estaba en el commit #70.

¿Se ven las diferencias? mientras que « git revert » te solicita que ingreses el hash del commit que deseas eliminar para luego generar un commit de este retroceso señalando que se revirtió todo a como estaba antes de el commit que señalaste, es decir un paso antes, con « git reset » pasa diferentes, pues no señalamos el commit que queremos borrar, sino que señalamos al commit al que queremos volver y « git reset » no va a generar un commit propio anunciando que revertimos un cambio, simplemente eliminará todo a su paso hasta regresar al estado que le señalamos.

En el próximos tutorial aprenderemos los comandos online de Git, para así conectarnos a un repositorio como GitHub y poder así realizar un proyecto de forma cooperativa con cualquier persona que tenga una cuenta de GitHub y también veremos más a profundidas los diferentes métodos y casos para usar o bien git revert o git reset y sus especificaciones ¡Hasta la próxima!

Glosario

Ya que Git está escrito originalmente en inglés, hay varios comandos y nombres de procesos que están en su idioma original, por lo que en este glosario puedes encontrar algunos términos importantes, sus nombres en español y en inglés, así como sinónimos que usamos en este tutorial.

• Directorio, sinónimo para Folder o Carpeta
• Staging area, lo hemos mencionado como área de staging, y también lo conocemos como Index. Stage es una palabra inglesa para "escenario"
• Directorio de trabajo NO es lo mismo que el staging area. El directorio de trabajo es el Folder en donde se encuentra contenido todo nuestro proyecto, mientras que el "staging area" es el nombre de una de las platafórmas dentro de la lógica de flujo de Git.
• En inglés "staging" significa "pasar algo al escenario", cuando registramos un cambio desde nuestro directorio de trabajo, a través del comando « git add » estamos "pasando tales cambios al escenario" (recordemos que este "escenario" se llama Index) para posteriormente de allí consolidar los cambios hacia el HEAD.
• En Git, cuando usamos el comando « git add », aunque "add" sea la expresión inglesa para "añadir", tenemos que saber que no estamos "añadiendo" archivos, sino que estamos añadiendo un cambio, y este cambio puede ser lo que sea, agregar un archivo nuevo, modificar un archivo existente o incluso eliminar algo, entonces en este caso "add" no señala que estemos solamente agregando un archivo, sino que estamos agregando un cambio a la lista de cambios, sea cual sea este cambio.
• "Merge" en inglés significa fusionar.
• "Log" en inglés significa registro, como un registro en una bitácora; lo que Git guarda son "logs" de los cambios.
• "Commit" en inglés significa "hacer cambios, entregarse a una causa, preservar para el futuro", y eso es justo lo que el comando « git commit » , que es la base de la escencia de Git como un software de control de versiones. ¡Git se trata completamente de hacer commits!