No sé mucho de GIT pero tiro palante

Llevo programando y usando 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 소프트웨어 제어 버전, 퀴즈 esto ya lo sabíamos, pero 퀴즈 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. 가장 중요한 문제 중 하나는 Git의 커밋에 대해 새로운 코드를 작성하고 작업을 완료하고 개인을 식별하기 위한 새로운 프로젝트의 "버전"을 실행하는 것입니다. ¿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 이니셜.

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. 중요하지만 중요한 것은 GitHub가 새로운 버전을 사용하지 않는 경우 Git para recoger o dar información에 단독으로 연결하여 entender en este punto가 커밋을 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 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 thinko 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".