Git

Cómo trabajar con Git bien de verdad: ramas, commits y pull requests sin hacer un estropicio

26 mar 2026

Git no es una colección de comandos que memorizas para parecer técnico. Git es el sistema que evita que un proyecto serio se convierta en una discusión infinita de “¿quién tocó esto?”, “¿dónde estaba la versión buena?” y “¿por qué hemos roto producción otra vez?”.

Aprender Git bien no consiste en saberse 80 comandos raros. Consiste en entender qué problema resuelve, cómo se trabaja con él en equipo y qué hábitos evitan convertir un repositorio en un cementerio de commits inútiles.

Esta guía va justo de eso.

Git no sirve para “guardar código”: sirve para trabajar con historia

Mucha gente empieza pensando que Git es una especie de carpeta con guardado avanzado. No.

Git sirve para:

llevar un historial real de cambios
poder volver atrás con criterio
trabajar varias personas sin pisarse
probar cosas en ramas separadas
revisar cambios antes de integrarlos
entender cómo ha evolucionado un proyecto

En otras palabras: Git convierte el desarrollo en un proceso trazable.

Sin eso, lo que tienes no es un proyecto. Es una acumulación de archivos con fe.

Lo mínimo que tienes que entender para no ir a ciegas

Git se vuelve mucho más lógico cuando entiendes estas cuatro piezas:

1. Working directory

Es tu carpeta real. Lo que estás editando.

2. Staging area

Es la zona donde decides qué cambios exactos van al siguiente commit.

3. Commit

Es una foto con contexto. No solo guarda cambios: guarda una intención.

4. Branch

Es una línea de trabajo separada del resto.

Cuando entiendes esto, Git deja de parecer magia negra.

El error más común: trabajar directamente en `main`

Si estás solo y es un proyecto minúsculo, puedes salirte con la tuya durante un tiempo.

Pero en cuanto el proyecto importa un poco, trabajar en main como si fuera tu mesa de pruebas es una mala práctica.

main debería representar una versión estable, o al menos razonablemente limpia.

Tu trabajo diario debería ocurrir en ramas.

Cómo se trabaja bien con ramas

La idea de una rama no es “tener muchas”. La idea es aislar cambios.

Una buena rama suele cumplir esto:

resuelve una sola tarea
tiene un alcance claro
vive poco tiempo
se puede revisar con facilidad

Ejemplos buenos:

feat/buscador-glosario
fix/error-en-footer
docs/actualizar-readme

Ejemplos malos:

cambios
nueva-rama
cosas-de-hoy
feature-definitiva-buena-ahora-si

El nombre de la rama no es decoración. Es contexto.

Antes se hacía con `checkout`. Ahora es mejor `switch`

Durante años, cambiar de rama y crear una rama nueva se hacía con git checkout:

git checkout main
git checkout -b feat/mejora-buscador

Sigue funcionando, y lo vas a ver en muchísimos tutoriales y repos antiguos.

Pero hoy, si estás aprendiendo o documentando un flujo nuevo, es mejor usar git switch:

git switch main
git switch -c feat/mejora-buscador

¿Por qué se recomienda `switch` ahora?

Porque git checkout hacía demasiadas cosas distintas:

cambiar de rama
crear rama nueva
moverse a commits antiguos
restaurar archivos

Eso lo volvía más ambiguo y más fácil de usar mal.

Git introdujo dos comandos más claros:

git switch para trabajar con ramas
git restore para recuperar archivos

La idea no es que checkout esté prohibido. La idea es que switch expresa mejor la intención y reduce confusión, especialmente cuando estás empezando.

¿Y cómo vuelven esos cambios a `main`? Con `merge`

Aquí está la pieza que hace que todo tenga sentido: una rama no se crea para vivir sola para siempre. Se crea para trabajar aislado y luego integrar esos cambios en otra rama, normalmente main.

Eso es un merge.

La idea básica es esta:

creas una rama
trabajas ahí
haces commits
cuando está lista, esa rama se mezcla con main

Ejemplo clásico:

git switch main
git pull origin main
git merge feat/mejora-buscador

Eso le dice a Git: “trae a main la historia de esa rama”.

Lo importante en un flujo moderno

En equipos normales, muchas veces no haces ese merge a mano en local. Lo habitual es:

subes tu rama
abres una Pull Request
el merge se hace desde GitHub, GitLab o donde trabaje el equipo

Pero el concepto sigue siendo el mismo: las ramas se integran con merge.

Por qué esto importa

Si no entiendes merge, las ramas parecen carpetas temporales sin destino.

Y no lo son.

Una rama es una línea de trabajo separada cuyo objetivo final es volver a entrar en la rama principal sin romper el proyecto.

Flujo diario razonable con Git

Si trabajas en un repo propio o de equipo, este flujo suele ser suficiente:

git switch main
git pull origin main
git switch -c feat/mejora-buscador

Haces tus cambios, luego:

git status
git add .
git commit -m "feat: añadir filtro por categoría en el buscador"
git push -u origin feat/mejora-buscador

Después abres la Pull Request.

Esto ya cubre el 80% de un trabajo normal.

Lo importante no es hacer commits. Es hacer commits legibles

Un commit no debería decir “guardando avances”.

Eso no explica nada. Un buen commit responde a una pregunta simple:

¿Qué cambia aquí?

Ejemplos buenos:

git commit -m "feat: añadir filtros de búsqueda por categoría"
git commit -m "fix: corregir desbordamiento del menú móvil"
git commit -m "docs: documentar variables de entorno del proyecto"

Ejemplos malos:

git commit -m "cambios"
git commit -m "arreglo"
git commit -m "ahora si"
git commit -m "wip"

Un historial lleno de commits vagos es casi tan inútil como no tener historial.

No mezcles diez cosas distintas en una sola rama

Una rama ideal debería ser revisable sin dolor.

Si en la misma rama:

cambias estilos
arreglas un bug
refactorizas tres componentes
renombraste carpetas
tocas la configuración de build

entonces la PR va a ser incómoda de revisar y más fácil de romper.

Git no te obliga a hacer ramas pequeñas. Pero el equipo futuro te lo va a agradecer.

Cómo funciona una Pull Request de forma sana

La Pull Request no es un trámite. Es el momento donde tu trabajo deja de ser solo tuyo y pasa a entrar en el sistema del equipo.

Una buena PR debería ser:

pequeña o moderada
fácil de leer
con título claro
con contexto suficiente
con cambios centrados en una sola intención

Qué debería incluir

qué problema resuelve
qué has cambiado
si hay riesgos o efectos secundarios
si necesita revisión visual o pruebas manuales

El flujo de Pull Request en repositorios de otros

Este es el flujo open source clásico. Traducido a una forma práctica:

1. Haces fork del repositorio

Copias el proyecto a tu cuenta desde github.

2. Clonas tu fork

git clone https://github.com/tu-usuario/repo.git

3. Creas una rama

git switch -c fix/mejora-documentacion

4. Haces cambios

Pequeños, claros y con una intención concreta.

5. Guardas cambios

git add .
git commit -m "docs: mejorar explicación del flujo de instalación"

6. Subes la rama

git push origin fix/mejora-documentacion

7. Creas la Pull Request

Desde GitHub, comparando tu rama con la rama base del repo original.

8. Esperas revisión

Y si hace falta, corriges cosas.

Ese flujo no es burocracia. Es colaboración ordenada.

Cómo revisar antes de hacer push

Hay un ritual simple que evita muchos disgustos:

git status
git diff
git diff --staged

Antes de subir nada, deberías saber:

qué archivos has tocado
qué líneas han cambiado
si estás incluyendo algo que no querías

Subir cambios sin mirar el diff es como mandar un email importante sin leerlo.

Cuándo hacer `pull`

Haz pull antes de empezar una rama nueva si trabajas sobre main.

git switch main
git pull origin main

Eso evita empezar trabajo nuevo sobre una base vieja.

Lo que no conviene es abrir una rama desde una main desactualizada, pasarte dos horas trabajando y descubrir luego que el repositorio avanzó por otro lado.

Qué hacer si tu rama se queda atrás

Si mientras trabajas otros han mergeado cosas en main, lo normal es traer esos cambios a tu rama antes de abrir o actualizar la PR.

Puedes hacerlo con merge o rebase según el flujo del equipo.

Si no tienes claro cuál usan, no improvises. Sigue la convención del proyecto.

La regla madura aquí no es “yo prefiero X”. Es “el equipo trabaja así”.

Git no arregla malos hábitos, los expone

Si una persona:

no divide tareas
no escribe commits claros
no revisa su diff
mezcla cambios sin relación
abre PRs enormes

Git no va a salvar eso. Solo va a dejar un registro precioso del desastre.

Por eso Git no va solo de comandos. Va de disciplina de trabajo.

Tips que sí valen oro

Haz ramas pequeñas y con propósito único.
Escribe commits como si otra persona fuera a leerlos mañana.
Mira siempre git status antes de commitear.
Mira el diff antes de hacer push.
No uses main como zona de pruebas.
No abras PRs gigantes si puedes evitarlo.
No metas en una PR un refactor accidental “ya que estaba”.
Si el repo tiene convención, respétala aunque no sea tu favorita.
Si no entiendes un comando destructivo, no lo ejecutes.

Una forma simple de pensar Git

Git bien usado significa esto:

separo el trabajo en ramas pequeñas
hago cambios con intención
guardo commits legibles
reviso antes de subir
integro con Pull Request

No hace falta complicarlo más para trabajar bastante bien.

Cierre

Git es importante porque convierte el desarrollo en algo reversible, revisable y colaborativo. No te hace mejor desarrollador por instalarlo, igual que tener un martillo no te convierte en carpintero.

Pero cuando lo usas bien, cambia por completo la forma en que trabajas:

piensas mejor los cambios
reduces el caos
colaboras con menos fricción
entiendes mejor la historia del proyecto

Y eso, en equipos de verdad, vale muchísimo más que saberte de memoria 40 comandos raros.

Si quieres la parte más de referencia rápida, con comandos organizados por tareas, tienes también la Cheat Sheet completa de Git.