Conviene haber comprendido Herramientas y extensiones del Editor.
Avanza en orden. Cada lección está redactada para Palta es Cool, utiliza ejemplos propios y termina con una actividad cuya respuesta puedes desplegar.
Ubícate antes de avanzar
Al terminar deberías poder relacionar Repositorio Unity con Commit, push y ramas y resolver un caso nuevo.
Reserva entre 75 y 120 minutos o divide el laboratorio en dos sesiones.
Instala Unity Hub, una versión LTS compatible y un IDE con integración para C#. Conserva un proyecto de laboratorio separado.
Abrir la guía de herramientas →Diagnóstico rápido: ¿cómo se relacionan Repositorio Unity y Commit, push y ramas? +
No necesitas acertar todavía. Escribe una hipótesis de dos líneas y compárala con tu respuesta al finalizar; si puedes corregirla y justificar el cambio, hubo aprendizaje.
Aprende el tema paso a paso
Protegerás el proyecto con un historial comprensible y aprenderás a tratar escenas, assets y archivos .meta como datos relacionados.
- Assets, Packages y ProjectSettings describen el proyecto
- Status y diff preceden a commit, push y merge
- Un conflicto exige reconstruir la intención y probar Unity
Assets, Packages y ProjectSettings describen el proyecto
El repositorio debe conservar fuentes, configuración y archivos .meta. Library, Temp, Logs y otros caches se regeneran y normalmente se ignoran. Mover un asset junto con su .meta conserva el identificador usado por las referencias.
Usa un .gitignore específico para Unity.
No versiones credenciales, builds ni caches regenerables.
Revisa que cada asset nuevo incluya su .meta.
¿Por qué versionar solo Assets no basta?
Mostrar respuesta +
Porque las dependencias de paquetes y ajustes del proyecto también determinan cómo compila y se comporta. Sin ellos, otra persona no reconstruye el mismo entorno.
Status y diff preceden a commit, push y merge
Un commit es una unidad coherente y comprobada; push comparte; pull o fetch más merge integra cambios. Las ramas aíslan trabajo, pero no reemplazan comunicación ni pruebas. Antes de registrar, revisa exactamente qué cambió.
Un commit responde a una intención.
No mezcles reorganización masiva con una función nueva.
Actualiza e integra con frecuencia para reducir conflictos.
¿Por qué “cambios varios” es un mal mensaje de commit?
Mostrar respuesta +
No explica la intención ni ayuda a encontrar, revisar o revertir una decisión. El historial deja de servir como herramienta de diagnóstico.
Un conflicto exige reconstruir la intención y probar Unity
Los marcadores muestran versiones incompatibles; resolver no es elegir automáticamente un lado. Escenas y prefabs serializados pueden requerir coordinación, YAML Merge o una reconstrucción controlada. Después hay que abrir el proyecto y verificar referencias.
Lee ambos cambios y el estado base.
Conserva archivos .meta con su asset correspondiente.
Compila, abre escenas y ejecuta una prueba mínima tras integrar.
¿Qué debes hacer después de borrar los marcadores de conflicto?
Mostrar respuesta +
Revisar el diff, abrir Unity sin errores, comprobar las escenas o prefabs afectados y ejecutar la prueba relacionada antes de completar el merge.
Tu recorrido en tres ideas
- Assets, Packages y ProjectSettings describen el proyecto
- Status y diff preceden a commit, push y merge
- Un conflicto exige reconstruir la intención y probar Unity
Comprueba que puedes usarlo
Antes de continuar, revisa estos tropiezos frecuentes y resuelve un caso sin copiar los ejemplos.
Versionar Library o builds mientras faltan Packages, ProjectSettings o archivos .meta.
Resolver un conflicto de escena eligiendo un lado sin reconstruir la intención.
Ahora hazlo sin guía
Prepara un repositorio Unity, crea una rama, realiza dos commits coherentes y resuelve un conflicto controlado.
Mostrar pauta de corrección +
- El clon limpio reconstruye el proyecto y conserva referencias.
- Cada commit tiene una intención comprobable y diff revisado.
- Después del merge Unity abre, compila y ejecuta el caso afectado.
