##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](https://git-scm.com/book): >_"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**). ![Areas GIT](https://dev-to-uploads.s3.amazonaws.com/i/yar2xwjkx171ysqx5gpy.png) Fuente [git-scm.com/book](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Fundamentos-de-Git) 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. ![Estados GIT](https://dev-to-uploads.s3.amazonaws.com/i/p0g697j92mb20p33lofh.png) Fuente [git-scm.com/book](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio) *** ##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](https://git-scm.com/)) y algún editor de código para poder trabajar. En mi caso, recomiendo _Visual Studio Code_, el cual pueden descargar en este [link](https://code.visualstudio.com/)
Una vez instalado todo, necesitamos integrar la terminal de Git para poder trabajar con mayor fluidez y facilidad. Les dejo este [tutorial](https://youtu.be/EVh36sDppcs), indicando cómo se realiza esta configuración. {% youtube EVh36sDppcs %}
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. ![Archivo en blanco](https://dev-to-uploads.s3.amazonaws.com/i/9ksupq19at1avvcakc82.png)
Abrimos la Terminal en VSC, yendo a _View_->_Terminal_ (o Ctrl+ñ como atajo).
Podemos verificar la versión de GIT ingresando el siguiente comando. {% gist https://gist.github.com/juanfrasca/6d2e509b1583a74e89b4343cd96b8aef %} Si está todo correctamente instalado, en la terminal nos arrojará una leyenda similar a esta:![Version](https://dev-to-uploads.s3.amazonaws.com/i/avwlzm4922yopileoud1.png)
Configuramos nuestro nombre de usuario y email, ingresando el siguiente comando. {% gist https://gist.github.com/juanfrasca/69b29a1df44c818d5934be479143aa5c %} Para analizar si quedó registrado el usuario y email, podemos realizar una revisión como la siguiente: ![Revisar config](https://dev-to-uploads.s3.amazonaws.com/i/54vgiwddhyac99c40c54.png)
Inicializamos nuestro repositorio ingresando {% gist https://gist.github.com/juanfrasca/9aba618a662211b37876424a10a1a547 %} Como resultado, veremos lo siguiente:
- En nuestra terminal de VSC, aparecerá la siguiente leyenda:![Repositorio inicializado](https://dev-to-uploads.s3.amazonaws.com/i/njnzywms6lyjw2a6jtpn.png)
- 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 ![Untracked](https://dev-to-uploads.s3.amazonaws.com/i/64dlloy604lrc4rk23uz.png)
- Para que el archivo ingrese a nuestra **área de preparación**, debemos agregarlo {% gist https://gist.github.com/juanfrasca/0627ae6b0aac17c062803c4936353bd9 %} Al agregarlo, el estado de nuestro archivo cambiará a _added_ ![Added](https://dev-to-uploads.s3.amazonaws.com/i/ujqbre12cu2xydsruj05.png)
- Al realizar cualquier cambio en nuestro archivo y **guardarlo**, veremos que el estado del mismo cambia a _modified_ ![Modified](https://dev-to-uploads.s3.amazonaws.com/i/72xi5169c1zll81rblgz.png)
- 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 ![Added2](https://dev-to-uploads.s3.amazonaws.com/i/3ycg61204y7rnsdtef0j.png)
- 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). {% gist https://gist.github.com/juanfrasca/e95911da0feca1f98d42b364923b9848 %} 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 ![Commit](https://dev-to-uploads.s3.amazonaws.com/i/hz2z8bg0kdai7hee7ns4.png) Además, observamos que nuevamente nuestro archivo volvió a su estado original ![Commit2](https://dev-to-uploads.s3.amazonaws.com/i/rc91gje1jk1uy4tm3w3t.png) 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. ![Commit3](https://dev-to-uploads.s3.amazonaws.com/i/oeb9zqlsk15d98dmhn6k.png) Por otro lado, también podemos revisar todos los commits que hemos realizado sobre un archivo, ingresando {% gist https://gist.github.com/juanfrasca/183078e0e0bcda04d407fafd4cb207f1 %} ![Log-online](https://dev-to-uploads.s3.amazonaws.com/i/u70vt0gpha0tqbaq52ut.png) 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 {% gist https://gist.github.com/juanfrasca/11e43e2d7cd9694e6ee7594e634fa6b3 %} ![Reset](https://dev-to-uploads.s3.amazonaws.com/i/zvkxf902m277novlybpq.png) Y, como pueden ver, nuestro archivo volvió a la versión original ![Reset2](https://dev-to-uploads.s3.amazonaws.com/i/w18pgpafndl9xqbf7lg4.png) 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 ![Status](https://dev-to-uploads.s3.amazonaws.com/i/ze2dk23ph8splnhkkqu0.png)
- Dentro de [GitHub](https://github.com/), una vez **creado nuestro usuario**, creamos un nuevo repositorio, dando click en _New_, en la esquina superior izquierda ![New Repository](https://dev-to-uploads.s3.amazonaws.com/i/89ojgdwgxilqjwmr9aza.png)
- 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_ ![New Repository2](https://dev-to-uploads.s3.amazonaws.com/i/ddquvsxdtvwf9l8j8ex9.png)
- Dentro de GitHub, existen diferentes formas de inicializar el repositorio. ![Subir repositorio a GitHub](https://dev-to-uploads.s3.amazonaws.com/i/uqyk8et2eyc6x3dw456e.png) 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 ![Push](https://dev-to-uploads.s3.amazonaws.com/i/2fvqq2kzy3j8vocz68iu.png) Una vez ingresada la última línea, veremos algo como esto ![Push2](https://dev-to-uploads.s3.amazonaws.com/i/y8asvy4myu1dl5jp7tuv.png)
- 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. ![GitHub](https://dev-to-uploads.s3.amazonaws.com/i/uv5ie9bmeuhpzdkn5xo7.png)
- 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. {% gist https://gist.github.com/juanfrasca/3ffdfc071f1256dc60d888d0019f9b16 %} 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_ ![Delete](https://dev-to-uploads.s3.amazonaws.com/i/7wikkyyp2unf7xzc3nfl.png) Damos la confirmación para realizar la acción y ya está. ![Delete2](https://dev-to-uploads.s3.amazonaws.com/i/2a0qcnfrx92idlysf6b0.png) ![Delete3](https://dev-to-uploads.s3.amazonaws.com/i/2rb0dn167f5i45r410gj.png) Cualquier duda que tengas al respecto, se puede consultar la [Documentación de GitHub](https://docs.github.com/es). *** ###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!

juanfrasca

Aprendiendo GIT (Mi primer repositorio)

Join Our Newsletter. No Spam, Only the good stuff.