En el post anterior, dejé una brevísima pero concisa introducción de lo que es Git, sus términos importantes y la instalación. En este seguiremos con la teoría pero enfocada en ampliar el vocabulario y conocer más en detalle cómo funciona y reafirmar el conocimiento. Como comenté en el post anterior, conocer los conceptos básicos de Git nos ayuda a buscar mejor nuestras dudas y encontrar solución a los errores que se presenten (no todo es ChatGPT).
Contenido
Qué es un repositorio
Uno de los conceptos básicos de Git es el repositorio (repository) o repo es el lugar donde se almacena toda la información del proyecto, incluyendo los archivos, su historial, tags, etc. A efectos prácticos digamos que es el directorio que contiene todo el proyecto.
Cuando creas un repositorio git init -b main, dentro del directorio se crea otro oculto llamado .git, que sería la base de datos donde se guardan todo los datos que el repo controla.
Si haces un cambio en algún archivo del directorio, Git detecta estos cambios y al ejecutar el comando git status te muestra todo lo que hace falta por hacerle commit, ya sean cambios a archivos, cambios de nombre de archivos, etc.
Estado de archivos
En Git los archivos pueden tener estados. Estos pueden ser:
Tracked
Son aquellos archivos que de los que Git ya tiene conocimiento que existen, lo que quiere decir que ya está en su base de datos. Dentro de estos encontramos dos sub-estados. Modified y Unmodified, estos indican si han sufrido algún cambio o no, respectivamente, desde el último commit registrado en tu repo local.
Untracked
Estos archivos no están incluidos en la base de datos del repo. Esto es porque el hecho de que un archivo esté en el directorio (junto con todos los demás) no quiere decir que exista en la base de datos. Git detecta que hay un archivo nuevo del que no tiene conocimiento, pero no ha trabajado con él.
Para incluir un archivo con estado Untracked, debes ejecutar:
git add archivo.html
Si ejecutas de nuevo el comando git status debe mostrarte el archivo en la sección Changes to be committed:.
Áreas de trabajo en Git
Cuando trabajas con un repo en Git, los archivos, además de los estados mencionados anteriormente, también se encuentran en diferentes áreas de trabajo diferentes.
Working directory
Este es básicamente el directorio en tu computadora, en tu sistema de archivos. Puedes modificar, borrar o agregar contenido sin afectar al repositorio “compartido” por todos.
Staging area
Cuando editas un archivo, este cambia de estado (como lo vimos arriba), antes de guardarlo definitivamente en el repositorio, este archivo deben pasar por un área intermedia llamada Staging.
Debemos hacer una aclaración. Imagina que tienes un archivo llamado numeros.txt que contiene una línea con el siguiente texto 12345. En ese momento tú lo pasas a Staging con el comando git add numeros.txt. Entonces decides que agregarás otra línea más y creas una segunda línea con lo siguiente 98765. Si ejecutas git status verás que existen dos secciones:
Changes to be committed:
Changes not staged for commit:
Esto es porque aunque es el mismo archivo, los cambios que están listos para pasar al repository es de cuando el archivo contenía 12345, no la siguiente línea (98765). Entonces debes ejecutar de nuevo:
git add numeros.txt
Una vez hecho esto, el archivo con las dos líneas estará listo para ir al repository. Comprueba con git status y verás solamente Changes to be committed:.
Repository
Este es el área donde están los últimos cambios guardados (commited) con éxito en tu repositorio local. Si tienes la última versión, este el último commit debe coincidir con el de tu computadora y con el de tus remotes.
Para colocar tus archivos editados en esta área, tomaremos como ejemplo nuestro archivo numeros.txt y lo llevaremos de Staging a Repository:
git add numeros.txt
git commit -m "Descripcion de mi cambio"
Una vez hecho esto los cambios pasarán al área de Repository.
NOTA: tal vez es claro, pero hay que aclarar que un commit pueden ser uno o cien archivos. No se realiza un commit por cada archivo, sino que van en paquete. Es decir, el commit genera un hash de commit para el paquete de cambios que llevaste a Repository.
Ramas
Una rama en Git (branch) es como una separación del camino que sufre tu proyecto en un momento. Las ramas te van a permitir trabajar independientemente de la rama principal (main) y tendrán su propio historial.
Piensa en ellas como caminar por una calle. Tú caminas por ella y en algún punto puedes ir recto, izquierda o derecha (o atrás también). La calle principal sigue recto, pero tú decides ir por la izquierda. Aquí tienes otras tiendas, casas, perros, etc. Si no te gusta, puedes regresar al punto de inicio y continuar en donde decidiste tomar ese camino y continuar derecho, o puedes integrarte más adelante a la calle principal.
Para crear una rama ejecutamos:
git branch otro-camino
Para cambiar de rama:
git checkout experimento
Para crear y cambiarnos en un solo comando es:
git checkout -b new-feature
Hay más operaciones, pero lo veremos a detalle cuando toque.
Repositorios remotos
Es un repositorio remoto es el nombre que le damos a un repositorio que está alojado en un servidor en línea. Su uso más común es compartir código con otros desarrolladores y colaborar.
Para comenzar, podemos ejecutar:
git remote add origin URL/<NOMBRE-REPOSITORIO>.git
git remote -v
Con git remote -v podemos ver la lista de remotes, porque claro, podemos agregar más de uno.
Una vez que se ha agregado se pueden usar los siguientes comandos (en su forma más básica):
git pull: traemos la última versión del repo que fue publicada.git push: subimos los cambios de nuestro repositorio local al remote.
ACLARACIÓN: cuando tú haces un commit para pasar un archivo de Staging a Repository, no afectas al repositorio ubicado en tus remotes, básicamente porque todo continúa en tu repositorio local. Solamente al hacer git push es cuando tus cambios se sincronizan con el remote, de manera que si hiciste cuatro commits en tu repositorio local y quieres hacer un push, tus cuatro commits se irán tal cual están en la base de datos de .git. No se genera un nuevo hash, porque lo que estás haciendo es solamente poner tus cambios en un remote.
Espero se haya entendido.
Ampliar los conceptos de Git
Puedes ampliar los conceptos básicos de Git con estos enlaces. Aprende y practica mucho.
- https://learngitbranching.js.org/
- https://learn.microsoft.com/es-es/training/github/
- https://resources.github.com/learn/certifications/
Gracias por leer.
