🎮 UnityDocs

Flujo de trabajo en equipo

Cómo trabajar varias personas en un proyecto Unity sin pisarse: control de versiones con los ajustes correctos, evitar conflictos en escenas, el problema de los archivos grandes (LFS) y buenas prácticas de organización y comunicación.

📄 ArtículoAvanzado✅ RevisadoUnity 6.0 LTSActualizado 2026-07-15
DificultadConceptual Código Matemáticas
Tiempo📖 Lectura 8 min

Varias manos en el mismo proyecto#

Trabajar en equipo en Unity tiene trampas propias que no aparecen cuando estás solo. Con el control de versiones bien configurado y unas normas sencillas, evitas el caos de "hemos roto la escena otra vez".

Configurar Unity para colaborar#

Dos ajustes en Project Settings → Editor son obligatorios en equipo:

  • Version Control Mode → Visible Meta Files: cada asset lleva un archivo .meta con su configuración e ID. Deben versionarse junto al asset; sin ellos, se rompen las referencias.
  • Asset Serialization → Force Text: guarda escenas y prefabs en texto (YAML) en vez de binario. Es lo que hace posible que el control de versiones pueda fusionar y mostrar diferencias.
Sin Force Text, las escenas son intratables

Si dejas la serialización en binario, cada escena es un blob ilegible: no se puede ver qué cambió ni fusionar dos versiones, y cualquier conflicto obliga a elegir "todo lo mío o todo lo tuyo", perdiendo trabajo. Force Text es innegociable en equipo.

El .gitignore de Unity#

No subas al repo lo que Unity regenera. Usa un .gitignore de Unity que excluya como mínimo:

gitignore
[Ll]ibrary/
[Tt]emp/
[Oo]bj/
[Bb]uild/
[Bb]uilds/
[Ll]ogs/
[Uu]serSettings/

Subir la carpeta Library/ (que puede pesar gigas y es local) es el error de novato nº1. Se regenera sola al abrir el proyecto.

El gran problema: las escenas#

Aunque sean texto, dos personas editando la misma escena a la vez casi siempre genera conflictos difíciles. Estrategias para evitarlo:

  • Dividir el trabajo por escenas: cada quien en la suya siempre que se pueda.
  • Prefabs en lugar de objetos sueltos: si cada sistema (enemigo, UI, gestor) es un prefab, la gente edita prefabs distintos y no la misma escena. Es la mejor defensa.
  • Escenas aditivas: cargar varias escenas a la vez (SceneManager) permite que cada persona trabaje en un "trozo" del nivel por separado.
  • Comunicación: avisar "estoy tocando la escena del menú" evita choques.
Prefabs = paz en el equipo

La regla que más conflictos evita: casi todo debería ser un prefab, y la escena solo los coloca. Así el diseñador ajusta el prefab del enemigo mientras otro trabaja el nivel, y sus cambios no colisionan. Un proyecto con escenas llenas de objetos únicos es un imán de conflictos.

Smart Merge: fusionar escenas de Unity#

Unity incluye una herramienta, UnityYAMLMerge (Smart Merge), que entiende el formato YAML de escenas y prefabs y resuelve muchas fusiones automáticamente. Se configura en el sistema de control de versiones para que la use al fusionar archivos .unity y .prefab. No hace magia con conflictos grandes, pero salva muchos pequeños.

Archivos grandes: Git LFS#

Git no lleva bien los binarios pesados (texturas, audio, modelos, vídeo): el repo se hincha porque guarda cada versión entera. Git LFS (Large File Storage) guarda esos archivos aparte y en el repo deja solo un puntero. Configura LFS para las extensiones pesadas:

gitignore
*.psd filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text
¿Git o Unity Version Control?

Git + LFS es el estándar y gratis, pero sufre con proyectos enormes y con el bloqueo de archivos. Unity Version Control (antes Plastic SCM) está pensado para juegos: maneja mejor los binarios grandes y permite bloquear archivos (avisar de que una escena está "en uso") para evitar conflictos. Para equipos con mucho arte, merece considerarlo.

Buenas prácticas de equipo#

  • Commits pequeños y frecuentes, con mensajes claros.
  • Actualizar (pull) antes de empezar y antes de subir, para no acumular divergencias.
  • Convenciones compartidas: nombres, estructura de carpetas (organiza tu proyecto) y estilo de código iguales para todos.
  • Integración continua: ejecutar los tests automáticamente en cada cambio subido.
  • Nunca subir credenciales ni claves en el repo.

Errores frecuentes#

  • No versionar los archivos .meta (se rompen las referencias).
  • Dejar la serialización en binario (escenas imposibles de fusionar).
  • Subir la carpeta Library/ al repo.
  • Varias personas en la misma escena en vez de repartir por prefabs/escenas.
  • Binarios pesados sin LFS, hinchando el repositorio.

Ponte a prueba#

📝 Pon a prueba lo aprendido

Resumen#

Para trabajar en equipo en Unity: configura Visible Meta Files y Force Text (YAML) (imprescindibles para fusionar), usa un .gitignore de Unity (nunca subas Library/), reparte el trabajo por prefabs y escenas para no chocar (prefabs = paz), aprovecha Smart Merge y Git LFS para binarios pesados (o valora Unity Version Control con bloqueo de archivos), y adopta commits pequeños, convenciones comunes y tests en integración continua. Todo sobre la base de Git para Unity.

Fuentes y para profundizar