Git para Unity: control de versiones sin romper nada

Por qué control de versiones#

Guardar tu proyecto en Git te da: historial (volver a cualquier punto), copia de seguridad remota, y trabajo en equipo sin pisarse. Incluso en solitario, poder deshacer "el día en que rompí todo" vale oro. Pero Unity tiene particularidades que, si las ignoras, convierten Git en un infierno.

Lo primero: un .gitignore correcto#

Un proyecto de Unity genera carpetas que NO deben subirse: son enormes, cambian solas y se regeneran. Sube solo Assets/, Packages/ y ProjectSettings/.

Nunca subas Library/ (ni Temp/, Logs/, Build/)

Library/ es una caché que Unity regenera desde tus assets: pesa gigas, cambia constantemente y no aporta nada al repositorio. Subirla es el error nº1. Usa el .gitignore oficial de Unity (enlazado en las fuentes) que ya excluye Library/, Temp/, Logs/, Obj/, Build/, etc.

texto

# Extracto de un .gitignore de Unity
[Ll]ibrary/
[Tt]emp/
[Oo]bj/
[Bb]uild/
[Ll]ogs/
*.csproj
*.sln

Git LFS para los assets grandes#

Git está pensado para texto (código), no para archivos binarios grandes (texturas, audio, modelos). Si subes esos a Git normal, el repositorio se hincha sin control. La solución es Git LFS (Large File Storage): guarda los binarios aparte y en el repo deja solo un puntero.

texto

# .gitattributes — que LFS gestione estos tipos
*.png filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text

Configura LFS antes de subir los binarios

Instala Git LFS y crea el .gitattributes al empezar el repo. Si subes primero los binarios a Git normal y migras después, es un lío. Configúralo desde el primer commit.

El problema de las escenas y prefabs#

Las escenas casi no se pueden fusionar

Los archivos .unity (escenas) y .prefab son de texto (YAML), pero muy difíciles de fusionar a mano si dos personas editan la misma escena a la vez: los conflictos son casi imposibles de resolver. Estrategias:

Comunicación: que dos personas no toquen la misma escena a la vez.
Divide el trabajo en varias escenas (aditivas) o en prefabs.
Activa el Smart Merge de Unity (herramienta UnityYAMLMerge) en tu configuración de Git para ayudar con estos conflictos.
En Project Settings, Asset Serialization → Force Text y Visible Meta Files (suele venir así por defecto): necesario para que Git vea los cambios.

Los archivos .meta#

Cada asset tiene un archivo .meta que guarda su ID y su configuración de importación. Súbelos siempre junto a su asset: si falta un .meta, Unity genera otro con distinto ID y rompe las referencias (todo lo que apuntaba a ese asset se queda en blanco). El .gitignore oficial ya los conserva.

Un flujo de ramas sencillo#

🛠️ Decisión de ingeniería

Solo / pequeño → una rama principal + commits frecuentes con mensajes claros
Equipo pequeño → main estable + una rama por funcionalidad (feature/inventario), y fusionar cuando esté lista
Regla de oro → commits pequeños y a menudo; nunca commits gigantes de "todo el día" imposibles de revisar

¿Git o Plastic SCM?#

Git es el estándar y gratis (GitHub, GitLab). Unity Version Control (antes Plastic SCM) está integrado en el editor y maneja mejor los binarios grandes y los bloqueos de archivos, pensado para equipos de juego. Para la mayoría de indies, Git + LFS es suficiente y más portable.

Errores frecuentes#

Subir la carpeta Library/ (repositorio gigantesco e inútil).
No usar LFS y ahogar el repo con binarios.
Ignorar los .meta y romper las referencias del proyecto.
Dos personas editando la misma escena y generando conflictos irresolubles.
Mover/renombrar assets desde fuera de Unity (rompe los .meta y las referencias).

Ponte a prueba#

📝 Pon a prueba lo aprendido

Resumen#

Usa Git con el .gitignore oficial de Unity (jamás subas Library/), configura Git LFS desde el principio para los binarios, y sube siempre los .meta. Ten cuidado con las escenas (difíciles de fusionar: divide el trabajo y usa Smart Merge), mueve assets dentro de Unity, y trabaja con commits pequeños y una rama por funcionalidad. Va de la mano de una buena organización del proyecto.