Git para UX designers

Me propuse hablar de Git para UX designers porque visto cómo está la industria ya no es un «extra» pensado sólo para los developers. En este contexto en el que diseño, el código y la IA empiezan a mezclarse de verdad… llámalo vibe coding, designer engineer o como quieras, entender lo básico de Git empieza a tener sentido.

Y relax… que no hablo de convertirse en experto ni de manejar flujos complejos. Hablo de entender qué está pasando cuando trabajas con algo que ya no es solo un archivo estático. Versionar, guardar cambios, compartirlos con el equipo, volver atrás si hace falta.

Tener ese mínimo contexto cambia cómo diseñas el producto y cómo te relacionas con el trabajo de otros perfiles.

Git básico

Esto lo vi claro la semana pasada, cuando monté para una compañera un archivo markdown con una guía de comandos básicos de Git.

# clonar un repositorio
# descarga el proyecto en tu ordenador
git clone https://github.com/usuario/repositorio.git

# entrar en la carpeta del proyecto
cd repositorio


# traer los últimos cambios del equipo
# buena práctica antes de empezar a trabajar
git pull


# ver el estado de los archivos
# qué hay cambiado y qué no
git status

# ver el historial de commits
# entender qué se ha hecho antes
git log --oneline


# ver las ramas disponibles
# la rama actual aparece marcada con *
git branch

# crear una rama nueva
# para trabajar sin tocar main
git checkout -b prueba-diseño


# añadir cambios
# prepara los archivos para guardarlos
git add .

# añadir solo un archivo concreto
git add src/components/Button.jsx


# crear un commit
# guarda un punto de control con un mensaje claro
git commit -m "ajustes de diseño en el perfil"


# subir la rama nueva al repositorio remoto
# solo la primera vez
git push -u origin prueba-diseño

# subir cambios habituales de la rama
git push


# cambiar entre ramas
git checkout main
git checkout prueba-diseño

Te lo dije, nada avanzado… clonar un repo, añadir cambios, usar ramas, hacer un commit y subirlos. Lo justo para no ir en pelotas a ciegas y no depender siempre de otra persona para cosas muy básicas.

Cursor y otros IDEs

Pero la cosa no quedó allí… al día siguiente un compañero developer dio un paso más y montó comandos personalizados en Cursor para facilitarnos el trabajo a los product designers.

Acciones habituales, simplificadas, con menos margen de error. No para que sepamos más Git, sino para que podamos trabajar mejor sin fricción innecesaria.

Me pareció buena idea pero no sentí que fuera para mí.

GitHub Desktop

Pero al día siguiente otro developer en mitad de una meet nos sugirió directamente usar GitHub Desktop.

La verdad es que tiene todo el sentido, ves los cambios, sabes qué vas a subir y cuándo, y reduces bastante el miedo a “romper algo”.

Creo que para muchos perfiles de diseño, esto es una puerta de entrada más amable a Git.

Terminal o Consola

Pero ahora te cuento qué hago yo, trabajo con un mix bastante práctico. Uso comandos de Git en consola cuando quiero rapidez o control directo. Y uso GitHub Desktop cuando prefiero revisar cambios con calma o trabajar más visual.

En mi caso, hay además un motivo personal por el que la consola no me resulta extraña. Me gusta usar terminal porque me conecta con los inicios de mi carrera, cuando escribía directamente en la pantalla de fósforo verde de mi primer Apple II. No había capas ni interfaces sofisticadas, sólo había texto, comandos y respuesta inmediata.

Usar hoy la consola, aunque sea para cosas sencillas, me resulta natural.

Resumiendo…

Aprender lo básico de Git o GitHub ya no va de querer programar. Va de entender mejor el entorno en el que estás diseñando productos, colaborar mejor con developers y moverte con menos fricción en equipos donde diseño y código ya no van separados.