Llevo programando y usando GIT aproximadamente 7 meses, sin embargo nunca he tenido claro exactamente ni qué es, ni cómo funciona por detrás, ni cómo separar las funciones de GIT y las de GitHub. Un desastre, vamos. Pero para eso estamos aquí, para hacer una guía rápida y básica de GIT con todo lo que necesitamos saber para tirar palante con la vida como desarrolladoras.

Empezando por el principio... ¿Qué es GIT? Git es un software de control de versiones, quizá esto ya lo sabíamos, pero quizá no sabíamos que se trata de software libre, y que su mantenimiento actual recibe actualizaciones de aproximadamente 280 programadores.

Cuando iniciemos Git en un repositorio veremos que nos creará un subdirectorio llamado ".git". Este subdirectorio es el encargado de ir guardando el "esqueleto" de nuestro proyecto, esto es todos los archivos necesarios para su funcionamiento. A partir de este punto, iremos haciendo cambios y actualizaciones en nuestro código que podremos ir añadiendo a commits de Git, es decir, "versiones" de nuestro proyecto que se van quedando guardadas y plenamente identificadas de forma individual. ¿Y para qué todo este lío? Pues probablemente eso sea lo único que tengo claro escribiendo sobre Git, hacemos todo este lío porque pase lo que pase el software nos permitirá volver a cualquier versión anterior que necesitemos, es decir, si a mí un día se me ocurriera trabajar en un proyecto tomándome un chupito de tequila cada vez que escribo "lenght", al día siguiente podría recuperar la última versión antes del desastre.

Además, Git nos permite trabajar con "ramas". El trabajo con ramas, además de estar presente en infinidad de metodologías de workflow actuales, es muy útil para cualquier tipo de proyectos, incluso los más pequeños y personales. La creación de una nueva rama es simplemente la creación de una "copia" del proyecto tal como está, en la que podrás probar nuevas funcionalidades, estilos e ideas peregrinas sin miedo de romper nada de tu avance, ya que siempre tendrás tu copia idéntica a salvo en tu rama inicial.

Vale, y ahora, en toda esta bendita historia, ¿Dónde entran las plataformas como GitHub? Las plataformas como GitHub son servicios en línea a los que Git puede conectarse para subir o bajar código y recursos. Es importante, por tanto, entender en este punto que GitHub no gestiona nuestras versiones, solo se conecta con Git para recoger o dar información, o para crear nuevos commits que podamos realizar desde este repositorio remoto.

A mí, como profana, me ha resultado muy útil hacer un paralelismo entre GitHub y Google Drive (como servicio de almacenamiento) para entender todo esto: Si yo escaneo un documento con una app del móvil y posteriormente lo subo a Google Drive, lo único que hace Google es guardar ese archivo, no lo ha creado. Sin embargo, si lo deseo puedo utilizar Drive como editor de ciertos archivos, y esos archivos los puedo devolver de nuevo a local y seguir trabajando con él en el editor del ordenador que sea. Pues algo así es lo que yo entiendo que ocurre con GitHub.

Pero aunque yo considero súper necesario tener una desambiguación correcta de las herramientas que utilizamos antes de utilizarlas, vamos a lo que más mola, al tema que te quema, a los comandos más guays y necesarios de Git:

- git init: Inicia git, crea el subdirectorio .git que comentamos antes.
- git fetch: Revisa el repositorio remoto (el que tengamos en el servicio online X, por ejemplo en GitHub) en busca de cambios vs el local y se los descarga.
- git pull: Revisa el repositorio remoto (el que tengamos en el servicio online X, por ejemplo en GitHub) en busca de cambios vs el local, se los descarga, y los aplica a nuestra versión local.
- git add <nombre_archivo>: Añade el archivo que indiquemos a la versión (commit). Si indicamos git add -A le estaremos diciendo que añada todos los archivos para el nuevo commit.
- git commit -m "mensaje": Crea una versión con los cabios realizados en los archivos que hayamos añadido. El mensaje se utiliza para indicar una breve descripción de los cambios realizados. Según convención los commits acostumbran a ser en inglés, y comenzar por un verbo en infinitivo. (E.G "Add landing page styles").
- git push: Sube el commit realizado al repositorio remoto. Si estamos subiendo cambios en una nueva rama tendremos que indicar `git push -u origin <nombre_rama>`
- git status: Muestra el estado actual de la rama, como los cambios que hay sin commitear.
- git checkout -b <nombre_rama_nueva>: Crea una rama idéntica a en la que te encuentras con el nombre "nombre_rama_nueva", y una vez creada te lleva a esta rama nueva.
- git merge <nombre_rama>: Desde una rama X haremos merge de otra rama Y para unir ambas versiones. Realizar esta acción, dependiendo de la naturaleza de los cambios entre ambas ramas, derivará en un merge blando (git lo realizará solo y únicamente tendremos que confirmar) o un merge duro (tendremos que resolver conflictos manualmente e indicar con el código de qué rama nos queremos quedar).
- git branch -a: Crea una lista de todas las ramas (locales y remotas).
- git remote prune origin: Actualiza tu repositorio remoto en caso que algún otro desarrollador haya eliminado alguna rama remota.
- git reset --hard: Elimina todos los cambios realizados de los que aún no se haya hecho commit.
- git revert <commit>: Revierte el proyecto al commit "commit".