Aprendiendo GIT (Mi primer repositorio)

Bienvenidos a mi primer post!

En este post, voy a dejarles un tutorial, paso por paso, con el cual van a poder comenzar a iniciarse en el mundo de GIT, uno de los VCS (Sistema de Control de Versiones) más utilizados hoy en día.

Antes de comenzar, deberíamos responder la pregunta ¿qué es un VCS?
Basándonos en la fuente original de la página de GIT:

"Un control de versiones es un sistema que registra los cambios realizados en un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante.

Un sistema de control de versiones (VCS por sus siglas en inglés) te permite regresar a versiones anteriores de tus archivos, regresar a una versión anterior del proyecto completo, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que pueda estar causando problemas, ver quién introdujo un problema y cuándo, y mucho más. Usar un VCS también significa generalmente que si arruinas o pierdes archivos, será posible recuperarlos fácilmente.

Git maneja sus datos como un conjunto de copias instantáneas de un sistema de archivos miniatura. Cada vez que confirmas un cambio, o guardas el estado de tu proyecto en Git, él básicamente toma una foto del aspecto de todos tus archivos en ese momento y guarda una referencia a esa copia instantánea."

Ahora que ya sabemos qué es GIT y para qué nos sirve, necesitamos entender un poco más los diferentes estados que tendrán nuestros archivos.

Git tiene tres estados principales en los que se pueden encontrar tus archivos: confirmado (committed), modificado (modified), y preparado (staged).

Confirmado: significa que los datos están almacenados de manera segura en tu base de datos local.
Modificado: significa que has modificado el archivo pero todavía no lo has confirmado a tu base de datos.
Preparado: significa que has marcado un archivo modificado en su versión actual para que vaya en tu próxima confirmación.

Esto nos lleva a las tres secciones principales de un proyecto de Git: El directorio de Git (Git directory), el directorio de trabajo (working directory), y el área de preparación (staging area).

Fuente git-scm.com/book

En función de esto, el flujo de trabajo básico en Git es algo así:

Modificas una serie de archivos en tu directorio de trabajo.
Preparas los archivos, añadiéndolos a tu área de preparación.
Confirmas los cambios, lo que toma los archivos tal y como están en el área de preparación y almacena esa copia instantánea de manera permanente en tu directorio de Git.

En conclusión, si una versión concreta de un archivo está en el directorio de Git, se considera confirmada (committed). Si ha sufrido cambios desde que se obtuvo del repositorio, pero ha sido añadida al área de preparación, está preparada (staged). Y si ha sufrido cambios desde que se obtuvo del repositorio, pero no se ha preparado, está modificada (modified).

Además de esta diferenciación de estados, es posible realizar una segunda categorización más amplia. Los tres estados mencionados anteriormente se denominan archivos rastreados (tracked) y son todos aquellos archivos que estaban en la última instantánea del proyecto. Por otro lado, se encuentran los archivos sin rastrear (untracked); cualquier otro archivo en tu directorio de trabajo que no estaba en tu última instantánea y que no está en el área de preparación (staging area).

Mientras editas archivos, Git los ve como modificados (modified), pues han sido cambiados desde su último commit. Luego preparas estos archivos modificados y finalmente confirmas todos los cambios preparados, y repites el ciclo.

Fuente git-scm.com/book

Ahora sí.

Hemos definido qué es GIT, su utilidad y los diferentes estados que puede ir tomando un archivo.
A continuación, veremos los comandos más básicos a utilizar para poder trabajar con GIT y cómo debemos proceder para cargar nuestro archivo en un repositorio de GIT.

Primero que nada, debemos tener instalado el propio GIT (les dejo este link de descarga) y algún editor de código para poder trabajar. En mi caso, recomiendo Visual Studio Code, el cual pueden descargar en este link
Una vez instalado todo, necesitamos integrar la terminal de Git para poder trabajar con mayor fluidez y facilidad. Les dejo este tutorial, indicando cómo se realiza esta configuración.
Desde Visual Studio Code (VSC de ahora en más), creamos un archivo (puede ser de cualquier formato) que será el que terminaremos subiendo a nuestro repositorio. Para el ejemplo de este tutorial, crearemos un archivo .txt, el cual estará totalmente en blanco hasta que decidamos comenzar a modificarlo.
Abrimos la Terminal en VSC, yendo a View->Terminal (o Ctrl+ñ como atajo).
Podemos verificar la versión de GIT ingresando el siguiente comando.

Si está todo correctamente instalado, en la terminal nos arrojará una leyenda similar a esta:
Configuramos nuestro nombre de usuario y email, ingresando el siguiente comando.

Para analizar si quedó registrado el usuario y email, podemos realizar una revisión como la siguiente:
Inicializamos nuestro repositorio ingresando

Como resultado, veremos lo siguiente:
- En nuestra terminal de VSC, aparecerá la siguiente leyenda:
- En el costado izquierdo de VSC, donde se encuentra nuestro archivo creado, veremos que el mismo pasa a estar de color verde y con una letra U (de untracked) al costado

Siempre es posible revisar el estado de nuestro archivo, ingresando

Para que el archivo ingrese a nuestra área de preparación, debemos agregarlo

Al agregarlo, el estado de nuestro archivo cambiará a added
Al realizar cualquier cambio en nuestro archivo y guardarlo, veremos que el estado del mismo cambia a modified
Para que el archivo vuelta al estado de staged (o preparado), nuevamente debemos agregarlo, como hicimos en el paso 8. De esta manera, el archivo volverá a figurar como added, habiendo registrado nuestra modificación
Para poder ingresar nuestro archivo al directorio de GIT, debemos realizar lo que se denomina commit. De esa manera, se realiza una copia segura de todo el trabajo que hemos realizado (todavía de manera local en nuestro dispositivo).

En el comentario entre comillas debemos describir de la mejor manera posible los cambios que hemos realizado en este commit, de manera de tener una referencia en el futuro, en caso de querer volver a esta versión.

Una vez realizado el commit, obtendremos lo siguiente Además, observamos que nuevamente nuestro archivo volvió a su estado original

Si nuevamente realizamos una modificación a nuestro archivo, volverá al estado de modified, por lo que tendremos que realizar un nuevo add para regresarlo a la zona de stage (lo mismo deberíamos hacer si eliminamos un archivo). Luego, deberíamos realizar un nuevo commit para que quede subido al directorio de GIT.

Por otro lado, también podemos revisar todos los commits que hemos realizado sobre un archivo, ingresando

El HEAD indica sobre el commit que estaríamos trabajando actualmente y los códigos en amarillo son los ID de cada commit. De esta manera, si quisiéramos volver a una versión anterior (o posterior), utilizamos

Y, como pueden ver, nuestro archivo volvió a la versión original De igual manera, podemos trabajar con varios archivos en paralelo al mismo tiempo (teniendo en cuenta que todos deben llegar al estado de staged antes de poder realizar el commit al directorio de GIT) y después volver a versiones anteriores. La ventaja de GIT es que, si un archivo no es modificado, no se le asigna el nuevo commit, por lo que queda registrada la última versión donde tuvo un cambio.

Un dato a tener en cuenta es que, si volvemos a una versión anterior donde todavía no habíamos creado algún archivo, éste "desaparecerá" (en VSC aparecerá la palabra (deleted) en su pestaña). Sin embargo, no hay que preocuparse, ya que, si volvemos al commit original, ese archivo volverá a aparecer.
Cuando ya hemos realizado todos los commits necesarios, si revisamos el estado de nuestros archivos, aparecerá lo siguiente, que indica que estamos en condiciones de subir los archivos a GitHub
Dentro de GitHub, una vez creado nuestro usuario, creamos un nuevo repositorio, dando click en New, en la esquina superior izquierda
Asignamos el nombre de nuestro repositorio (no puede ser igual a otro ya existente dentro de nuestros repositorios creados), seteamos los parámetros que consideremos necesarios (el más importantes es establecer si nuestro repositorio será Público o Privado) y damos click a Create repository
Dentro de GitHub, existen diferentes formas de inicializar el repositorio. Una de las más sencillas es realizar un push del repositorio ya existente desde la terminal de VSC. Para eso, simplemente debemos ingresar, de a una por vez, las líneas indicadas en GitHub Una vez ingresada la última línea, veremos algo como esto
Si damos a actualizar en GitHub, veremos que ahora aparece nuestro repositorio con sus archivos y la última versión de commit activa. También es posible ver todos los commits históricos realizados, junto con las modificaciones correspondientes a cada uno.
Luego, una vez creado el repositorio en GitHub, comienza el ciclo nuevamente. Cada vez que creemos o modifiquemos un archivo, luego de realizar el add y, posteriormente, el commit, simplemente debemos realizar un push. Vale aclarar que no es necesario ingresar todos los comandos como la primera vez; simplemente se ingresa el último.

De esta manera, nuevamente queda actualizado nuestro archivo en GitHub.
Por último, si así lo quisiéramos, podemos eliminar nuestro repositorio de GitHub. Simplemente vamos a Settings y damos a Delete this repository Damos la confirmación para realizar la acción y ya está.
Cualquier duda que tengas al respecto, se puede consultar la Documentación de GitHub.

Con esto termina mi primer post.

Espero que les haya sido útil y, cualquier duda que tengan, comentario o crítica constructiva, pueden escribirme a juanfrasca@gmail.com

Saludos!