Qué es Git y cómo empezar a usarlo desde cero

Si has oído hablar de Git pero nunca has entendido bien para qué sirve o te has perdido con los comandos, esta guía es para ti. Vamos a empezar desde el principio: qué problema resuelve Git, cómo funciona y qué hace cada comando que vas a usar en el día a día.

El problema que resuelve Git

Imagina que estás escribiendo código para un proyecto. Funciona bien, así que decides hacer cambios para añadir una nueva funcionalidad. A mitad del camino algo se rompe y no sabes cómo volver al estado anterior. O peor: trabajas con otra persona en el mismo proyecto y los dos modificáis el mismo fichero a la vez. ¿Cómo juntáis los cambios sin pisaros?

Ese es exactamente el problema que resuelve Git: es un sistema de control de versiones que guarda el historial completo de cambios de tu proyecto. Puedes volver a cualquier punto anterior, ver qué cambió y cuándo, y trabajar en equipo sin que nadie se pise el trabajo de los demás.

Instalación

En Ubuntu:

sudo apt update
sudo apt install -y git

Verifica que está instalado:

git --version

Configuración inicial

Antes de nada, dile a Git quién eres. Usará este nombre y email para identificar tus cambios:

git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"

Esto solo hace falta hacerlo una vez.

Cómo piensa Git

Antes de ver los comandos, hay un concepto que lo cambia todo: Git no guarda "los cambios que hiciste" — guarda fotografías completas de tu proyecto en momentos concretos. Cada vez que haces un commit (ya veremos qué es), Git hace una foto de todos tus ficheros en ese instante y la guarda.

Eso significa que puedes viajar en el tiempo: volver a cualquier foto anterior, comparar dos fotos, o trabajar en varias líneas de tiempo en paralelo (las ramas).

Las tres zonas

Git tiene tres zonas que es importante distinguir:

┌─────────────────┐    git add    ┌─────────────┐   git commit  ┌──────────────┐
│  Tu carpeta     │ ──────────►  │   Staging   │ ────────────► │  Historial   │
│  (tus ficheros) │              │  (zona de   │               │  (commits)   │
│                 │              │  preparación│               │              │
└─────────────────┘              └─────────────┘               └──────────────┘

Tu carpeta es donde trabajas normalmente, editas ficheros, escribes código.

Staging es una zona intermedia donde preparas qué va a incluir la próxima foto. Puedes elegir qué ficheros incluir y cuáles no.

Historial es donde se guardan las fotos (commits) de forma permanente.

El flujo siempre es el mismo: editas ficheros → los preparas con git add → los guardas con git commit.

Crear tu primer repositorio

Un repositorio es simplemente una carpeta que Git controla. Para convertir una carpeta en repositorio:

mkdir mi-proyecto
cd mi-proyecto
git init

Git crea una carpeta oculta .git dentro de tu proyecto. Ahí guarda todo el historial. No la toques.

Los comandos básicos explicados uno a uno

git status — ¿qué está pasando?

Es el comando que más usarás. Te dice en qué estado están tus ficheros:

git status

Te muestra:

• Ficheros modificados que aún no has preparado para el commit
• Ficheros preparados en staging listos para el commit
• Ficheros nuevos que Git no está rastreando todavía

Úsalo constantemente. Antes y después de cada comando, hasta que entiendas bien qué está ocurriendo.

git add — preparar cambios

Mueve los cambios de tu carpeta al staging. No guarda nada todavía — solo prepara qué va a entrar en la próxima foto.

git add fichero.txt          # Preparar un fichero concreto
git add carpeta/             # Preparar toda una carpeta
git add .                    # Preparar todos los cambios

Si ejecutas git status después de git add, verás los ficheros en verde — están en staging, listos para el commit.

git commit — guardar la foto

Guarda permanentemente los cambios que están en staging. Cada commit necesita un mensaje que describa qué cambió:

git commit -m "Añadir página de inicio"

El mensaje es importante: debe explicar qué hace ese cambio, no cómo lo hace. En el futuro te lo agradecerás cuando busques en el historial.

Después de un commit, el staging queda vacío y los cambios están guardados en el historial.

git log — ver el historial

Muestra todos los commits que has hecho:

git log

Cada commit tiene un identificador único (hash), el autor, la fecha y el mensaje. Si el historial es largo, sal con la tecla q.

Para una versión más compacta:

git log --oneline

git diff — ver qué ha cambiado

Muestra exactamente qué líneas han cambiado en tus ficheros:

git diff                     # Cambios en tu carpeta que no están en staging
git diff --staged            # Cambios que están en staging

Las líneas en verde con + son añadidas. Las rojas con - son eliminadas.

Deshacer cosas

Uno de los mayores miedos cuando se empieza con Git es hacer algo mal sin poder deshacerlo. La realidad es que Git está diseñado para que casi todo tenga vuelta atrás.

Descartar cambios en un fichero

Si has modificado un fichero y quieres volver a como estaba en el último commit:

git restore fichero.txt

Cuidado: este comando descarta los cambios sin posibilidad de recuperarlos.

Sacar un fichero del staging

Si has hecho git add por error y quieres sacarlo del staging (sin borrar los cambios):

git restore --staged fichero.txt

Modificar el último commit

Si te has olvidado de añadir algo al último commit o el mensaje tiene una errata:

git add fichero-olvidado.txt
git commit --amend -m "Mensaje corregido"

Solo funciona bien si el commit aún no lo has subido a ningún servidor remoto.

Ramas: trabajar en paralelo

Una rama es una línea de trabajo independiente. Por defecto trabajas en la rama main. Cuando quieres añadir una nueva funcionalidad sin tocar lo que ya funciona, creas una rama nueva:

main:     A ── B ── C
                     \
nueva-rama:           D ── E

Los commits D y E están en la rama nueva y no afectan a main hasta que decidas fusionarlos.

Crear y cambiar de rama

git branch                           # Ver todas las ramas (* indica la actual)
git checkout -b nombre-de-la-rama    # Crear una rama y cambiar a ella
git checkout main                    # Volver a main

Fusionar ramas

Cuando terminas el trabajo en una rama y quieres incorporarlo a main:

git checkout main
git merge nombre-de-la-rama

Git fusiona los cambios automáticamente. Si dos ramas han modificado la misma línea del mismo fichero, aparece un conflicto que tendrás que resolver a mano — Git marca el fichero con indicadores para que veas exactamente dónde está la discrepancia.

Conectar con GitHub

Hasta aquí todo es local — el historial está solo en tu máquina. GitHub es un servidor donde puedes subir tu repositorio para tenerlo en la nube, compartirlo o trabajar en equipo.

Subir tu repositorio a GitHub

1. Crea un repositorio nuevo en github.com (sin inicializarlo)
2. Conecta tu repositorio local con el remoto:

git remote add origin https://github.com/tuusuario/tu-repo.git
git push -u origin main

origin es el nombre que le damos al remoto (es el estándar, podrías llamarlo de otra forma). El -u establece la conexión por defecto para futuros pushes.

Los tres comandos del trabajo con remoto

git push    # Subir tus commits locales a GitHub
git pull    # Bajar los cambios de GitHub e incorporarlos a tu rama
git clone https://github.com/usuario/repo.git    # Descargar un repositorio completo

El fichero .gitignore

Hay ficheros que no quieres que Git rastree nunca: contraseñas, claves de API, carpetas de dependencias, ficheros temporales. Para eso existe el .gitignore: un fichero en la raíz de tu proyecto donde listas qué ignorar.

nano .gitignore

Ejemplo básico:

# Variables de entorno con contraseñas o claves (nunca subas esto)
.env

# Dependencias de Node.js
node_modules/

# Ficheros del sistema operativo
.DS_Store
Thumbs.db

# Logs
*.log

Git ignorará completamente cualquier fichero o carpeta que aparezca aquí.

Regla importante: nunca subas un fichero .env con contraseñas o claves de API a GitHub, especialmente en repositorios públicos. Una vez subido, aunque lo borres después, queda en el historial.

El flujo de trabajo del día a día

Resumiendo todo lo anterior, así es como se trabaja con Git en el día a día:

# 1. Ver en qué estado está todo
git status

# 2. Hacer cambios en tus ficheros...

# 3. Preparar los cambios
git add .

# 4. Guardar la foto con un mensaje claro
git commit -m "Descripción de qué has hecho"

# 5. Subir a GitHub
git push

Y cuando trabajas en equipo o desde otra máquina:

# Bajar los últimos cambios antes de empezar a trabajar
git pull

Referencia rápida de comandos

Conclusión

Git deja de dar miedo en cuanto entiendes que todo gira alrededor de tres pasos: modificar ficheros, prepararlos con git add y guardarlos con git commit. El resto — ramas, remotos, historial — son herramientas construidas sobre esa base.

La mejor forma de afianzarlo es usarlo en un proyecto real, aunque sea pequeño. Con el tiempo los comandos se vuelven automáticos y empiezas a entender cuándo y por qué usarlos, no solo cómo.

Te dejo el vídeo con un resumen visual: