# Práctica 1: Primer contacto con Git

## Objetivos
- Primer contacto con Git y GitHub
- Mostrar los casos de uso más habituales con Git/GitHub
- Incorporar Git al flujo de trabajo personal

## Prerrequisitos

- Entender qué son los [entornos virtuales](https://hackmd.io/@dfbarrero/entorno-trabajo-videojuegos) y cómo se utilizan con VS Code.
- Tener [Git](https://git-scm.com/) instalado.
- [GitHub Desktop](https://desktop.github.com/download/) es un cliente Git gráfico que **no** es necesario para hacer esta práctica, pero sí es útil conocerlo.

Una vez preparado el entorno de trabajo, introduciremos algunos de los escenarios más comunes para trabajar con Git y GitHub.

## Escenario 1: Respositorio local sin remoto

El escenario más sencillo en el que se puede utilizar Git es manteniendo un repositorio local sin asociarlo a ningún repositorio remoto. De este modo se mantiene más simple, pero al no mantener una copia en un equipo externo, **no nos va a proteger ante problemas con el disco duro** o borrados accidentales.

Vamos a practicar este escenario, que es poco realista, pero nos permite una buena primera toma de contacto con Git. Haz las siguientes actividades.

1. Crea un directorio vacio.
2. Abre el directorio con VS Code.
3. Añade un archivo (```main.py```, por ejemplo).
5. Comprueba si el directorio tiene archivos ocultos.
6. Inicializa el repositorio (*git init*).
8. Vuelve a comprobar si el directorio cnotiene archivos ocultos.
9. Edita edita el script para que imprima un mensaje por pantalla (¡hola, mundo!).
10. Agrega el archivo al área de preparación (*git add*, o *stage* en terminología de VS) y "commitea" los cambios.


12. Cambia el script para que imprima el mensaje 10 veces por pantalla. Observa cómo VS marca los cambios del archivo.
13. Vuelve a marcar el archivo y a subir los cambios al repositorio local.
14. Cambia el proyecto cuanto quieras, guardando los cambios en el respositorio local.
15. Repite 13 varias veces.
16. Borra el proyecto (o conservalo, pero no lo vamos a volver a usar).

## Escenario 2: Crear un repositorio nuevo desde GitHub
En este escenario partimos sin repositorios de ningún tipo, ni local ni remoto. La forma más sencilla para trabajar de este modo es, posiblemente, crear un repositorio vacío en GitHub, y luego clonarlo para poder empezar a trabajar con él en local.

Para poner en práctica este escenario, haz la siguientes tareas:

1. Crea un nuevo repositorio en Github llamado "prueba", da igual si es privado o público.
2. Clona el repositorio "prueba". Esto es una opción que nos da VS cuando creamos una ventana nueva o arrancamos el IDE sin ningún proyecto abierto. Es posible que GitHub te pida autorización o que tengas que aportar la URL que identifica el proyecto.

> [!Note]
> Recuerda que los repositorios se identifican por medio de una URL. Dado que VS Code tiene nuestras credenciales de GitHub, puede acceder a todos nuestros repositorios, y no es estrictamente necesario darle la URL, aunque se puede hacer.

Con esto ya tenemos creado un repositorio local con el que trabajar. Ya puedes, por ejemplo, agregar archivos nuevos al repositorio y publicar sus cambios en GitHub. Sigamos implementando un flujo de trabajo habitual trabajando con el repositorio recién creado.

3. Crea un nuevo archivo llamado ```sumar.py``` que contenga un script escrito en Python que muestre por pantalla la suma de los cien primeros números. Puedes utilizar el siguiente código:

suma = 0
for i in range(1, 100):
    suma += i

print(f"La suma de los primeros 100 números es: {suma}")

4. Agrega el archivo recién creado al *staging area*.
5. "Commitea" los cambios.

Dado que tenemos un repositorio remoto, ya podemos hacer una operación *git push. Vamos a hacerlo.

6. "Pushea" los cambios.

Felicidades, acabas de realizar tu primer flujo de trabajo completo con Git. Lo habitual es que cada vez que hagas un cambio significativo en el código es que realices un commit.

>[!TIP] Consejo
>Para saber si un cambio es significativo, pregúntate si te dolería perder ese cambio. Si la respuesta es afirmativa, guarda los cambios.

7. Cambia el código anterior para que en vez de calcular la suma de los cien primeros números enteros, haga la multiplicación.
8. Guarda el resultado en GitHub.

>[!CAUTION] Regla de oro
> Nunca, nunca, nunca, "commitees" cambios al respositorio que no hayas testeado previamente.

## Escenario 3: "Forkear" un repositorio existente en GitHub
El escenario más frecuente, y el que usaremos en la asigantura, es empezar a trabajar a partir de un repositorio ya disponible en GitHub. Este escenario se da, por ejemplo, cuando se accede a una plantilla para hacer una práctica, o se quiere colaborar en un proyecto de software libre.

La diferencia, en este caso, es que ya existe un repositorio remoto previo que pertence a un usuario distinto al tuyo, por lo que no tendrás permiso de escritura. Es decir, si intentas "pushear" tus cambios te saldrá un error.

Para solucionar esta situación, GitHub nos proporciona la posibilidad de hacer un "fork", que básicamente consiste en copiar un repositorio remoto del que no se es propietario en otro repositorio remoto del que sí eres propietario. Una vez que has hecho un fork, puedes trabajar con el nuevo repositorio con total normalidad.

En este escenario vamos a ejecutar, por primera vez, un Hola Mundo escrito en Arcade, para ello vamos a apoyarnos en un repositorio que guarda un *script* con el hola mucho, así como una plantilla para hacer este primer bloque de prácticas: https://github.com/dfbarrero/arcade-labs.

En base al repositorio anterior, haz las siguientes tareas:

0. Abre una nueva ventana con VS Code.
1. "Forkea" el repositorio.
2. Clona el repositorio.
3. Ejecuta el script ```lab01-git/lab01-git.py```.

>[!Important] requirements.txt
>Fíjate que este proyecto tiene un archivo ```requirements.txt``` que contiene las dependencias. Cuando crees un entorno virtual para este proyecto, VS Code va a localizar ese archivo y te ofrecerá la posibilidad de instalar las dependiencias automáticamente. Esto es una gran ayuda para facilitar el despliquegue de nuestros proyectos.

4. Introduce los cambios que quieras, "commiteando" y "pusheando" periódicamente los cambios.

> [!Note] Puedes encontrar ideas para usar la función ```draw_text()``` en este [enlace](https://api.arcade.academy/en/stable/example_code/drawing_text.html).

## Escenario 3: Colaborar con un repositorio compartido.
Git por sí mismo es una gran herramienta para gestionar el código en proyectos individuales, pero en donde brilla con más fuerza es facilitando la colaboración en equipos de desarrolladores. Vamos a implementar un flujo de trabajo en equipo utilizando Git como herramienta de control de versiones.

La dinámica de trabajo en este escenario es la misma que en el caso individual, la única diferencia es que todos los desarrolladores deberían de tener acceso de escritura en un repositorio compartido. Conseguir esto es tan sencillo como que el dueño de un repositorio agregue a los usuarios que estime oportuno en GitHub.

1. Busca a un compañero o compañera para formar un equipo.
2. Uno de los integrantes del equipo debe dar permisos, para ello debe ir a la vista del repositorio que quiera compartir y de a la opción "*Settings->Collaborators->Add people*".
3. Los compañeros ahora pueden clonar el respositorio compartido y pushear los cambios al repositorio remoto.
4. Realizad, de forma coordinada, varios cambios en el código, commiteando y pusheando.

> [!Warning] Aviso
> Asegúrate de tener enviados todos los cambios que te interesen antes de pasar al siguiente escenario.

## Escenario 4: Recuperación de fallos
Uno de los motivos por los que se utiliza Git incluso cuando se trabaja individualmente es que Git facilita que nos recuperemos ante fallos que, aunque sean improbables, sí o sí terminarán suceder en algún moemnto. Siempre podemos borrar accidentalmente un archivo crítico en algún momento, se puede romper un disco duro, o se puede perder un portátil. Es recomendable que estemos preparados para cuando se nos de una situación así. Porque sucederá.

Vamos a generar algunas situaciones para entender mejor cómo podemos usar Git ante estas situaciones.

### Borrado accidental de archivos
1.- ¡CATÁSTROFE! Se acaba de borrar el contenido del subdirectorio ```lab01-git```. Utiliza un navegador de archivos u otra herramienta externa a tu IDE para borrar dicho directorio. Ten cuidado de borrar sólo ese subdirectorio.

2.- Recupera el directorio borrado. Investiga en VS Code cómo puedes recuperar el directorio borrado. Fíjate que los archivos se han borrado en el directorio de trabajo, pero no en los respositorios, ni local ni remoto.

<!--
### Vuelta a una versión anterior
A veces desarrollamos código y nos damos cuenta de que el camino elegido no es el más adecuado, y se hace oportuno dar una "marcha atrás" a una versión anterior del código. Esto con Git es bastante sencillo.

1. Haz un cambio en tu hola mundo, a ser posible a algo que no te guste.
2. Commitea los cambios.
3. Introduce un cambio en el proyecto, y commitea.
-->

### Resolución de un conflicto
Los conflictos son uno de los problemas más habituales que nos encontramos en el trabajo diario, tanto si operamos sobre un repositorio compartido, como si no. Es muy habitual que se generen conflictos, por ejemplo, cuando uno trabaja individualmente pero en distintas ubicaciones (por ejemplo, en un ordenador del laboratorio y un ordenador portátil personal). Saber resolver conflictos es una habilidad que nos facilitará bastante nuestra vida como programadores.

Vamos a simular la creación de un conflicto para practicar la recuperación.

1. Desde VS Code, edita el archivo ```lab01-git/lab01-git.py``` e introduce un cambio en una línea determinada. Por ejemplo, puedes cambiar el nombre a la ventana.
2. Desde GitHub, edita el mismo archivo y pon algo diferente. Con esto estamos imitando a un compañero que haya pusheado sus propios cambios a GitHub.

En este momento tenemos dos versiones del mismo archivo, una en local, y otra en GitHub.

3. Intenta "commitear" y "pushear" tu cambio local. En este momento se generará un error

Vas a ver que al pushear, Git intentará fusionar (*merge*) el repositorio local y remoto, pero tiene dos versiones del mismo archivo que cambian en el mismo lugar, por lo que Git no tiene ningún mecanismo objetivo con el que resolver esta situación. **Git requiere que un humano resuelva el conflicto**.

VS Code te va a generar una pantalla en la que se te muestra las diferencias que ha encontrado en el formato visto en clase de teoría.


Adicionalmente VS Code te da la posibilidad de visualizar el conflicto con un editor que muestra lado a lado cada una de las versiones del archivo, así como una vista preliminar del archivo fusionado. Básicamente hay dos posibles acciones: aceptar el cambio del archivo local o aceptar el cambio del archivo remoto.


4. Resuelve el conflicto. Recuerda que un conflicto queda resuelto cuando un archivo es enviado a la zona de almacenamiento.

5. *[Opcional]* Un ejercicio adicional que puedes realizar es intentar generar conflictos con un compañero y resolverlos.

Más sobre resolución de conflictos en Git en este [enlace](https://code.visualstudio.com/docs/sourcecontrol/merge-conflicts).

### Más información

* [Version control in VS Code](https://code.visualstudio.com/docs/sourcecontrol/overview)