Branches y versiones en Figma: cómo probar cambios sin romper el archivo principal
Las ramas de Figma permiten experimentar en una copia del archivo y fusionarla después, y el historial de versiones deja restaurar. Planes, flujo y límites.
¿Qué son las ramas y el historial?
Si todavía no conoces la herramienta a fondo, la ficha de Figma de esta wiki resume lo básico. Una rama es una copia de trabajo del archivo principal. Cuando la creas, puedes cambiar componentes, reorganizar pantallas o probar una arquitectura nueva sin que el equipo vea el cambio. El archivo principal sigue siendo la fuente única de verdad, y las ramas funcionan como espacios para explorar.
Figma presenta las ramas como espacios exploratorios que permiten probar ideas nuevas sin cambiar el archivo principal (Figma, «How (and why) we built branching»). El historial de versiones, por su parte, es el registro del archivo en el tiempo: Figma crea un checkpoint automático cada 30 minutos y permite nombrar versiones y añadirles una descripción (Figma Help, «View a file’s version history»). En los planes Starter y de borradores, el historial llega hasta 30 días atrás.
¿Por qué le importa a un diseñador?
Porque un archivo de diseño compartido es frágil. Alguien mueve un componente de librería y rompe la pantalla de otro equipo. Alguien experimenta en el archivo principal y no sabe cómo volver atrás. Las ramas y el historial separan el experimento de la versión estable y dan un camino de vuelta.
También ordenan la revisión. Una rama revisada por otra persona, con cambios visibles y una fusión registrada, es más fácil de defender que una serie de ediciones directas que nadie recuerda.
¿Cómo es el flujo?
Un flujo práctico, según la guía de ramificación de Figma:
- Crea la rama desde el archivo principal, con un nombre que diga qué pruebas.
- Trabaja en la rama sin tocar el archivo original. Puedes compartirla para que otra persona la vea.
- Actualiza la rama cuando el principal cambie, para no trabajar sobre algo viejo.
- Solicita revisión. Un revisor aprueba o pide cambios.
- Fusiona. Quien tenga acceso de edición al archivo principal hace la fusión.
Figma crea checkpoints en el historial cuando se crea una rama y cuando se fusiona, y añade uno extra justo antes de fusionar, así que puedes revisar la actividad después. Si una fusión sale mal, se puede deshacer restaurando una versión anterior de la rama o del archivo principal (Figma Help, «Guide to branching»; Figma Help, «Merge branch into main file»).
¿Qué planes y límites tiene?
La ayuda oficial de Figma indica que la función está disponible en los planes Organization, Enterprise, Government y de educación K-12. Para crear una rama se necesita un asiento completo (Full seat) y acceso de vista o edición al archivo principal. Para solicitar revisión hace falta acceso de edición a la rama y de vista al principal (Figma Help, «Request a branch review»). Los planes cambian: si tu equipo depende de esta función, confirma la disponibilidad en la ayuda de Figma antes de planificar.
Limitaciones que conviene conocer:
- Actualizar desde el principal no es selectivo. Según la ayuda de Figma, no puedes elegir qué cambios aplicar. Lo que entra, entra completo.
- No se puede ramificar desde una rama. Figma lo dejó fuera a propósito para mantener la función simple (Figma, «How (and why) we built branching»).
- Los límites de memoria bloquean la revisión. Si el archivo tiene un aviso de límite de memoria activo, no puedes revisar ni fusionar hasta reducir el uso.
- Quien no tiene edición no puede fusionar. Debe pedir la fusión a alguien que sí la tenga.
¿Qué pasa al restaurar una versión?
Restaurar una versión anterior no borra nada. Figma añade dos checkpoints: uno con el estado actual, antes de restaurar, y otro con la versión restaurada. Los comentarios de todas las versiones se mantienen, aunque los que ya estaban eliminados no vuelven. Esto permite experimentar en el historial: si restauras y no te gusta, puedes volver al estado previo. Lo que no se puede hacer es borrar checkpoints; sí puedes quitar el nombre y la descripción de una versión, y eso no se deshace. Para crear, nombrar, borrar o restaurar versiones hace falta acceso de edición al archivo (Figma Help, «View a file’s version history»).
Ejemplo
Ejemplo ilustrativo: un equipo quiere rediseñar la navegación de su producto, que usa 40 componentes de la librería. En lugar de tocar el archivo principal, crea una rama llamada «nav-v2». Trabaja allí durante tres días, actualiza la rama dos veces cuando cambia la librería y pide revisión a la responsable de diseño de sistemas. La revisión marca tres componentes que rompen la accesibilidad del foco. Se corrigen en la rama, se fusionan y el historial muestra los checkpoints de creación y fusión. Si el lanzamiento sale mal, el equipo puede restaurar la versión anterior sin perder el rediseño.
¿Cuándo NO conviene usar ramas?
- Para cambios pequeños de texto. Una rama para cambiar una etiqueta es burocracia. Edita directamente y deja registro con una versión nombrada.
- Si nadie va a revisar. Una rama sin revisión es una copia más. Define quién aprueba antes de crearla.
- Cuando el archivo está saturado. Si el archivo tiene límite de memoria, primero reduce su tamaño.
- Como sustituto de comunicación. Una rama no reemplaza una conversación con quien mantiene la librería.
Errores comunes
- Crear ramas y no actualizarlas, así que se fusionan cambios sobre una base vieja.
- Fusionar sin revisión.
- Usar nombres genéricos como «prueba 2».
- Trabajar en el archivo principal mientras hay una rama abierta sobre los mismos componentes.
- No nombrar versiones importantes, como la entrega a desarrollo.
Cómo empezar mañana
Elige un cambio pendiente en la librería de tu equipo. Crea una rama con un nombre que diga qué cambia, y dedica una sesión a trabajar en ella. Pide revisión a una persona de tu equipo de diseño de sistemas. Antes de fusionar, guarda una versión nombrada del archivo principal. Después de la fusión, anota en la documentación de diseño qué cambió y por qué. Si el cambio afecta a componentes que usan otros equipos, coordínalo con el equipo de desarrollo antes de publicarlo.