Git para diseñadores: el control de versiones sin jerga
Git guarda el historial de cambios de un proyecto y permite volver atrás. Commit, diff y rama explicados sin jerga para diseñadores que trabajan con IA.
¿Qué problema resuelve?
Un proyecto cambia muchas veces al día. Sin registro, cuando algo se rompe no sabes cuándo empezó ni qué lo causó. Con Git, cada cambio importante queda guardado con una fecha, un autor y una descripción. Según el libro oficial de Git, el control de versiones sirve justamente para recuperar versiones específicas, comparar cambios a lo largo del tiempo y ver quién modificó algo que causa un problema (Pro Git, Acerca del control de versiones).
Un detalle que conviene saber: cada copia del repositorio tiene el historial completo. Eso significa que, mientras tu copia exista, tu trabajo no se pierde si la nube falla.
¿Qué son un commit, un diff y una rama?
| Concepto | Qué es | Ejemplo cotidiano |
|---|---|---|
| Commit | Un punto guardado con descripción | “Agrega el estado vacío del buscador” |
| Diff | La diferencia entre dos versiones | Líneas en verde (agregadas) y rojo (quitadas) |
| Rama | Una línea de trabajo separada | Probar un rediseño sin tocar la versión principal |
Un commit es como una foto con nota al pie. El diff es la comparación entre dos fotos. Una rama es una línea de trabajo paralela que puedes descartar o integrar a la versión principal cuando estés conforme.
¿Por qué le importa a quien trabaja con IA?
Porque una IA puede cambiar muchos archivos en un solo paso. Si no hay commits, revertir un cambio es adivinar qué tocó. Antes de cada sesión importante, guarda un commit; después de cada cambio que funcione, guarda otro. Así, si el siguiente cambio rompe algo, vuelves al último punto que sí funcionaba.
Los puntos de restauración de algunas herramientas ayudan, pero no sustituyen a Git. La documentación de Claude Code, por ejemplo, aclara que sus checkpoints solo siguen las ediciones hechas con sus herramientas de edición de archivos: los cambios por comandos de terminal o por otras sesiones no se registran.
¿Qué comandos necesitas?
No necesitas memorizar muchos. Estos cubren el uso básico del día a día:
git status: qué archivos cambiaron desde el último commit.git diff: qué exactamente cambió.git addygit commit: guardar un punto con descripción.git log: ver el historial.git restore <archivo>: descartar los cambios sin guardar de un archivo y devolverlo a su último commit. Ojo: lo descartado así no se puede recuperar.git revert <commit>: crear un commit nuevo que deshace otro anterior, sin borrar el historial.
Una herramienta de IA suele ejecutar estos comandos por ti. Tu trabajo es revisar el resultado: lee el diff antes de aceptar. Esa lectura es la misma que describe leer código sin saber programar, y las ramas para cambios grandes se explican en ramas y pull requests.
Ejemplo
Ejemplo ilustrativo: un diseñador tiene un formulario de contacto que funciona. Antes de pedirle a la IA que cambie el diseño, hace un commit: “Formulario de contacto funcionando”. La IA rediseña el formulario y cambia también el archivo de validación. Al revisar el diff, el diseñador ve el cambio en la validación, que no pidió. Revierte solo ese archivo al estado del commit anterior, pide que el rediseño no toque la validación y guarda un nuevo commit. Sin el punto guardado, habría tenido que reconstruir la validación a mano.
¿Cómo empezar mañana?
- Inicializa el control de versiones en tu proyecto de diseño o de prototipo (
git init) y guarda un primer punto con el estado actual, con un mensaje que diga qué funciona. - Antes de cada sesión con IA, revisa si hay cambios sin guardar. Si los hay, decide si los guardas o los descartas antes de empezar.
- Después de cada cambio que funcione, guarda un punto con una descripción en una frase: qué se agregó o qué se corrigió.
- Cuando la IA termine, abre el diff y revisa al menos los nombres de los archivos. Si aparece uno que no esperabas, pregunta por qué antes de guardar.
Con estos cuatro hábitos, un error se convierte en un retroceso de un punto y no en una semana perdida.
Un hábito que ahorra conflictos: al empezar cada día, revisa el estado del proyecto antes de pedir cambios, y al terminar, guarda un punto aunque el trabajo esté incompleto, con «en curso» en el mensaje. Así mañana sabes dónde quedaste sin depender de la memoria de la conversación anterior. Si te preguntas qué cambió en un archivo que nadie tocó, el historial responde, incluso cuando la herramienta ya no lo recuerda. Los comandos de esta sección se ejecutan desde la terminal, y la forma de compartir esos cambios con otros está en ramas y pull requests.
Errores comunes
- Trabajar semanas sin guardar puntos de historial.
- Escribir mensajes de commit como “cambios” o “fix”, que no dicen nada dentro de un mes.
- Aceptar cambios de la IA sin mirar el diff.
- Creer que la nube guarda todo lo que Git guarda.
- Editar archivos a mano en medio de una sesión de IA sin avisar a la herramienta.
- Confiar en que el historial de la IA reemplaza al historial del proyecto.
Fuentes
- Scott Chacon y Ben Straub, “Pro Git”, capítulo 1.1, “Acerca del control de versiones”: https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
- Anthropic, “Checkpointing” en la documentación de Claude Code (qué registran los puntos de restauración y qué no): https://code.claude.com/docs/en/checkpointing
- Git, documentación de
git restore: https://git-scm.com/docs/git-restore - GitHub Docs, “About pull requests” (cómo se revisa un cambio antes de integrarlo): https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests