Aprende los fundamentos de Git en menos de 10 minutos

por Gowtham Venkatesan

Sí, el título es un clickbait. No hay manera de que puedas entender los fundamentos de la tecnología git en sólo 10 minutos. Pero puedes acercarte bastante en unos 25 minutos. Y ese es el objetivo de este artículo.

Si quieres iniciarte en el aprendizaje de la tecnología Git, has llegado al lugar adecuado. Esta es una completa guía para principiantes sobre Git. Hay muchos clientes para Git. La tecnología es la misma independientemente del cliente. Pero en esta guía usaremos GitHub para entender Git.

¡Comencemos!

¿Qué es el control de versiones?

El control de versiones es un sistema que registra los cambios realizados en un archivo o conjunto de archivos a lo largo del tiempo para poder recuperar versiones específicas más adelante. Así que, idealmente, podemos colocar cualquier archivo del ordenador en el control de versiones.

Umm… Vale… Pero, ¿por qué?

Aquí está el porqué:

Un sistema de control de versiones (VCS) le permite revertir archivos a un estado anterior, revertir todo el proyecto a un estado anterior, revisar los cambios realizados a lo largo del tiempo, ver quién fue el último en modificar algo que podría estar causando un problema, quién introdujo un problema y cuándo, y mucho más. El uso de un VCS también significa que si se estropean las cosas o se pierden archivos, generalmente se pueden recuperar fácilmente. Y a veces sólo quieres saber «quién escribió esta mierda», y tener acceso a esa información vale la pena…

¿Qué es Git?

Git es un sistema de control de versiones para rastrear los cambios en los archivos de la computadora y coordinar el trabajo en esos archivos entre varias personas. Git es un sistema de control de versiones distribuido. Así que Git no depende necesariamente de un servidor central para almacenar todas las versiones de los archivos de un proyecto. En su lugar, cada usuario «clona» una copia de un repositorio (una colección de archivos) y tiene el historial completo del proyecto en su propio disco duro. Este clon tiene todos los metadatos del original, mientras que el original en sí se almacena en un servidor propio o en un servicio de alojamiento de terceros como GitHub.

Git te ayuda a realizar un seguimiento de los cambios que haces en tu código. Es básicamente la pestaña del historial de tu editor de código(Sin modo incógnito?). Si en algún momento mientras codificas te encuentras con un error fatal y no sabes qué lo está causando siempre puedes volver al estado estable. Así que es muy útil para la depuración. O simplemente puedes ver qué cambios has hecho en tu código a lo largo del tiempo.

En el ejemplo anterior, las tres tarjetas representan diferentes versiones del mismo archivo. Podemos seleccionar qué versión del archivo queremos utilizar en cada momento. Así que puedo saltar a cualquier versión del archivo en el continuo temporal de git.

Git también te ayuda a sincronizar el código entre varias personas. Así que imagina que tú y tu amigo estáis colaborando en un proyecto. Ambos estáis trabajando en los mismos archivos del proyecto. Ahora Git toma esos cambios que tú y tu amigo hicieron independientemente y los fusiona en un solo repositorio «Maestro». Así que usando Git puedes asegurarte de que ambos estáis trabajando en la versión más reciente del repositorio. Así que no tienes que preocuparte de enviar tus archivos por correo al otro y trabajar con un número ridículo de copias del archivo original. Y colaborar a larga distancia se convierte en algo tan fácil como el HTML€/p>

Flujo de trabajo Git:

Antes de empezar a trabajar con los comandos Git, es necesario que entiendas lo que representa.

¿Qué es un repositorio?

Un repositorio a.k.a. repo no es más que una colección de código fuente.

Hay cuatro elementos fundamentales en el flujo de trabajo Git.

Directorio de trabajo, área de staging, repositorio local y repositorio remoto.

Si consideras un archivo en tu Directorio de Trabajo, puede estar en tres posibles estados.

1. Puede estar en fase. Lo que significa que los archivos con los cambios actualizados están marcados para ser confirmados en el repositorio local pero aún no están confirmados.
2. Puede estar modificado. Lo que significa que los archivos con los cambios actualizados aún no se almacenan en el repositorio local.
3. Puede ser comprometido. Lo que significa que los cambios realizados en el archivo se almacenan de forma segura en el repositorio local.

• git add es un comando que se utiliza para añadir un archivo que está en el directorio de trabajo al área de staging.
• git commit es un comando que se utiliza para añadir todos los archivos que están en fase al repositorio local.
• git push es un comando que se utiliza para añadir todos los archivos comprometidos en el repositorio local al repositorio remoto. Así, en el repositorio remoto, todos los archivos y cambios serán visibles para cualquiera que tenga acceso al repositorio remoto.
• git fetch es un comando utilizado para obtener archivos del repositorio remoto al repositorio local pero no en el directorio de trabajo.
• git merge es un comando utilizado para obtener los archivos del repositorio local al directorio de trabajo.
• git pull es un comando utilizado para obtener los archivos del repositorio remoto directamente al directorio de trabajo. Equivale a un git fetch y a un git merge .

Ahora que sabemos qué es Git y sus terminologías básicas, vamos a ver cómo podemos colocar un archivo bajo git. Lo vamos a hacer de la manera correcta y difícil. Sin ninguna aplicación GUI.

Estoy asumiendo que ya tienes un archivo que quieres colocar bajo el control de versiones. Si no es así crea una carpeta de ejemplo llamada ‘MuskCult’ y coloca algunos archivos de código de ejemplo en ella.

Paso 0: Haz una cuenta de GitHub. Duh.

Si aún no tienes una, puedes hacer una aquí.

Paso 1: Asegúrate de que tienes Git instalado en tu máquina.

Si estás en un Mac, enciende el terminal e introduce el siguiente comando:

$ git --version

Esto te pedirá que abras un instalador si aún no tienes git. Así que configúralo usando el instalador. Si ya tienes git, sólo te mostrará qué versión de git tienes instalada.

Si estás ejecutando Linux(deb), introduce lo siguiente en la terminal:

$ sudo apt install git-all

Si estás en Windows:

$ get a mac

Es broma… Relájate… La cantidad de gente que desencadené… Ufff…
Ve a este enlace o a este otro para más información sobre cómo conseguirlo.

Paso 2: Dile a Git quién eres.

Preséntate. Deslízate hacia adentro. En serio, menciona tu nombre de usuario de Git y tu dirección de correo electrónico, ya que cada commit de Git utilizará esta información para identificarte como autor.

$ git config --global user.name "YOUR_USERNAME" 

$ git config --global user.email "[email protected]"

$ git config --global --list # To check the info you just provided

Paso 3: Genera/comprueba en tu máquina las claves SSH existentes. (Opcional)

¿Por qué lo preguntas? Usando el protocolo SSH, puedes conectarte y autenticarte a servidores y servicios remotos. Con las claves SSH, puedes conectarte a GitHub sin tener que suministrar tu nombre de usuario o contraseña en cada visita.

Sigue este enlace para aprender más sobre SSH.
Ve aquí para comprobar si tienes una clave SSH existente.
Ve aquí para generar una clave SSH.
Ve aquí para añadir la clave SSH a tu cuenta de GitHub.
Y finalmente ve aquí para probar su conexión.

Si has configurado SSH, cada comando de git que tenga un enlace lo sustituyes por:

Instead of : https://github.com/username/reponame

You use : [email protected]/username/reponame.git

 Note : You can use both ways alternatively

En este tutorial utilizaré el protocolo SSH.

Paso 4: Hagamos Git

Crea un nuevo repositorio en GitHub. Sigue este enlace.
Ahora, localiza a la carpeta que quieres colocar bajo git en tu terminal.

$ cd Desktop/MuskCult

Inicia Git:

Y para colocarlo bajo git, introduce:

$ touch README.md # To create a README file for the repository$ git init # Initiates an empty git repository

Ahora ve a editar el archivo README.md para proporcionar información sobre el repositorio.

Añadir archivos al área de staging para el commit:

Ahora a añadir los archivos al repositorio git para el commit:

$ git add . # Adds all the files in the local repository and stages them for commit

OR if you want to add a specific file

$ git add README.md # To add a specific file

Antes de hacer el commit vamos a ver qué archivos están staged:

$ git status # Lists all new or modified files to be committed

Commitamos los cambios que has hecho en tu Git Repo:

Ahora a cometer los archivos que has añadido a tu git repo:

$ git commit -m "First commit"# The message in the " " is given so that the other users can read the message and see what changes you made

Desconfirmar los cambios que acabas de hacer en tu Git Repo:

Ahora supongamos que acabas de cometer algún error en tu código o has colocado un archivo no deseado dentro del repositorio, puedes desconfirmar los archivos que acabas de añadir utilizando:

$ git reset HEAD~1# Remove the most recent commit# Commit again!

Añadir un origen remoto y Push:

Ahora cada vez que hagamos cambios en nuestros archivos y lo guardemos, no se actualizará automáticamente en GitHub. Todos los cambios que hicimos en el archivo se actualizan en el repositorio local. Ahora para actualizar los cambios en el master:

$ git remote add origin remote_repository_URL# sets the new remote

El comando git remote te permite crear, ver y eliminar conexiones a otros repositorios.

$ git remote -v# List the remote connections you have to other repositories.

El comando git remote -v lista las URLs de las conexiones remotas que tienes con otros repositorios.

$ git push -u origin master # pushes changes to origin

Ahora el comando git push empuja los cambios de tu repositorio local al repositorio remoto que has especificado como origen.

Y ahora si vamos a consultar la página de nuestro repositorio en GitHub debería verse algo así:

Y ya está. Acabas de añadir los archivos al repositorio que acabas de crear en GitHub.

Ver los cambios que has hecho en tu archivo:

Una vez que empieces a hacer cambios en tus archivos y los guardes, el archivo no coincidirá con la última versión que fue confirmada en git. Para ver los cambios que acabas de hacer:

$ git diff # To show the files changes not yet staged

Vuelve a la última versión confirmada en el Git Repo:

Ahora puedes elegir volver a la última versión confirmada introduciendo:

$ git checkout .

OR for a specific file

$ git checkout -- <filename>

Ver el historial de commits:

Puedes utilizar el comando git log para ver el historial de commit que has realizado en tus archivos:

$ git log

Cada vez que realices cambios que quieras que se reflejen en GitHub, el siguiente es el flujo de comandos más habitual:

$ git add .$ git status # Lists all new or modified files to be committed$ git commit -m "Second commit"$ git push -u origin master

Ahora bien, si vamos a ver nuestro repo, podemos identificar si el commit fue exitoso mirando el mensaje de commit de cada archivo.

Paso 5 : Todo esto está muy bien… ¿Pero cómo descargo y trabajo en otros repositorios de GitHub?

Clonando un Repo Git:

Localiza al directorio que quieres clonar el repo. Copia el enlace del repositorio que quieras e introduce lo siguiente:

$ git clone remote_repository_URL

Siéntete libre de seguir adelante y clonar el repo que he creado arriba usando: https://github.com/Gothamv/MuskCult

Pulsando cambios al Git Repo:

Ahora puedes trabajar en los archivos que quieras y confirmar los cambios localmente. Si quieres empujar los cambios a ese repositorio tienes que ser añadido como colaborador para el repositorio o tienes que crear algo conocido como pull request. Ve a ver cómo hacer uno aquí y dame un pull request con tu archivo de código.

Colaborando:

Así que imagina que tú y tu amigo estáis colaborando en un proyecto. Ambos estáis trabajando en los mismos archivos del proyecto. Cada vez que haces algunos cambios y los empujas al repo maestro, tu amigo tiene que tirar de los cambios que empujaste al repo git. Es decir, para asegurarte de que estás trabajando en la última versión del repositorio git cada vez que empiezas a trabajar, un comando git pull es el camino a seguir.

Ahora, a continuación, un ejemplo de un proyecto en el que mi amigo y yo estamos colaborando:

Así que para asegurarme de que esos cambios se reflejan en mi copia local del repo:

$ git pull origin master

Aquí hay dos comandos git más útiles:

$ git fetch AND$ git merge

En los términos más simples, git fetch seguido de un git merge equivale a un git pull. Pero entonces, ¿por qué existen estos?

Cuando usas git pull, Git intenta hacer el trabajo automáticamente por ti. Es sensible al contexto, por lo que Git fusionará cualquier commits extraído en la rama en la que estés trabajando en ese momento. git pull fusiona automáticamente los commits sin permitirte revisarlos primero.

Cuando git fetch, Git recoge cualquier commit de la rama de destino que no exista en tu rama actual y los almacena en tu repositorio local. Sin embargo, no los fusiona con tu rama actual. Esto es particularmente útil si necesitas mantener tu repositorio actualizado, pero estás trabajando en algo que podría romperse si actualizas tus archivos. Para integrar los commits en tu rama maestra, utilizas git merge.

Una cosa más:

.gitignore

Entonces, ¿qué es?

.gitignore le dice a git qué archivos (o patrones) debe ignorar. Normalmente se utiliza para evitar confirmar archivos transitorios de tu directorio de trabajo que no son útiles para otros colaboradores, como productos de compilación, archivos temporales que crean los IDEs, etc.

Así que en el ejemplo anterior, archivos como __pycache__, .DS_Store son utilizados por el sistema para almacenar información para un acceso más rápido. Esto no es útil para otros colaboradores. Así que podemos decirle a git que los ignore añadiendo un archivo .gitignore.

Usa el comando touch para crear el archivo .gitignore:

$ touch .gitignore

Y puedes añadir los siguientes patrones para decirle a git que ignore dichos archivos.

/*.cmake/*.DS_Store/.user/buildetc. depending upon the files you want git to untrack

Y eso es más o menos todo lo básico. Estad atentos a la Parte 2 que se centrará en Branch, Merge, Stash, Rebase, etc.

Si os ha gustado el artículo, no olvidéis aplastar ese botón de Clap y aseguraos de seguirme para la Parte 2.

Referencias :

Añadir un proyecto existente a GitHub usando la línea de comandos – Documentación de usuario
Poner tu trabajo existente en GitHub puede permitirte compartir y colaborar de muchas maneras. Si estás migrando tu…help.github.comCómo deshacer (casi) todo con Git
Una de las características más útiles de cualquier sistema de control de versiones es la posibilidad de «deshacer» tus errores. En Git, «deshacer»…blog.github.comGit en la línea de comandos – No tengas miedo de hacer commit 0.3 documentación
Hay otras formas de instalar Git; incluso puedes conseguir una aplicación gráfica de Git, que incluirá la línea de comandos…dont-be-afraid-to-commit.readthedocs.ioComienza a usar Git en la línea de comandos | GitLab
Documentación para GitLab Community Edition, GitLab Enterprise Edition, Omnibus GitLab, y GitLab Runner.docs.gitlab.com¿Cuál es la diferencia entre ‘git pull’ y ‘git fetch’?
Nota del moderador: Dado que esta pregunta ya ha tenido sesenta y siete respuestas publicadas (algunas de ellas eliminadas)…stackoverflow.com