Capacitaciones IESTA

# Capacitaciones IESTA - Taller 2
## Taller de Git
### Mauro Loprete
### 21 de Febrero de 2022

---

# ¿Qué es y para que sirve git?

- #### Es un sistema de control de versiones diseñado (originalmente) para desarrollo de software de manera colaborativa.

- #### Lo usamos para manejar la colección de archivos que hacen a un proyecto (datos, figuras, reportes, código fuente).

- #### Git permite el seguimiento de la evolución de un conjunto de archivos que se llama repositorio. 
--

- #### Un sistema de control de versiones nos va a servir para trabajar en equipo de una manera mucho más simple y óptima cuando estamos desarrollando software. 
--

- #### Trackear y obtener versiones anteriores de nuestro proyecto de manera sencilla

---

# Comandos básicos en terminal

- #### **pwd:** Ver la ruta actual

- #### **cd:** Navegar entre carpetas

- #### **ls:** Listar los archivos de una carpeta

- #### **cp,mv:** Nos permite copiar archivos, mover o renombrarlos

- #### **cp -r:** Copiar carpetas

- #### **mkdir:** Permite crear carpetas

- #### **rm:** Eliminar archivos

- #### **rmdir:** Eliminar carpetas

Y muchos más, zip,unzip,touch,echo,cat,tail,head y un largo etc.
---

# Instalación :

## En windows :

<https://git-scm.com/download/win>

## En linux basado en Fedora :

```bash
sudo apt-get install git-all
```

## En Mac (con el uso de Homebrew) :

```bash
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install git
```
---

# Terminología

- #### **Repository:** Archivos, directorios a las cuales git les esta haciendo seguimiento.

- #### **Clone:** Copia local de un repositorio en la nube.

- #### **Pull:** Traer a nuestro repositorio local los cambios locales de la nube.

- #### **Commit:** Confirmación 'instantanea' de nuestro directorio de trabajo, cada uno de ellos tiene un identificador único, hora y el nombre de la persona que lo hizo.

- #### **Push:** Enviar nuestras confirmaciones al repositorio remoto.

Y mas, como **pull request**, **fork**, etc.

---

# Repositorio locales y remotos 
.center[
<img src="Flujo.png" width="900" />
]

---

# Guía del taller

- ## **Módulo 1:** Introducción a git

- ## **Módulo 2:** Uso del control de versiones

- ## **Módulo 3:** Correción de errores

- ## **Módulo 4:** Trabajando con ramas

- ## **Módulo 5:** git stash

- ## **Módulo 6:** gitignore

---
class: title-slide,middle

# Módulo 1: Introducción a git

## 1. Configurar nuestra información 
## 2. Crear repositorios locales 
## 3. Asociar repositorio local con un repositorio remoto 
## 4. Workflow of git repository´s (add, commit, push) 
## 5. Clonar repositorios

---

# Módulo 1: Introducción a git

## Configurar git

### git config

```bash
git config --global user.email "Nuestro correo"
git config --global user.name "Nuestro apodo"
```

A cada commit se le asocia está información para identificar los cambios realizados por cada integrante del equipo.

#### Tip: Diferentes nombres en cada proyecto

Podemos modificar esa configuración sin afectar la configuración global, para esto simplemente modificamos lo anterior de esta manera :

```bash
git config user.email "Nuestro correo"
git config user.name "Nuestro apodo"
```

---

# Módulo 1: Introducción a git

## Crear repositorios locales

### git init

Primero tenemos que situarnos en nuestro directorio, movernos con el comando de la terminal `cd` y la ruta de nuestro directorio.

Una vez hecho esto, vamos a pedirle a git que haga el seguimiento de este directorio, lo haremos de la siguiente forma :

```bash
git init 
```

Luego nos saldrá un mensaje haciendo referencia a que ya estamos haciendo el seguimiento de nuestro directorio con **git**.
---

# Módulo 1: Introducción a git

## Asociar repositorio local con uno remoto

### git remote

En el caso de querer trabajar con ramas remotas (Github, Gitlab, entre otros) debemos de crear la conexión con la nube. Para esto debemos de contar con una cuenta 
y crear un repositorio desde su página web, para asociar la dirección a nuestro repositorio local.

```bash
git remote add origin https://github.com/Usuario/NombreRepositorio.git
```

#### Tipos de repositorios remotos :

- **Públicos:** Acceso a todo el mundo.

- **Privados:** Para colaborar y ver el repositorio debemos de ser colaboradores.

---

# Módulo 1: Introducción a git

## Añadir archivos / Agregar cambios

### git add

Una vez guardemos nuestros cambios en el archivo de manera habitual, debemos de indicarle a git que terminamos de modificarlo.

En el caso que el archivo sea nuevo, este comando agregara el archivo al repositorio y en caso que ya le este haciendo seguimiento irá tomando 
las difrencias.

```bash
git add archivo.txt
```

## Quitar cambios

### git restore

```bash
git restore --staged archivo.txt
```

---

# Módulo 1: Introducción a git

## Hacer confirmaciones (commit's)

### git commit

```bash
git commit
```

La terminal de git en windows por defecto usa **VIM** (editor de texto en terminal), una vez ejecutado el siguiente comando se nos desplegará una ventana para escribir el mensaje
del commit, siempre git nos hace una sugerencia, podemos escribir la nuestra o incorporar esta última.

Para hacer modificaciones sobre este texto debemos de apretar la tecla **INSERT** una vez hecho esto, la terminal entrara en modo edición. 
Para salir de este modo debemos de apretar la tecla **ESC**, el signo de **:** y **wq** para guardar el archivo. Tambien existe **NANO** que automaticamente se entra en modo edición, para guardar y salir utilizamos
**CTRL+O** y **CTRL+X**.

#### Tip: Mensaje corto

Podemos utilizar el flag **-m**, para indicar el mensaje que queremos.

```bash
git commit -m "Nuestro mensaje"
```

---

# Módulo 1: Introducción a git

## Subir cambios a la nube

### git push

```bash
git push <remote> <rama>
```

Debemos de indicarle la dirección del repositorio remoto y la rama que queremos subir.

#### Tip: Actualizar todas las ramas

```bash
git push --all <remote>
```

#### Solución de errores: Cambios en historial y actualizar historial remoto

En algunas situaciones, se puede llegar a modificar el historial teniendo como consecuencia que para un mismo commit dos identificadores diferentes, es por esto,
que debemos de actualizarlo en el reposiotorio remoto y advertir a nuestros compañeros.

```bash
git push --force <remote> <rama>
```

---

# Módulo 1: Introducción a git

## Traer cambios de la nube

### git pull

```bash
git pull <remote> <rama>
```

#### Solución de errores: Cambios en historial remoto

```bash
git pull --rebase <remote> <rama>
```

## Actualizar ramas remotas pero no fusionarlas con las locales

### git fetch

```bash
git fetch <remote>
```

---
class: inverse,middle

# Parte práctica 1

### 1. Crear repositorio con un archivo de texto desde la terminal 
### 2. Crear un repositorio en github vacio y añadirlo como fuente remota 
### 3. Clonar repositorio del Taller 
---

# Módulo 2: git como sistema de control de versiones

## 1. Ver historial
## 2. Navegar en el historial
## 3. Comparar versiones
## 4. Ver el estado del proyecto

---

# Módulo 2: git como sistema de control de versiones

## Ver historial

### git log

Este comando nos permite ver el historial de todo nuestro proyectox

```bash
git log
```

#### Tip: Mejorar la visualización

```bash
git log --all --decorate --oneline --graph
```
El comando **all** nos permite ver información sobre todas las ramas, incluso las ocultas que refieren a las remotas, **decorate** nos brinda colores en la terminal, **oneline** hace que tengamos una presentación en la terminal agradabale y **graph** nos da una visualización de la ramificación de nuestro proyecto.

---

# Módulo 2: git como sistema de control de versiones

## Navegar en nuestro historial

### git checkout

```bash
git checkout <Hash commit>

```

**¡OJO!** Cuando se navega en el historial se crea una 'rama' temporal que apunta a ese commit.

## Volver a la situación actual

### git switch

```bash
git switch -
```

Al que tanto la versión temporal como al lugar donde queremos regresar son ramas, podemos usar **git checkout rama** para volver a la situación actual, pero lo veremos mas adelante.

---

# Módulo 2: git como sistema de control de versiones

## Ver modificaciones actuales

### git diff

Con este comando podemos ver las modificaciones que fuimos haciendo sobre los archivos que git le esta haciendo seguimiento.

```bash
git diff <archivo> # Si estaomos interesados en comparar el último commit con lo que esta en el WD
git diff --staged <archivo>s # Si estamos interesados en comparar con SA
```

## Comparar commits

### git diff

También podemos ver cambios relativos entre diferentes commits para esto únicamente debemos de indicar los hash de los dos commit:

```bash
git diff <hash commit más viejo> <hash commit mas nuevo> --flag's <archivo>
```
 
---

# Módulo 2: git como sistema de control de versiones

## Ver estado del repositorio

### git status

```bash
git status 
```

Este comando nos indica información relativa a la rama en la que estamos situados, los cambios que estan prontos para hacerles un commit (**SA**)
y los que todavía se encuentran en el directorio de trabajo (**WD**).

#### Tip: Versión compacta

```bash
git status -s
```

A cada archivo se le agrega la información de su estado, por ejemplo:

- **M** a la izquierda (verde) : Archivo modificado y agregado a SA.
- **M** a la derecha (rojo) : Archivo modificado en WD.
- **A** a la izquierda (verde) Nuevo archivo agregado al SA.
- **??** a la derecha (rojo) Archivo nuevo que git nunca le hizo seguimiento.

---

# Parte práctica 2

### 1. Ver el historial del repositorio del taller 
### 2. Agregar un cambio a nuestro repositorio de prueba y ver git diff 
### 3. Salida del git status (en sus dos versiones)

---

# Repaso del taller anterior:

#### - Aprendimos comandos básicos de la terminal

Utilizamos por primera vez la terminal, navegamos entre nuestros directorios con **cd**, listamos archivos con **ls**.

Creamos nuestro directorio de trabajo con **mkdir**, luego agregamos un archivo de ejemplo con el block de notas utilizando **notepad**.

#### - Primer contacto con git y vimos sus posibles usos.

Primero configuramos nuestra información de usuario con **git config --global user.name "Nombre"** y **git config --global "user.email"**.

Vimos que existe la posibilidad de configurar un nombre personalizado para cada proyecto o consultar la información fijada, 
quitando los flgs (comando luego de --) ó simplemente haciendo referencia a que variable desemos consultar (Para user.name : **git config user.name**), respectivamente.

Convertimos nuestro directorio en un repositorio de git con **git init**.

Hicimos nuestro primer commit, primero, le indicamos a git que le de seguimiento al archivo de prueba con **git add**,
esto hizo que el archivo pase del directorio de trabajo (WD) al área de preparación (SA) pronto para incluir su 'etiqueta'.

Una vez allí, pudimos hacer nuestro primer commit con **git commit**, probamos la versión 'corta' con **git commit -m "Mensaje"** y 
también aprendimos a hacerlo desde VIM, en el caso de querer mensajes mas extensos.

---

# Repaso del taller anterior:

#### - Creamos nuestro primer repositorio local y en la nube.

Desde Github, creamos un repositorio vacio, una vez hecho esto obtuvimos un enlace. A nuestro repositorio local le indicamos este enlace utilizando,
**git remote add <NombreOrigin> <Enlace>**.

Tuvimos algunos percances, ingresamos mal el enlace, y luego lo corregimos con **git remote set-url {NombreOrigin} {Enlace}**.

Una vez hecho esto, le pedimos a git que subiera nuestro repositorio a la nube con **git push {NombreOrigin} {NombreRama}**. En base a esto aprendimos que según la versión de git
que tengamos instalada y/o configuración del mismo, git pone diferentes nombres a las ramas principales, antiguamente utilizaba *master* y ahora *main*.

#### Tip: Cambiar rama por defecto al usar git init

```bash
git config --global init.defaultBranch main
```

Para saber que nombre se utilizó en nuestro caso, utilizamos **git branch**. En ese momento, al crear un repositorio privado, Github abrió una ventana emergente
para que realizamos una autenticación en el navegador, si utilizamos windows el recordará estas credenciales. En el caso de Linux (o si lo queremos hacer en Win)
debemos de generar una clave pública.

[Mas info, aquí](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent)

---

# Repaso del taller anterior:

#### - Nos familizariamos con git como control de versiones, navegando en el historial

Primero, consultamos nuestro historial con **git log**, aprendimos los elementos importantes (Hash,fecha,mensaje,etc), volvimos a una versión anterior de la presentación del taller utilizando 
**git chekout {hash}** y vimos que nos situabamos exactamente en ese instante del tiempo.

Para volver a la versión actual con **git checkout {rama}** y mencionamos la alternativa de **git switch -**.

Hicimos un pequeño cambio en nuestro archivo y con **git diff** pudimos ver que git detectó que el archivo cambió, y sabe exactamente que lineas fuerón modificadas tanto las adiciones como las eliminaciones.

Aprendimos un comando útil y necesario siempre para orientarnos en el estado actual del repositorio **git status**. Extendimos este comando con su versión 'minimalista', **git status -s** y aprendimos
los iconos de los diferentes estados.

### ¿y ahora?

Vamos a aprender a modificar confirmaciones y a trabajar con ramas. Además, dejamos el camino abierto en el aprendizaje y/o uso de git con el **stash** y aplicaciones que dependen de **git**.

---

# Módulo 3: Correción de errores en el proyecto

## 1. Modificar confirmaciones  
## 2. Volver a versiones anteriores 
## 3. Volver a versiones anteriores elimniando el historial.

---

# Módulo 3: Correción de errores en el proyecto

## Modificar mensaje de una confirmación

### git commit --amend

```bash
git commit --amend
```

## Modificar archivos que conforman la confirmación

### git commit --amend

```bash
git add <archivo> 
git commit --amend
```

--
.center[

**¡OJO!** si queremos hacer una modificación con *amend* que ya se encuentra en la nube, al hacer un **push** debemos forzarlo con --force y nuestros compañeros al hacer **pull** un --rebase.

]
---

# Módulo 3: Correción de errores en el proyecto

## Volver a una versión anterior sin dejar rastro

### git reset

```bash
git reset --opcion <id commit>
```

Al ejecutar este comando estamos modificando el historial, si está en github:

#### *¿Qué debemos hacer?*

#### *¿Qué debemos de pedir a nuestros compañeros que hagan?*

#### Tip: Hash relativos

Para no tener que consultar el historial para poder encontrar el identificador de un commit en concreto, podemos retrodecer tantos commits relativos a la ultima confirmación.

```bash
git reset HEAD~n
```

---

# Módulo 3: Correción de errores en el proyecto

## Volver a una versión anterior sin dejar rastro conservando los archivos (o no)

### git reset

#### Borrar definitivamente

En el caso que querramos ademas de volver a un determinado momento de nuestro proyecto y borrar cualquier rastro :

```bash
git reset --hard <hash commit>
```

#### Dejando los archivos en WD

```bash
git reset --mixed <hash commit>
```

#### Dejando los archivos en SA

```bash
git reset --soft <hash commit>
```

---

# Módulo 3: Correción de errores en el proyecto

## Volver a una versión anterior haciendo una confirmación (commit)

### git revert

```bash
git revert <id commit> 
```

#### Tip: revert sin commit inmediatamente

```bash
git revert --no-commit <Hash commit>
```

Una vez que tengamos los archivos en nuestro WD hacemos **add** y **commit** como es habitual.

.center[
Este comando deja todos los archivos en WD y **¡OJO!** todos los archivos que tengamos en WD sin estar en SA se borran.
]

---

# Módulo 3: Correción de errores en el proyecto

## Recuperar confirmaciones

### git reflog

Usar git reset deja huerfanas todas las confirmaciones a su derecha, por un perioodo de 30 días se encontraran en una lista de confirmaciones temporal, para acceder a ella debemos de usar git reflog.

```bash
git reflog
```

#### Tip: Limpiar reflog

```bash
git reflog --delete
```

---

# Parte práctica 3

## 1. Modificar el mensaje del útlimo commit y agregar nueva versión del archivo.

## 2. Deshacer el commit anterior (sin tocar el historial) creando un nuevo cambio que avise que hemos realizado este cambio.

## 3. Borrar definitivamente una confirmación.

---

# Módulo 4: Trabajando con ramas

## 1. Crear ramas 
## 2. Fusionar ramas 
## 3. Problemas de fusión 
## 4. Pull Request's

---

# Módulo 4: Trabajando con ramas

## Concepto de ramas

La razón principal de utilizar ramas es que nos permite obtener diferentes versiones de nuestro trabajo y a su vez tener un seguimiento de estas.

Existen diferentes esquemas de trabajo para el manejo de ramas, como puede ser el de *git flow* una rama principal, una de desarrollo, una de pre-desarollo que de ella se desprenden cada 
una de las features o bugs del software. Esto depende del equipo y el objetivo del proyecto.

<blockquote>
Each branch is like a parallel universe: changes you make in one branch do not affect other branches (until you merge them back together).
</blockquote>

#### Mas sobre git flow

[Git flow](https://nvie.com/posts/a-successful-git-branching-model/)

---

# Módulo 4: Trabajando con ramas

## Crear ramas

### git branch

```bash
git branch <nombre nueva rama>
git checkout -b <nombre nueva rama>
```

## Eliminar ramas

### git branch

```bash
git branch -d <nombre rama> # Si ya se encuentra fuisionada.
git branch -D <nombre rama> # Si no se encuentra fuisionada y queremos forzar su eliminación.
git push <remote> --delete <Rama>
```

---

# Módulo 4: Trabajando con ramas

## Listar ramas

### git branch

```bash
git branch 
git branch -all # También incluye ramas ocultas (remotas)
```

## Hacer seguimiento a una rama remota

### git checkout

```bash
git checkout --track <remote>/<rama>
git checkout -b <nombre rama> <remote>/<rama>
```

---

# Módulo 4: Trabajando con ramas

## Fusionar ramas

### git merge

A pesar de las diferentes ramas pueden convivir de forma independiente, generalmente con el fin de obtener un producto final se fusionan las diferentes ramas.

```bash
git merge <source> <destination> 
```

#### Tip: Fusionar ramas con un único commit

```bash
git merge --squash 
git commit
```

Se puede utilizar el flag -m, pero de esta manera nos perdemos el texto de todas las confirmaciones de los commits.

]

---

# Módulo 4: Trabajando con ramas

## Problemas de fusión

En las fusiones pueden ocurrir conflictos, sin embargo estos se pueden reconocer :

#### 1. Modificar la misma línea de código en las dos ramas
#### 2. Cambios diferentes en ambas ramas pero que no se superponen

git, para solucionar esto tiene diferentes estrategias para fusionar ramas, al utilizar el comando merge se elegirá una de ellas.

#### Información sobre estrategias de fusión

[Estrategias de fusión](https://www.atlassian.com/git/tutorials/using-branches/merge-strategy)

---

# Módulo 4: Trabajando con ramas

## Pull Request's

Los pull request son utilizados en repositorios para establecer cierta formalidad en la implementación e incorporación de la información de la rama de 
desarollo.

GitHub y Gitlab al publicar ramas (diferentes a las principales) la terminal nos brinda un link para hacer efectivo este pull request o desde la 
interfaz web del servicio que estemos utilizando.

Vamos a suponer que la **rama1** ya se encuentra en su versión final y esta lista para incoporarse a la rama principal. Además, supongamos que ya se encuentra abierto un pull request.

---

# Módulo 4: Trabajando con ramas

#### Pasos para aceptar un Pull Request

- Tenemos que actualizar los cambios

```bash
 git fetch <remote>
 ```

- Crear una rama local asociada a la rama remota

```bash
 git checkout --track <rama>
 ```

- Incorporar los cambios de la rama principal.

```bash
 git merge <ramaPrincipal> <ramaDesarrollo> 
 ```

- Solucionar los problemas de fusión

En el caso que existan, utilizar un editor de texto, seleccionar que línea deseamos conservar, y luego hacer un commit.

- Fusionar la rama de desarrollo con la principal

```bash
 git merge <ramaDesarrollo> <ramaPrincipal>
 ```

---

# Parte práctica 4

### 1. Mostrar como se hace un pull request 
### 2. Hacer una copia local de la rama de desarollo 
### 3. Ver el código dentro de ella
### 4. Fusionar la rama principal

---

# Módulo 5: Ignorando archivos

## 1. Crear nuestro gitignore 
## 2. Ver diferentes gitignore
---

# Módulo 5: Ignorando archivos

## Crear nuestro git ignore

Para ignorar un archivo simplemente debemos de crear un archivo en nuestro directorio de
git con el nombre `.gitignore` y dentro de él escribir los archivos que deseamos ignorar.

Se pueden escribir los archivos por su nombre o utilizar expresiones regulares o ingorar carpetas
enteras.

### Ignorar archivos por extensión

```bash
\*.csv # Si se encuentran en la raíz. 
/*.csv # Si se encuentran en cualquier subdirectorio.
```

## Ver ejemplos de gitignore

[Uno de R](https://github.com/github/gitignore/blob/main/R.gitignore)

[Uno de Python](https://github.com/github/gitignore/blob/main/Python.gitignore)

---

# Módulo Extra: Git stash

## 1. Guardar cambios temporalmente 
## 2. Listar cambios guardados temporalmente 
## 3. Aplicar cambios guardados temporalmente 
## 4. Borrar cambios guardados temporalmente 
## 5. Aplicar y borrar cambios guardados temporalmente

---

# Módulo Extra: Git stash

## Guardar cambios temporalmente

### git stash push

```bash
git stash push -m "Breve comentario para recordarlo luego"
```

#### Tip: Uso del stash

Algunos cambios guardados en el stash pueden convertirse en ramas luego y la manera de hacerlo es muy sencillo.

Existen situaciones donde tenemos que migrar a una rama de apuro y tenemos el WD sucio pero con cambios significativos, por ejemplo, o estamos trabajando en una rama y solucionamos un bug
y no nos encontramos en la rama correspondiente.

---

# Módulo Extra: Git stash

## Listar cambios temporales.

### git stash list

No tenemos un límite para añadir información en esta "memoria" por lo que una buena idea es añadirle una buena descripción. También existe una manera de ver el listado de todos
nuestros cambios temporales

```bash
git stash list
```

#### Tip: Referencias a elementos del stash

Con este comando podemos ver que cada uno tiene una referencia del estilo, `stash@{n}`, siendo este el identificador. En el caso de no indicarlo los cambios serán explusados
desde el más nuevo hasta el mas viejo.

---

# Módulo Extra: Git stash

## Aplicar  el último cambio temporal.

### git stash apply

Ahora vamos a traer la información guardada en el stash al WD para poder seguir mejorandolo.

```bash
git stash apply stash@{Número del stash}
```
En el caso de no agregarle el número de stash se agregara por defecto el `stash@{0}`.

## Aplicar el cambio n temporal.

### git stash apply

En el caso de usar PowerShell utilizar comillas para referenciar el stashs, es decir `"stash@{n}"` también se puede utilizar:

```bash
git stash apply n
```

---

# Módulo Extra: Git stash

## Borrar el último cambio temporal.

### git stash drop

Al usar el flag `apply` podemos llevar los cambios temporales del stash al WD pero este permanecerá aún en el stash. Para eliminarlo utilizaremos `drop`

```bash
git stash drop stash@{n} 
```

## Aplicar y borrar el cambio temporal

### git stash pop

```bash
git stash pop
```

---

# Para seguir aprendiendo ...

### git rebase

Nos perimte modificar el historial de nuestros commit's ya sea fusionandolos, cambiarles el órden o eliminarlos.

### git cherry-pick

Nos permite mover commits a diferentes ramas y cambiarles el órden.

### git tag

Podemos poner etiquetas a nuestro código para poder identificarlo, ej : `v1.0.0`.

#### Tip: Etiquetas

Usando el flag -a, podemos crear una etiqueta para cada commit y usando -m podemos indicarle un mensaje :

```bash
git tag -a v1.0.0 -m "Etiqueta para la versión 1.0.0"
```

---

[Disponible aquí](https://git-scm.com/book/en/v2)

]

---

# ¿Preguntas?

# ¡Gracias!