# 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. *Tags: ux, proceso, figma, sistemas, colaboracion* --- > [!info] Definición Rápida > Las **ramas en Figma** son copias de un archivo donde se prueban cambios sin afectar la versión principal que usa el equipo. El **historial de versiones** guarda checkpoints automáticos y nombrados, y permite restaurar un estado anterior sin perder nada. Juntos reemplazan el miedo a «tocar el archivo» por un flujo ordenado. ## ¿Qué son las ramas y el historial? Si todavía no conoces la herramienta a fondo, la [ficha de Figma](/es/wiki/herramientas/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»](https://www.figma.com/blog/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»](https://help.figma.com/hc/en-us/articles/360038006754)). 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: 1. **Crea la rama** desde el archivo principal, con un nombre que diga qué pruebas. 2. **Trabaja en la rama** sin tocar el archivo original. Puedes compartirla para que otra persona la vea. 3. **Actualiza la rama** cuando el principal cambie, para no trabajar sobre algo viejo. 4. **Solicita revisión.** Un revisor aprueba o pide cambios. 5. **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»](https://help.figma.com/hc/en-us/articles/360063144053); [Figma Help, «Merge branch into main file»](https://help.figma.com/hc/en-us/articles/5691189138839/)). ## ¿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»](https://help.figma.com/hc/en-us/articles/5691414603543/)). 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»](https://www.figma.com/blog/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»](https://help.figma.com/hc/en-us/articles/360038006754)). ## 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 [[documentacion-de-diseno|documentación de diseño]] qué cambió y por qué. Si el cambio afecta a componentes que usan otros equipos, coordínalo con [[trabajar-con-desarrolladores|el equipo de desarrollo]] antes de publicarlo. ## Fuentes - [Figma: How (and why) we built branching](https://www.figma.com/blog/how-and-why-we-built-branching/) - [Figma Help: Request a branch review](https://help.figma.com/hc/en-us/articles/5691414603543/) - [Figma Help: Guide to branching](https://help.figma.com/hc/en-us/articles/360063144053) - [Figma Help: Merge branch into main file](https://help.figma.com/hc/en-us/articles/5691189138839/) - [Figma Help: View a file's version history](https://help.figma.com/hc/en-us/articles/360038006754) --- Source: https://www.fernandoux.com/es/wiki/procesos/branching-en-figma/