Bienvenid@ a esta pequeña guía para dar tus primeros pasos en Git. Una casa no se construye por el tejado. Por ello, para entender qué es Git necesitamos algunos cimientos que nos iluminen el camino en forma de definiciones.
Definición 1. Un control de versiones es una herramienta para gestionar cambios o colaborar con más personas en un mismo fichero.
Definición 1.1. Un repositorio es una colección de ficheros y directorios que vamos a querer versionar.
Definición 1.2. Un cambio es una modificación de ficheros.
Nuestro punto de partida será esta imagen mental que seguramente reconozcas a la hora de trabajar.
Dentro de esta herramienta de gestión, vamos a identificar diferentes formas de trabajar. De esta manera, identificamos dos tipos principales de controles de versiones.
• Control De Versiones Centralizado.
Para leer el Libro de Ajedrez, Dados y Tablas de Alfonso X el Sabio de la Real Biblioteca del Monasterio de San Lorenzo de El Escorial, hay que leerlo en persona. Si algún día me levanto y quiero estudiarlo en mi casa, tendré que conseguir una versión escaneada de los capítulos que me interesan. No me puedo llevar, ni copiar, el manuscrito entero. Si alguna persona tiene que restaurarlo, o Alfonso X resucita y quiere añadir nuevas jugadas, entonces, tiene que pedir un permiso y tendrá que acudir presencialmente a la biblioteca. Esta manera de modificar las grandes jugadas de ajedrez representa el funcionamiento de un control de versiones centralizado del siglo XIII.
• Control De Versiones Distribuido.
¡Enhorabuena! Eres una persona afortunada y tu profesora favorita sube sus apuntes al Moodle. Todos tenemos acceso a los apuntes de Geometría. Trabajas sobre ellos, garabateas, añades gráficas. No necesito estar en clase para ver los apuntes en la pizarra, porque los tengo descargados (offline). Tu profesora tampoco puede ver las atrocidades matemáticas que escribes porque todavía no le has mandado tus modificaciones (push/pull de archivos). Las erratas que veamos tienen que ser enviadas a la profesora, ella cambiará el archivo, y los estudiantes no se volverán a encontrar con un signo menos innecesario. Tu profesora está actuando como repositorio central, y en los procesos descritos se clasifica a nuestro protagonista : Git. Un sistema de control de versiones distribuido.
Una vez que tenemos ubicado qué es Git, te estarás planteando diferentes preguntas. Empecemos a responderlas.
1. ¿Necesito conocer algún otro término antes de empezar?
Es conveniente que además de tener en mente las definiciones que habíamos establecido como cimientos de nuestro camino, añadamos unos conceptos más a nuestro vocabulario.
Definición 2. Un registro histórico es la trazabilidad del fichero. Nos permite responder a las preguntas: ¿Quién lo modificó? ¿Cuándo?¿Por qué?
Definición 3. Un commit es la unidad mínima de almacenamiento.
2. ¿Para qué usamos Git?
Tomando el símil de la forma de trabajar de tu profesora favorita, podemos sacar algunas conclusiones sobre quién puede ser partícipe en el control de versiones.
Puedes usarlo de manera particular para gestionar las modificaciones que vas realizando en tu trabajo. Igualmente, podemos usar Git colaborando con más personas. Por ejemplo, nos permite sincronizar a todos los colaboradores en un proyecto a través de un repositorio central. En este caso el repositorio central/remoto se llama GitHub.
3. ¿Cómo trabajamos con las modificaciones de los ficheros?
Para responder a esta pregunta, hay que considerar tres identidades en las que vamos a ir pasando los archivos:
- Tu ordenadoe
- GitHub (el repositorio central/remoto)
- Un servidor
4. ¿Cómo interactuamos con el repositorio central aka GitHub?
La primera opción que tenemos es con la terminal de Git:
Si trabajar sobre la terminal no está en tus aficiones, quizás te interesa usar un cliente gráfico, como podría ser RStudio o VSCode (un editor de código).
Es Hora De Ponerse Manos A La Obra.
Resueltas las preguntas, es hora de ponerse manos a la obra y ver cómo funciona en la práctica todo lo que acabamos de mencionar utilizando en este caso VSCode. Acompáñame paso a paso y descubriremos el funcionamiento de todos los términos que acabamos de citar.
Creemos un nuevo repositorio en nuestra cuenta de GitHub (para disponer de una simplemente necesitas un correo electrónico ) desde VSCode.
Paso 1. Log In en GitHub
Paso 2. Creamos un nuevo repositorio en nuestra cuenta.
Paso 3. Queremos trabajar en local (es decir, queremos hacer todas las modificaciones desde nuestro ordenador o nuestro servidor local), necesitamos clonar nuestro repositorio. ¡Dibujar las flechas de nuestro esquema anterior!
Es hora de crear nuestro clon en VSCode. Aunque podemos usar los diferentes iconos, aquí usaremos la terminal, y usamos nuestra URL correspondiente en el modo SSH (para mayor seguridad).
¿Dónde encontrar la URL?
¿Cómo clonar en VSCode desde la terminal?
Al iniciar nuestro repositorio desde cero, tenemos que añadir algún archivo para empezar. ¡No queremos trabajar con un conjunto vacío! Desde GitHub nos recomiendan crear un archivo README.md y realizar nuestro primer commit, es decir, ¡nuestro primer cambio registrado!
Toda esta información es lo que aparece en el interior de tu nuevo repositorio. Esa parte de código que parece que va a generar una bomba nuclear al ejecutar:
Podemos tener cierta desconfianza al ejecutar estas líneas en nuestra terminal. Descubramos una por una qué es lo que nos intentan decir.
echo "# Unforgettable_Git >> README.md
En esta línea de código, creamos el archivo README.md para convertir nuestro ahora conjunto vacío, en un repositorio con aspiraciones.
git init
Al ejecutar, inicializamos nuestro repositorio.
git add README.md
Añadimos en nuestro repositorio el archivo README.md que hemos creado.
git commit -m "first commit"
Nos interesa guardar nuestro primer cambio con un mensaje para que nos quede muy claro que este es nuestro "first commit" en el repositorio.
A partir de ahora es necesario indicar dónde se van a guardar todos los cambios que vamos haciendo. Para ello, creamos una rama o branch.
git branch -M main
Esta es la rama principal que tendrá el registro de cambios almacenados (commits) . Por supuesto , podemos crear todas las ramas que queramos en las que añadiremos diferentes modificaciones. De momento no nos interesa para nuestros primeros pasos, pero es interesante observar la siguiente imagen para entender hasta dónde puede llegar la complejidad.
Además, de ponerle un bonito nombre a nuestro registro, cada vez que queramos trabajar en este repositorio copiar nuestro URL inicial para indicar dónde estamos trabajando sería tedioso, por eso vamos a ponerle un nombre original. Como el repositorio es el origen de nuestra aventura, le llamaremos ‘origin‘:
git remote add origin git@github.com:Aliiciaa/Unforgettable_Git.git
Aparentemente parece que todo está listo. No obstante, simplemente hemos registrado nuestro cambio. ¿Cómo lo podemos ver en GitHub?
“ Por favor git, podrías añadir mis cambios a ‘origin‘ sin salirte de la rama principal ‘main’ “ – dijo un usuario a la terminal.
git push origin
git push -u origin main
Si has seguido todos los pasos a la perfección, ¡ya podemos empezar a trabajar! Recuerda que hemos hecho nuestro primer repositorio, creado nuestro primer archivo, y lo mejor de todo, ya hemos hecho el primer commit y ha quedado registrado. Es más, si tuvieras curiosidad para ver cómo aparece en GitHub verás que puedes ver todas tus modificaciones y cuándo se hicieron. Ten cuidado con lo que registras porque tus errores más oscuros pueden quedar para la posteridad.
Hemos terminado con los pasos esenciales. Seguidamente, te pondrás a escribir código, y te interesará hacer un nuevo commit para dejar constancia de tus modificaciones. Para que puedas continuar usando Git y te conviertas en un experto, te mencionaré las últimas pinceladas que te ayudaran a volar de manera independiente en el proceso.
- Recuerda que a la hora de ‘hacer commit’ estamos registrando un cambio. Esto es, si perdemos nuestro trabajo en local, pero está registrado en GitHub siempre vamos a poder recuperarlo. ¡Qué alivio!
- Puede que de momento solo estés trabajando en tus propios archivos, pero cuando colaboras con más gente, les interesa saber por qué te dedicaste a borrar su código o añadir algunas líneas más. Escribe un mensaje extenso dando los motivos de cambio cuando ‘hagas un commit’. Facilitarán la lectura a tus colaboradores.
- En este momento, tanto cambio puede generar confusión en el camino. Anota estos comandos útiles para comprobar estos estados.
git log
Permite ver los commits que hemos hecho en el repositorio.
git status
Permite comprobar el estado de nuestro archivo. ¿Hemos registrado nuestras modificaciones? ¿Hemos cambiado algo? ¿Nos falta algún paso que se nos haya podido olvidar?
Estados de nuestros ficheros. Aunque de manera impulsiva queremos realizar más commits, tenemos que conocer los estados de los cambios y cómo quedan representados, para no perdernos en la emoción.
- Estado modificado : [directorio.git] Todo OK, todo listo y registrado en git.
- Estado preparado: [working directory] trabajando en local listo para registrar. Bienvenido al área de preparación, nos indica que ficheros de los modificados son los que vamos a hacer commit. Si está vacía, todo perfecto, y todo está limpio (‘clean’).
- Estado confirmado: [staging area] aquí se está esperando a subir y confirmar lo que hemos hecho para que esté en el repositorio central.
Si quieres estar al día de nuestras publicaciones síguenos en LinkedIn o visítanos en www.komorebi.a
