Control de Versiones para Proyectos en Equipo
Para proyectos colaborativos, el Control de Versiones permite un desarrollo verdaderamente en paralelo entre equipos.
Cada colaborador trabaja en su propia rama de usuario, lo que permite que varias personas editen el mismo proyecto al mismo tiempo, sin sobrescribir el trabajo de otros ni bloquear el progreso.
Cada cambio permanece aislado, rastreable y reversible, mientras que la colaboración se mantiene rápida, flexible y segura.
Creación de tu Rama de Usuario en un Proyecto de Equipo
Tu rama de usuario personal se crea automáticamente la primera vez que interactúas con un proyecto de equipo — no se requiere configuración manual.
Una rama de usuario se crea cuando:
- Abres un proyecto de equipo existente
- Realizas cualquier cambio y guardas, o
- Publicas el proyecto en tu entorno de Development
Una vez que tu rama de usuario existe:
- Todos los guardados futuros se registran en tu historial personal
- Puedes hacer checkout, revisar y fusionar el trabajo de otros colaboradores
- Otros usuarios pueden revisar y fusionar tus cambios, según su nivel de permisos
Este flujo de trabajo permite que los equipos avancen rápido, manteniendo el trabajo de cada colaborador independiente, revisable y seguro.
Funcionalidades de Colaboración
El Control de Versiones ofrece un conjunto completo de herramientas diseñadas específicamente para flujos de trabajo en equipo:
- Ver el historial de commits de otros colaboradores para revisión o pruebas
- Hacer checkout de checkpoints de colaboradores para inspeccionar o validar cambios
- Fusionar cambios aprobados en tu propia rama
- Revisar comentarios y señales de estado (Ready) antes de fusionar
- Registros automáticos de fusiones para trazabilidad y responsabilidad total
XR Creator Studio gestiona automáticamente la integridad de las versiones — no se requiere ramificación manual, bloqueo de archivos ni resolución de conflictos.
Visualizar los Commits de un Colaborador
Puedes explorar el trabajo de otro colaborador —incluyendo borradores, checkpoints listos para revisión, comentarios y cambios— sin afectar tu propia rama.
Esto facilita:
- Probar funcionalidades
- Validar lógica
- Revisar avances
- Dar feedback antes de fusionar
Para ver el trabajo de un colaborador:
- Selecciona al colaborador en el panel de Control de Versiones
- Haz clic en cualquiera de sus checkpoints para inspeccionar los cambios
Hacer Checkout de un Checkpoint de un Colaborador
Hacer checkout de un checkpoint restaura el editor para que coincida exactamente con ese estado guardado.
Para hacerlo:
- Abre el menú de acciones (⋮) del checkpoint deseado
- Haz clic en Checkout

Esta acción:
- Actualiza instantáneamente el editor al estado seleccionado
- No elimina checkpoints más recientes
- Es completamente reversible en cualquier momento
Fusionar Cambios Aprobados en tu Rama
Una vez que los cambios han sido revisados y aprobados, pueden fusionarse de forma segura en tu rama.
Para fusionar:
- Abre el menú de acciones (⋮) del checkpoint seleccionado
- Haz clic en Merge
La fusión:
- Aplica los cambios del checkpoint seleccionado a tu rama actual
- Superpone los cambios entrantes sobre tu trabajo sin sobrescribirlo
- Actualiza únicamente los objetos compartidos que requieren fusión
- Preserva tu trabajo existente y el historial completo de versiones
- Crea un registro automático de fusión para trazabilidad total
Esto permite que los equipos combinen trabajo con confianza, sin perder progreso.
Revisión de Comentarios y Señales de Estado
Los colaboradores pueden dejar comentarios y marcar checkpoints como Ready (Listo para revisión), lo que ayuda a coordinar feedback y decidir cuándo los cambios están listos para fusionarse o publicarse.

Por ejemplo:
- Un compañero completa una funcionalidad
- Marca el checkpoint como Ready for review
- Deja un comentario explicando el cambio
Esto indica a los demás que el trabajo es estable y está listo para revisión o fusión.
Publicación y Despliegue
Los borradores y checkpoints están optimizados para la iteración.
La publicación es el paso en el que el proyecto se construye y se despliega en un entorno externo.
Cuando un proyecto se publica:
- Se generan los artefactos finales de compilación
- Se crea un registro de despliegue
- Se actualiza el entorno seleccionado
- Todos los borradores y checkpoints permanecen disponibles en el historial
Publicar nunca elimina ni reemplaza borradores — simplemente captura un estado y lo despliega.
Entornos de Despliegue

Development
- Usado para pruebas, validación y revisiones internas
- Genera una versión jugable en un entorno de prueba
- Seguro para experimentación y publicaciones frecuentes
- Puede republicarse varias veces sin afectar a usuarios finales
- Cada colaborador tiene su propio entorno de Development aislado
Los despliegues en Development no se guardan ni aparecen en la pestaña Verses.
Existen únicamente para pruebas individuales e iteración.
Production
- Representa la versión final y pública del proyecto
- Usado para usuarios reales y compartición externa
- Solo el propietario del proyecto o los administradores pueden desplegar en Production
- Cada despliegue en Production reemplaza al anterior
- Solo los despliegues en Production aparecen en la pestaña Verses
Permisos de Despliegue
En proyectos de equipo, las capacidades de despliegue dependen del rol del usuario:
- Colaboradores → Pueden desplegar solo en Development
- Administradores / Propietario → Pueden desplegar en Development y Production
Esto garantiza que todos los colaboradores puedan probar e iterar de forma independiente, mientras que las publicaciones en Production se mantienen intencionales, revisadas y controladas.