Todo lo que vimos hasta el momento es “lo básico” de Git. Es lo suficiente para que tomemos como punto de partida y empecemos a trabajar versionando nuestro proyecto en Unity. Para esto, vamos a, primero, agregarlo. Para este paso, tienen que ya tener creado el proyecto de Unity y, por supuesto, no tener Unity abierto. Lo que van a hacer a continuación, es copiar/cortar EL CONTENIDO de la carpeta que guarda el proyecto de ustedes, y pegarlo en la carpeta que guarda el repositorio de Git que, por lo general, debería tener el mismo nombre del proyecto, ya que la idea del repositorio es que justamente guarde el proyecto en sí.

Voy a crear un proyecto de Unity y copiar los archivos del proyecto a la carpeta donde tengo el repositorio:

Denle un vistazo a los archivos que se agregaron, que aparecen con los signos de pregunta. Pueden notar que faltan cosas? Los archivos que faltan son todos los que están dentro de la carpeta “Library” y “Temp” principalmente, pero… Por qué?

Si recuerdan, al principio de todo, agregamos un archivo “.gitignore” con el cual iniciamos el proyecto. Habíamos dicho que este archivo contiene TODO LO QUE SE VA A IGNORAR del proyecto. Y entre esas cosas que se van a ignorar, son las carpetas que acabo de decir. Por qué las ignora? Porque no hace falta que estén en el repositorio, ya que Unity las vuelve a generar automáticamente y NADA CAMBIA, a diferencia de los archivos “.meta“. De esta forma, nuestro proyecto pesa menos y está más “limpio” de archivos innecesarios. Noten que, además, se agregan los archivos “.meta” de los que habíamos hablado.

Si quieren ver, y editar, el archivo “.gitignore”, pueden hacerlo activando la visualización de archivos ocultos de su sistema operativo. Al abrir el archivo van a poder agregar más cosas que quieran ignorar. Recuerden commitear estos cambios, una vez modificado el archivo.

Para continuar, agregamos los archivos nuevos y ponemos algún nombre que marque el inicio de esa historia.

Como siguiente paso, abramos el proyecto en Unity, y empecemos a hacer cambios. Para empezar, vamos a crear un script simple llamado “Hero”:

Volvemos a SourceTree y vamos a ver los siguientes cambios:

Fijense que agregó un archivo “Scripts.meta” que simboliza el archivo meta asociado a la carpeta llamada “Scripts“. Pero, como bien habíamos dicho con anterioridad, no hay rastros de que haya agregado la carpeta en sí. Agreguen los archivos al área de “Stage“, pongan un texto, “Commit“. Pero esta vez, no hagan “Push“, ya que voy a mostrarles una cosita “mágica”. Entonces, el proyecto nos quedaría de la siguiente forma:

Ahora, con el commit realizado, hagan click en “master” para ver la historia del proyecto. Hagan click derecho en el punto anterior de la historia, donde agregamos el contenido del proyecto vacío, y luego en “Reset master to this commit” (en mac), o “Reset current branch to this commit” (en Windows). Les va a salir una ventana con un menú desplegable, que contiene tres opciones:

Les va a salir una ventana con un menú desplegable, que contiene tres opciones:

Las 3 opciones eliminan todos los commits que estén DELANTE del commit al cual querémos reiniciar. Pero además:

• Soft – keep all local changes: Conserva los cambios que hayas agregado al área de “Stage” y también conserva los archivos que hayas modificado pero que no hayan sido agregados al área de “Stage” aún.
• Mixed – keep working copy but reset index: Saca los archivos que hayan agregado al área “Stage”, pero conserva los archivos que hayan modificado y que estén en el área de abajo.
• Hard – discard all working copy changes: Saca los archivos en el área de “Stage” y además resetea el estado de todos los archivos que hayan modificado. Básicamente deja todo TAL CUAL estaba en ese commit.

Las 3 opciones vuelven los archivos al estado del commit al cual quieren volver. La diferencia es lo que hacen con los cambios que ustedes estén haciendo actualmente. En el caso de “Mixed” que es la opción por defecto, o “Soft” les va a agregar todos los cambios que hayan hecho como archivos listos para ser commiteados. Entonces, básicamente podrían volver a commitearlos con otro mensaje, o incluso podrían agregar menos archivos de los que agregaron en ese momento.

Al principio de esto les dije que no hagan “Push” porque quería mostrarles una cosa. Si pushean los cambios, este comando es un poco… Destructivo, ya que lo que hace es LITERALMENTE borrar toda la historia que haya delante para poner todo el proyecto en el estado que estaba en el commit que seleccionaron. Veamos qué pasa. Voy a elegir la opción “Soft”:

Fijense que literalmente borró toda la historia que había adelante. Peeeeeeero… Todos los cambios que esa historia que borró tenía, me los deja en el área de “Stage“:

O sea que si yo quiero tener acceso a todas las modificaciones que se hicieron, puedo, aún, tenerlo, o incluso volver a commitear los archivos, pero con otro mensaje. Agrego, entonces, otro mensaje, hago “Commit”, “Push” y nos queda entonces de la siguiente manera:

Y ahora, como quien dice, CAMBIAMOS LA HISTORIA. Pero… Por qué les dije en un principio que no hagan “Push”? Porque quería mostrar la parte “destructiva” de ese “Volver en el Tiempo”, ya que al hacerlo, perdímos toda esa parte de la historia, y eso no lo podemos volver atrás… O sí?

En realidad… Se puedo… Si antes hacemos “Push”. Veamos cómo queda ahora, si hacemos de nuevo un “Reset master to this commit“.

Ahora se ve un poco diferente… Qué cambió? Ahora nos marca con un color bordó/marrón un la parte de la historia en la que estamos, y además sale un mensaje que dice “1 behind“. Pero no sólo eso… No parece haber borrado la parte de la historia que estaba adelante! Qué pasó?

Lo que ocurre acá es que tenemos dos líneas de tiempo. O sea, nuestra “máquina del tiempo” lo que hizo fue regresar en el tiempo sólo la línea local. Pero… Quedó una especie de “universo paralelo” existiendo aún. Dónde? Pues… En GitHub! Lo que nos está diciéndo SourceTree es que nuestra copia del repositorio LOCAL está parada “1 commit atrás” que la historia que tenemos guardada online, en GitHub. Qué ventajas tenemos? Que ahora podemos AVANZAR en el tiempo. Literalmente podemos “Volver al Futuro”, al mismo punto del que habíamos partido, ya que ese universo paralelo que creamos al hacer “Push” sigue existiendo. Probemos. Hagan “Reset master to this commit” pero en el punto del FUTURO.

Fijense que ahora, todo quedó como antes. Como si nunca nos hubiéramos ido de esa posición en el tiempo. Es más… Fijense que les figura como que la hora del commit la hicieron en ese momento Y NO AHORA! O sea que literalmente hicimos un “Viaje en el Tiempo” con nuestro proyecto y nuestros archivos como si fuera un historial donde hacemos CTRL+Z y volvemos todo a como estaba.

Incluso… Podemos hacer más… Podemos LITERALMENTE modificar la historia del futuro y sobreescribirla con una nueva historia. Wow, wow… Suena peligroso. Lo es… Pero los viajes en el tiempo son peligrosos así que vamos a hacerlos igual. Una vez más… Volvamos en el tiempo, a un estado anterior. Pero esta vez, inmediatamente después de haber viajado en el tiempo vamos a borrar el archivo llamado “Hero.cs” y crear otro con otro nombre. Luego, lo commiteamos y veamos qué pasa. Mi script de Hero ahora se va a llamar “HeroController“.

Escribimos un texto para identificar el cambio y hacemos “Commit” pero sin el “Push“. Qué pasó ahora en nuestra línea de tiempo?

Fijense que el commit de más arriba ahora dice “1 ahead 1 behind“. Esto quiere decir que estamos un paso atrás en la historia, con respecto a la historia que está en GitHub, pero también un paso adelante. Qué? QUÉ?!?!?!

Bueno… LITERALMENTE estamos al mismo tiempo un paso adelante y un paso atrás con respecto a la historia guardada en GitHub. Cómo es posible?

• Estamos un paso atrás porque las historias coinciden HASTA el commit que nos movimos.
• Estamos un paso adelante porque la historia LOCAL tiene EXACTAMENTE 1 commit que la historia de arriba no tiene.

Pero como es de esperarse, no vamos a querer conservar las dos historias, sino una de ellas. Entonces, lo que vamos a hacer, es subir nuestra historia local, como venímos haciendo hasta el momento, y vamos a PISAR la línea de tiempo que está online, en GitHub. Básicamente vamos a… Eliminar el otro universo.

Vamos a apretar el botón de “Push” y veamos qué pasa…

Este mensaje básicamente no está diciendo que no puede subir nuestros cambios porque el servidor los rechaza, debido a que nuestra historia figura como “más antigua” que la historia que está arriba. Por eso entre todo ese mensaje podemos leer “Updates were rejected because the tip of your current branch is behind“. Esto es más que nada por la parte de nuestros cambios que figuran como que están detrás de la historia. Peeeeeeeeeero… Podemos decirle algo así como: “No me importa, subilos igual y pisa todo“. En términos de Git, esto se llama “Force Push“.

Esta herramienta es tan “peligrosa” como los mismos viajes en el tiempo. Ya que, vamos a estar LITERALMENTE sobreescribiendo la historia que está arriba que, también sería nuestra historia principal. Predeterminadamente SourceTree no nos da acceso a hacer esto. Podemos hacerlo por consola de comandos o… Decirle a SourceTree que nos permita hacerlo. Para esto, tenemos que ir a las opciones de SourceTree.

De esta manera, al intentar hacer “Push” de nuevo, vamos a tener desbloqueada la opción de “Force push” para activarlo en cualquier momento. Marquenla, hagan push y vean qué pasa.

Ese mensaje nos advierte de que alterar el tiempo podría tener consecuencias graves y que podríamos llegar a cagarla de alguna manera. Pero como en este momento sabemos lo que estamos haciendo (o eso creemos), aceptamos y lo hacemos igual. Entonces, nos quedaría todo de la siguiente manera:

Ahora sí… Sobreescribimos la historia y aprendimos un poco más acerca de los viajes en el tiempo! Digo… De Git!