Fundamentos de Git: repositorio, commit y cómo rastrea los cambios

Introducción

Si estás empezando a programar o a trabajar con cualquier tipo de archivo que vaya a cambiar con el tiempo, seguramente ya escuchaste hablar de Git. Es el sistema de control de versiones más usado hoy en día y comprender sus conceptos básicos es esencial para trabajar de forma ordenada, colaborar con otros y poder volver atrás cuando algo sale mal.

En este artículo vas a aprender:

• Qué es un repositorio Git y por qué es el corazón del sistema.
• Qué significa hacer un commit y qué información guarda.
• Cómo Git detecta y registra los cambios en tus archivos sin necesidad de copiar todo el proyecto cada vez.
• Veremos los comandos más importantes como git init, git status, git add, git commit, git log y git diff, con ejemplos reales y su salida esperada.

El contenido está pensado para personas que ya tienen nociones básicas de línea de comandos pero que nunca han usado Git, o para quienes lo usan de forma superficial y quieren entender qué ocurre detrás de cada operación.

Qué es un repositorio Git

Un repositorio (en inglés repository) es simplemente un directorio donde Git lleva el control de todas las versiones de los archivos que contiene. No es una base de datos externa ni un servicio en la nube; es un subdirectorio oculto llamado .git que se crea dentro de tu proyecto y que guarda toda la información necesaria para reconstruir cualquier estado anterior.

Cuando decimos que un directorio es un repositorio Git, queremos decir que dentro de él existe esa carpeta .git con:

• Objetos (blobs, trees, commits) que almacenan el contenido de los archivos y sus relaciones.
• Referencias (branches, tags) que apuntan a commits específicos.
• El índice o stage area, un archivo temporal donde prepares los cambios que serán incluidos en el próximo commit.
• Un archivo de configuración y otros logs internos.

Todo esto significa que, una vez que tenés un repositorio, Git conoce el estado exacto de cada archivo en cada momento que vos le indicaste. No necesita guardar copias completas del proyecto cada vez; en cambio, almacena solo las diferencias (o deltas) y los objetos de forma eficiente.

Creando tu primer repositorio con git init

El primer paso para poner un proyecto bajo control de versiones es ejecutar git init. Este comando crea la carpeta .git y deja el repositorio listo para comenzar a registrar cambios.

Veamos qué ocurre cuando lo ejecutamos en un directorio vacío. Para que el ejemplo sea autónomo y muestre la salida real, usaremos un bloque de código ejecutable en Bash:

cd /tmp && rm -rf git-demo && mkdir git-demo && cd git-demo && git init

La salida esperada es algo parecido a:

Initialized empty Git repository in /tmp/git-demo/.git/

Esto nos confirma que se ha creado un repositorio vacío. En este punto, el directorio git-demo contiene únicamente la carpeta .git (oculta) y ningún otro archivo.

Ver el estado con git status

Antes de agregar cualquier archivo, es buena costumbre consultar el estado del repositorio con git status. Este comando te dice en qué rama estás, si hay cambios sin seguir, archivos nuevos, modificados o listos para ser commitados.

Ejecutemos git status justo después de haber inicializado el repositorio:

cd /tmp/git-demo && git status

La salida será:

On branch master
No commits yet
nothing to commit (create/copy files and use 'git add' to track)

Interpretemos cada línea:

• On branch master: estás en la rama principal (por defecto se llama master o, en versiones más recientes, main).
• No commits yet: aún no se ha hecho ningún commit, entonces el historial está vacío.
• nothing to commit ...: no hay archivos preparados para ser incluidos en el próximo commit.

Cómo Git rastrea los cambios

Para entender qué hace Git cuando le decís que siga un archivo, es útil conocer sus tres áreas de trabajo:

1. Árbol de trabajo (working tree): son los archivos que ves y editás en tu disco.
2. Índice (index o stage area): es un área intermedia donde marcás los cambios que querés incluir en el próximo commit.
3. Historial (repository): la base de datos de objetos donde se guardan los commits permanentes.

Cuando modificás un archivo, Git lo detecta comparando su contenido actual con la versión que tiene guardada en el índice (o, si nunca fue agregado, con la ausencia de registro). Esa comparación se hace mediante un algoritmo de hash (SHA‑1) que genera una huella única para cada versión del archivo. Si la huella cambió, el archivo está "modificado" o "sin seguir" según corresponda.

El flujo típico es:

• Modificás uno o más archivos en el árbol de trabajo.
• Agregás esos cambios al índice con git add. En este paso Git toma una instantánea (snapshot) del contenido y la guarda como un objeto blob en su base de datos, luego actualiza el índice para que apunte a ese blob.
• Committeás los cambios con git commit. El commit crea un nuevo objeto commit que apunta al árbol (tree) representado por el índice, guarda metadatos como autor, fecha y mensaje, y actualiza la rama actual para que apunte a ese nuevo commit.

Gracias a este diseño, Git no necesita guardar copias completas de cada versión; solo almacena los blobs que realmente cambiaron y reutiliza los existentes mediante su sistema de direccionamiento por contenido.

Preparando un archivo para el primer commit

Ahora que ya sabemos cómo funciona el seguimiento, vamos a agregar un archivo al repositorio y ver cómo cambian los estados.

Primero creamos un archivo de texto sencillo:

cd /tmp/git-demo && echo "Hola mundo" > hola.txt

Luego consultamos el estado:

cd /tmp/git-demo && git status

La salida esperada es:

On branch master
No commits yet
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        hola.txt

nothing added to commit but untracked files present (use "git add" to track)

Git nos dice que hola.txt está sin seguir (untracked): lo ve en el árbol de trabajo pero aún no está en el índice. Para que lo empiece a seguir tenemos que añadirlo al stage.

Agregando cambios con git add

Ejecutamos git add sobre el archivo:

cd /tmp/git-demo && git add hola.txt

Y volvemos a mirar el estado:

cd /tmp/git-demo && git status

Ahora la salida cambia a:

On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   hola.txt

El archivo pasó a estar en la sección Changes to be committed, lo que significa que su contenido ya está guardado como un blob en la base de datos de Git y el índice apunta a él. En este punto, si hacemos un commit, ese archivo será incluido exactamente tal como está ahora.

Creando el primer commit con git commit

Un commit es una instantánea segura del estado del índice en un momento dado, además de metadatos que permiten identificar quién lo hizo, cuándo y por qué. Cada commit tiene un mensaje descriptivo que vos proporcionás.

Ejecutemos el primer commit:

cd /tmp/git-demo && git commit -m "Primer commit: agrega hola.txt"

La salida será algo como:

[master (root-commit) a1b2c3d] Primer commit: agrega hola.txt
 1 file changed, 1 insertion(+)
 create mode 100644 hola.txt

Vamos a desglosar la información:

• [master (root-commit) a1b2c3d]: indica que se actualizó la rama master, que este es el primer commit (root-commit) y que su identificador SHA‑1 comienza con a1b2c3d.
• 1 file changed, 1 insertion(+): un archivo se modificó (en este caso se creó) y se agregó una línea.
• create mode 100644 hola.txt: el archivo se agregó con permisos normales de archivo regular.

Ahora el historial tiene un commit y el árbol de trabajo está limpio.

Viendo el historial con git log

Para inspeccionar los commits existentes usamos git log. Este comando muestra una lista de commits, desde el más reciente hacia atrás.

Ejecutemos:

cd /tmp/git-demo && git log

La salida típica (con el formato predeterminado) es:

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
Author: Tu Nombre <tu@email.com>
Date:   Thu Sep 26 10:00:00 2025 -0300

    Primer commit: agrega hola.txt

Si preferimos una vista más compacta, podemos usar la opción --oneline:

cd /tmp/git-demo && git log --oneline

Salida:

a1b2c3d Primer commit: agrega hola.txt

Cada línea muestra el hash abreviado y el mensaje del commit. Este historial nos permite volver a cualquier estado anterior simplemente referenciando su hash.

Haciendo cambios y viendo la diferencia con git diff

Supongamos que ahora queremos modificar el archivo hola.txt agregándole una línea. Después de hacer el cambio, queremos ver exactamente qué se modificó antes de preparar el próximo commit.

Primero editamos el archivo:

cd /tmp/git-demo && echo "Linea agregada" >> hola.txt

Luego revisamos el estado:

cd /tmp/git-demo && git status

Salida:

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   hola.txt

no changes added to commit (use "git add" and/or "git commit -a

Git nos indica que hola.txt está modificado pero no staged (no está en el índice). Para ver exactamente qué cambió, usamos git diff:

cd /tmp/git-demo && git diff

La salida será:

diff --git a/hola.txt b/hola.txt
index e69de29..23fd9fa 100644
--- a/hola.txt
+++ b/hola.txt
@@
 Hola mundo
+Linea agregada

Esta salida nos muestra:

• Las rutas del archivo (a/hola.txt es la versión antigua, b/hola.txt la nueva).
• Los hashes de los blobs antes y después (e69de29 es el hash de un archivo vacío, 23fd9fa corresponde al contenido con las dos líneas).
• Las líneas precedidas por - son las que se removieron (ninguna en este caso) y las que llevan + son las agregadas.

Con esta información podés decidir si el cambio está correcto antes de pasarlo al índice.

Completando el segundo commit

Agregamos el cambio al índice y lo committeamos:

cd /tmp/git-demo && git add hola.txt

Verificamos el estado:

cd /tmp/git-demo && git status

Salida:

On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   hola.txt

Ahora hacemos el commit:

cd /tmp/git-demo && git commit -m "Segundo commit: agrega segunda linea"

Salida esperada:

[master 3f4g5h6] Segundo commit: agrega segunda linea
 1 file changed, 1 insertion(+)

Y si miramos el historial con git log --oneline obtenemos:

3f4g5h6 Segundo commit: agrega segunda linea
a1b2c3d Primer commit: agrega hola.txt

El historial muestra dos commits, cada uno con su mensaje y su hash.

El flujo típico de trabajo con Git

Resumiendo, el flujo que usarás la mayor parte del tiempo es:

1. Modificar uno o más archivos en tu árbol de trabajo.
2. Ejecutar git status para ver qué cambió.
3. Revisar las diferencias con git diff si necesitás confirmar los detalles.
4. Agregar los cambios al índice con git add <archivo> (o git add . para todo).
5. Confirmar que el índice contiene exactamente lo que querés committear con otro git status.
6. Crear el commit con git commit -m "Tu mensaje descriptivo".
7. Repetir el proceso según necesites.

Este ciclo garantiza que cada commit represente una unidad lógica de trabajo, lo que facilita revertir cambios, revisar historial y colaborar con otros.

Buenas prácticas y errores comunes

Buenas prácticas

• Escribir mensajes de commit claros y concisos: explicar el qué y el por qué, no el cómo (el código ya muestra el cómo).
• Committear frecuentemente: mejor muchos commits pequeños que pocos grandes; así es más fácil aislar problemas.
• Usar ramas para desarrollar nuevas funcionalidades o corregir errores sin afectar la línea principal (git checkout -b nueva-feature).
• Ignorar archivos innecesarios mediante un archivo .gitignore (por ejemplo, directorios de compilación, logs, dependencias).
• Antes de hacer un push (si usás un remoto), revisar con git diff --staged o git diff HEAD para asegurarte de que no haya sorpresas.

Errores comunes

• Olvidar hacer git add antes de git commit: el commit quedará vacío o sin los cambios que esperabas.
• Committear archivos binarios grandes sin necesidad: aumenta innecesariamente el tamaño del repositorio; usar LFS o excluir esos archivos.
• Trabajar directamente en la rama principal en equipos grandes: puede generar conflictos y dificultar la integración.
• No revisar el estado antes de committear: podés incluir accidentalmente archivos temporales o de depuración.
• Sobrescribir historial público con git reset --force o git push --force: puede borrar trabajo de otros colaboradores.

Conclusión

Git es una herramienta poderosa cuya magia radica en su capacidad de rastrear cambios de forma eficiente mediante un modelo basado en blobs, trees y commits, gestionados por un índice intermedio. Un repositorio no es más que una carpeta con un subdirectorio .git que guarda toda la información necesaria para reconstruir cualquier versión del proyecto.

Hacer un commit significa tomar una instantánea del índice, almacenarla como un objeto commit con metadatos (autor, fecha, mensaje) y actualizar la rama actual para que apunte a ella. Gracias a este diseño, cada commit es seguro, inmutable y referencia únicamente los objetos que realmente cambiaron, evitando duplicaciones innecesarias.

A lo largo del artículo vimos, con ejemplos ejecutables, cómo:

• Inicializar un repositorio con git init.
• Ver el estado con git status.
• Seguir archivos nuevos con git add.
• Crear commits significativos con git commit -m.
• Consultar el historial con git log.
• Inspeccionar diferencias exactas con git diff.

Con estos conceptos básicos ya podés comenzar a usar Git de forma productiva en tus proyectos personales o en equipos de trabajo. Te recomendamos seguir practicando los comandos en un entorno seguro (como el .gitignore bien configurado) y, cuando te sientas cómodo, explorar temas avanzados como ramas, fusión (merge), rebase (rebase) y trabajo con repositorios remotos (push, pull, fetch).

¡Manos al código y que el versionado nunca sea un dolor de cabeza!