_Control de versiones: Git y GitHub

layout: true
class: animated, fadeIn

---
class: inverse, left, middle

# _Control de versiones: Git y GitHub._

Martín Venegas Márquez

***
[Modelos Multinivel - SOC01133/MCS7174 • Primer Semestre 2025]()

<br>

#### Marzo, 2025

---
# Contenidos de la sesión

.left-column[

**¿Qué es el control de versiones?**

1. Definiciones y analogías

**¿Por qué utilizar el control de versiones?**

1. Credibilidad

2. Eficiencia

]

.right-column[

**¿Cómo utilizar el control de versiones?**

1. Git, Github y RStudio

2. Conceptos centrales

3. Aplicando lo aprendido
]
---
class: middle, center, inverse

# _¿Qué es el control de versiones?_

---
# Definiendo el control de versiones

.left-column[
> Un control de versiones es un **sistema** que **registra los cambios** realizados en un archivo o conjunto de archivos a lo largo del **tiempo**, de modo que puedas **recuperar** versiones específicas más adelante ([Git](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones))
]

.right-column[
> Los sistemas de control de versiones son un tipo de **software** que ayuda a hacer un **seguimiento de los cambios** realizados en el código a lo largo del **tiempo**. A medida que un desarrollador edita el código, el sistema de control de versiones toma una [foto] de los archivos. Después, guarda esa [foto] de forma permanente para que se pueda **recuperar** más adelante si es necesario ([Microsoft](https://learn.microsoft.com/es-es/devops/develop/git/what-is-version-control))

]
![:scale 15%](images/git.png)
![:scale 15%](images/microsoft.png)
---

# Definiendo el control de versiones

- ** 💡 Idea principal:** Un sistema que permite llevar un registro de los cambios efectuados a uno o más archivos a través del tiempo.

- Google Docs y Microsoft Word como las formas más conocidas de llevar un registro de cambios: control de cambios e historial de versiones.

- Lo más común: usar el nombre de los archivos para denotar la versión.

![:scale 30%](images/googledocs.png)
![:scale 20%](images/word.png)
---
.center[![](images/versionhistory.png)]

---
.center[![:scale 90%](images/final2.jpg)]
---

.center[
![:scale 45%](images/final.jpg)
]
---
.center[
![:scale 55%](images/exit.jpg)
]
---
class: middle, center, inverse

# _¿Por qué usar el control de versiones?_

---
class: middle, center, inverse

# _Primera razón: credibilidad_

---
# Crisis en la ciencia
.left-column[
* Ha sido entendida como un problema de **transparencia** en:
    * Diseños de investigación 
    * Procedimientos de investigación 
    * Apertura y acceso a materiales de investigación
    
* Dentro de las motivos y consecuencias:

* Problemas para replicar (o reproducir) resultados
    * Confianza en los resultados se pone en duda
]

.right-column[.center[

![:scale 80%](images/crisis.png)

[Baker (2016)](https://www.nature.com/articles/533452a)  
]
]
---
# Crisis en la ciencia
.left-column[
* Ha sido entendida como un problema de **transparencia** en:
    * Diseños de investigación 
    * Procedimientos de investigación 
    * Apertura y acceso a materiales de investigación
    
* Dentro de las motivos y consecuencias:

* Problemas para replicar (o reproducir) resultados
    * **Confianza en los resultados se pone en duda** ❗
]

.right-column[.center[

![:scale 80%](images/crisis.png)

[Baker (2016)](https://www.nature.com/articles/533452a)  
]
]

---
# Prácticas de investigación

* _Fabrication_, _Falsification_, _Plagiarism_ (Invención, Falsificación y Plagio - FPP)
* Prácticas cuestionables de investigación (QRP)
* Conducta Responsable de Investigación (RCR)

.center[
![](images/ffp.png)

Gradación del comportamiento integro en investigación. Imagen de [Steneck (2006).](https://link.springer.com/article/10.1007/PL00022268)]
---
# Caso de fraude: Diderik Stapel

.left-column[
* Prestigioso psicológo social
* 137 artículos publicados
* 54 artículos retractados
* **Motivo:** 
    * Falsificación y manipulación de datos
* **Consecuencias:** 
    * Desvinculado de la Tilburg University
    * Se le rebocó su título de doctorado
]

.right-column[
![](https://0901.static.prezi.com/preview/v2/rh5mrmwhqbzdet7bdbrw4tbijl6jc3sachvcdoaizecfr3dnitcq_3_0.png
)
]

---
# Principios [mertonianos](https://www.panarchy.org/merton/science.html) de la ciencia

- **Universalismo:** La idea de que las afirmaciones científicas deben estar sujetas criterios objetivos preestablecidos e impersonales.

- **Comunalismo:** Los hallazgos de la ciencia son propiedad común de la comunidad científica y el progreso científico depende de la comunicación abierta y el intercambio.

- **Desinterés:** La ciencia debería limitar la influencia del sesgo tanto como sea posible y debería hacerse por el bien de la ciencia, más que por interés propio o poder.

- **Escepticismo organizado:** La necesidad de prueba o verificación somete a la ciencia a más escrutinio que cualquier otro campo.

---
.center[![:scale 85%](images/definitions.jpg)]
---
.center[![](images/reproducible.jpg)]
---
# ¿Cómo avanzamos?

* Prácticas de investigación orientadas a la reproducibilidad:

* Publicación de datos (Dataverse, OSF)
  * Código de análisis abierto (Github, OSF)
  * Uso de software libre y de código abierto (R, Python, Markdown)
  * Protocolos de trabajo reproducible (TIER project)
  * Control de versiones (Git)

.center[

![](https://www.nap.edu/openbook/21915/xhtml/images/img-51-1.jpg)

]
---
# ¿Cómo avanzamos?

* Prácticas de investigación orientadas a la reproducibilidad:

.center[

![](https://www.nap.edu/openbook/21915/xhtml/images/img-51-1.jpg)

]
---
class: middle, center, inverse

# _Segunda razón: eficiencia_

---
# Contexto: proyectos grandes/complejos

.left-column[
- **Trabajo en equipo:** distintas opiniones y formas de trabajar

- **Muchos archivos:** informes, _scripts de código_, presentaciones, tablas etc.
]

.right-column[
- **Muchas decisiones que tomar:** sobre el diseño de investigación, análisis, exploraciones etc.

- **A través del tiempo:** prueba y error, cambios de opinión, reiteración.
]
.center[![:scale 60%](images/decs.png)]

---
## Bowers, J., & Voors, M. (2016)

.center[![:scale 60%](images/paper.png)]
---
# Mejor relación con tu futuro yo

(1) **El análisis de datos es programación**: Codear todo lo que se pueda codear, evitar trabajo manual (_copypaste_) y asi minimizar errores

(2) **Ningún análisis de datos es una isla por mucho tiempo:** No lo hacemos solo nosotros, eventualmente llega a otra persona. Comentar código y documentar.

(3) **El territorio del análisis de datos requiere mapas:** Debemos saber de dónde vienen los datos y qué operaciones se hacen en qué set de datos. Organización de carpetas y nombres de archivos intuitiva.
---
class: inverse

# Mejor relación con tu futuro yo

[(4) **El control de versiones previene el _clobbering_, reconcilia el historial y ayuda a organizar el trabajo: Evitar perdida de información y conflictos** ]()

- Es necesario saber qué versiones de archivos son nuevas, cuáles son viejas y qué ha cambiado entremedio (_track changes_)

- **_Clobbering_:** cuando se elimina trabajo hecho por accidente o cuando se crean duplicados y es necesario revisar al detalle cuál es el original (gastando tiempo y energías)
---
class: middle, center, inverse

# _¿Cómo utilizar el control de versiones?_
---
# Git: un software de control de versiones

> Git es una **herramienta** para el control de versiones que permite **registrar y organizar** los cambios en documentos y datos a lo largo del tiempo. En investigación social, **facilita la colaboración** entre equipos, el rastreo de modificaciones en códigos de análisis o textos académicos, y la reproducción transparente de resultados.

.left-column[
- Es una especie de memoria o registro local que guarda información sobre: qué cambio se hizo, quién lo hizo y cuándo lo hizo.

- Mantiene la información de todos los cambios en la historia de la carpeta/repositorio local.

- Se puede sincronizar con repositorio remoto (ej. Github o Gitlab).
]
.right[![:scale 30%](images/git.png)]

---

# Github: una plataforma colaborativa

> GitHub es una **plataforma** de desarrollo colaborativo basada en Git que permite **alojar repositorios**, gestionar el control de versiones y facilitar la colaboración en proyectos de software y otros tipos de documentos. **Ofrece herramientas** para compartir código, coordinar equipos, hacer revisiones de cambios y automatizar flujos de trabajo.

.left-column[
- Red social de código. Pensada para desarrolladores, pero utilizada por personas de múltiples disciplinas.

- Alberga miles de repositorios públicos. Fomenta el código abierto, la transparencia y la reproducibilidad.

- Guarda la carpeta de trabajo en una "nube".
]
.right[![:scale 30%](images/github.png)]

---
# Git ≠ Github

.left-column[
.center[![:scale 40%](images/git.png)]

.left[✅ Git es un sistema de control de versiones distribuido que se utiliza de manera local (en el propio computador)]
]

.right-column[
.center[![:scale 40%](images/github.png)]

.right[✅ GitHub es un servicio en la nube que permite almacenar repositorios Git y colaborar en ellos con otras personas.]
]

---
# Ejemplo Git

![](images/git-console.png)
---
# Ejemplo Github

![:scale 85%](images/github-page.png)

---
# Git y Rstudio

**¡IMPORTANTE!**

- Git es el software que hace el trabajo de llevar el control de versiones y funciona a través de comandos en consola. Trabajar en él puede ser un poco críptico al principio.

- Es recomendable trabajar con alguna GUI _(Interfaz Gráfica de Usuario)_ para facilitar su uso

- Existen varias GUI para utilizar Git, nosotros utilizaremos las funciones que ofrece Rstudio (algo limitadas, pero cubren gran parte de lo que uno necesita).

![:scale 20%](images/rstudio-logo.png)
![:scale 20%](images/git.png)

---
# Conceptos centrales

## 1. Repositorio _(Repository)_

- Es el espacio donde se almacenan todos los archivos, su historial de cambios y las configuraciones del proyecto. **Puede ser local (en el computador propio) o remoto (en plataformas como Github).**

- En concreto, es equivalente a una carpeta del computador.

- El contenido de la carpeta puede variar dependiendo del alcance del proyecto y de las tareas. Un repositorio puede ser una parte del procesamiento de datos, un paper/informe o un proyecto entero (ej. Fondecyt).

---
# Conceptos centrales

## 1. Repositorio _(Repository)_

### ❗ Primero veremos como inicializar un repositorio local a través de RStudio.

### ⏩ Más adelante, cuando veamos el concepto de _Repositorio remoto_, veremos como inicializar un repositorio conectado a Github.
---
## Inicializar un repositorio local en Rstudio

Project > New project

.center[![:scale 63%](images/rstudio1.png)]
---
## Inicializar un repositorio local en Rstudio

Project > New project > New directory

.center[![:scale 63%](images/rstudio2.png)]
---
## Inicializar un repositorio local en Rstudio

Escoger nombre carpeta, ubicación y activar casilla _Create a git directory_

.center[![:scale 63%](images/rstudioa.png)]
---
## Inicializar un repositorio local en Rstudio

Aparecen botones asociados a Git:

.center[![:scale 63%](images/rstudiob.png)]
---
## (Parentesis: configuración inicial)

La primera vez que utilicemos Git, tenemos que especificar las credenciales. Si no lo hacemos, probablemente las pida más adelante.

Para esto, hay que usar la Terminal. Para acceder a ella en RStudio:

> Tools `\(\rightarrow\)` Terminal `\(\rightarrow\)` New Terminal (`Alt+Shift+R`)

Aquí escribir las credenciales de su cuenta de Github.

```r
git config --global user.email "usuario2021@gmail.com" 
git config --global user.name "nombreusuario"
```
---
# Conceptos centrales

## 2. Confirmaciones _(Commits)_

Cada _commit_ es una "foto" del estado del proyecto en un momento específico. Incluye:

- ✅ Los archivos y cambios realizados.
- ✅ Un identificador único (hash SHA-1).
- ✅ Un mensaje descriptivo sobre el cambio.
---
# Conceptos centrales

## 3. Área de preparación _(Staging Area / Index)_

- Es un espacio intermedio donde seleccionamos los cambios que queremos incluir en el próximo _commit_.

- Se puede pensar como lo que tenemos "arriba del escritorio/escenario" para ser revisado.

`git add archivo.R` → Mueve el archivo al _staging area_.

`git commit -m "Descripción del cambio"` → Guarda los cambios en el historial.

---
## _Stage_ y _Commit_ en Rstudio

Tenemos archivos nuevos o con cambios.

.center[![:scale 63%](images/rstudioc.png)]

---
## _Stage_ y _Commit_ en Rstudio

Al hacer click en _Stage_ lo estamos "subiendo al escenario"

.center[![:scale 63%](images/rstudiod.png)]

---
## _Stage_ y _Commit_ en Rstudio

Al hacer click en _Commit_ se abre una ventana para revisar los cambios e introducir mensaje:

.center[![:scale 63%](images/rstudioe.png)]

---
## _Stage_ y _Commit_ en Rstudio

Al hacer click en _Commit_ se debería ver algo como esto:

.center[![:scale 63%](images/rstudiof.png)]

---
# Conceptos centrales
## 4. Repositorios remotos _(Remotes)_

- El trabajo con un repositorio local es útil para tener un historial propio, pero la funcionalidad más potente de Git es la facilidad que da para la colaboración. 
- Git entrega esta facilidad a través de la sincronización entre repositorios locales y remotos.

- Existen distintas formas de conectar con el repositorio remoto, dependiendo del estado del trabajo. Las principales son:

1. Nuevo proyecto, Github primero
2. Proyecto existente, Github primero
3. Proyecto existente, Github al final

---
# Conceptos centrales
## 4. Repositorios remotos _(Remotes)_

- Existen distintas formas de conectar con el repositorio remoto, dependiendo del estado del trabajo. Las principales son:

1. **Nuevo proyecto, Github primero → ¡Esta es la que veremos aquí!** ✅
2. Proyecto existente, Github primero
3. Proyecto existente, Github al final

---
# Conceptos centrales
## 4. Repositorios remotos _(Remotes)_

- El repositorio remoto es una suerte de nube del cual subimos y bajamos cambios recurrentemente (nuestros o de otros miembros del equipo)

- Los comandos principales son:

`git push` → Enviar cambios al repositorio remoto.

`git pull` → Descargar cambios desde el repositorio remoto.

---
.center[![](images/git-flow.png)]
---
## Crear repositorio remoto desde Github

En Github, ir al perfil propio y hacer click en botón verde "New".

.center[![:scale 80%](images/new_repo.png)]

---
## Crear repositorio remoto desde Github

.left-column[Introducir la información del repositorio:

- _**Repository template:**_ no es necesario por ahora
- _**Repository name:**_ escoger un nombre (sin espacios)
- _**Description:**_ descripción breve del repositorio
- _**Public o Private:**_ público (a menos que haya una razón para dejarlo privado)
- _**Add a README file:**_ marcar casilla
- _**Add .gitignore:**_ R (a menos que se use otro programa)
- _**Choose a license:**_ ninguna

Apretar botón verde "Create repository"
]
.right[![:scale 40%](images/new_repo2.png)]
---
## Crear repositorio remoto desde Github

Así se verá el repo creado:

.center[![:scale 80%](images/new_repo3.png)]
---
## Clonar repositorio remoto

Code > HTTPS > Copiar URL

.center[![:scale 80%](images/clone_repo.png)]
---
## Clonar repositorio remoto

RStudio > New project > Version control

.center[![:scale 63%](images/clone_repo2.png)]

---
## Clonar repositorio remoto

RStudio > New project > Version control > Git > Pegar URL > Create project

.center[![:scale 63%](images/clone_repo3.png)]

---
## Hacer cambios, commit, pull, push

Crear/modificar archivos > _stage_ > _commit_

.center[![:scale 63%](images/clone_repo4.png)]

---
## Hacer cambios, commit, pull, push

Hacer pull (⬇) de los cambios en el remoto. En este caso, todo al día.

.center[![:scale 63%](images/git-pull.png)]

---
## Hacer cambios, commit, pull, push

Hacer push (⬆) de los commits realizados

.center[![:scale 63%](images/clone_repo5.png)]
---
## Hacer cambios, commit, pull, push

Si solicita autorización, entrar a través del navegador con las credenciales Github (o Token).

.center[![:scale 63%](images/clone_repo6.png)]
---
## Hacer cambios, commit, pull, push

Un push exitoso se debería ver asi:

.center[![:scale 63%](images/clone_repo7.png)]

---
# Conceptos centrales
## 5. Ramas _(Branches)_

- Son líneas independientes de desarrollo o análisis que permiten trabajar en nuevas características o exploraciones sin afectar la versión principal.

- Existe la rama principal (_main/master_) y ramas alternativas.

`git branch nueva_rama` → Crea una nueva rama.

`git checkout nueva_rama` → Cambia a la nueva rama.

.right[![](images/branch.png)]
---
![](images/versioncontrol3.png)
---
# Conceptos centrales
## 5. Ramas _(Branches)_

Las ramas se pueden:

- ✅ Crear remoto y luego descargar con un pull (⬇)

- ✅ Crear local y luego subir con un push (⬆)
---
## Rama en remoto y luego pull (⬇)

En Github, hacer click en main, luego escribir nombre de rama y apretar "_Create banch_ [nombre rama] _from main_"

.center[![:scale 63%](images/rama1.png)]

---
## Rama en remoto y luego pull (⬇)

Se verá así:

.center[![:scale 63%](images/rama2.png)]

---
## Rama en remoto y luego pull (⬇)

Ir a RStudio y hacer pull (⬇):

.center[![:scale 63%](images/rama3.png)]

---
## Rama local y hacer push (⬆)

En RStudio, botón morado y escribir nombre rama. En _Remote:_ debe decir _origin_. Click en crear.

.center[![:scale 63%](images/rama4.png)]

---
## Rama local y hacer push (⬆)

Si solicita autorización, utilizar credenciales o token Github.

.center[![:scale 63%](images/rama5.png)]

---
## Rama local y hacer push (⬆)

Se debería ver así:

.center[![:scale 63%](images/rama6.png)]

---
## Rama local y hacer push (⬆)

En Github aparecerá la nueva rama:

.center[![:scale 60%](images/rama7.png)]

---
# Conceptos centrales
## 6. Fusionar cambios _(Merge y Rebase)_

Cuando trabajamos con ramas, necesitamos combinarlas. Hay dos opciones:

`git merge` → Une los cambios de una rama a otra a través de un _commit_.

`git rebase` → Reaplica cambios de una rama sobre otra para mantener un historial más limpio.

💡 **Al comenzar a utilizar Git, es suficiente trabajar con _merge_. En proyectos más complejos puede ser útil el _rebase_.**
---
# Ejemplo de historial (con muchos _merge_)

![](images/ejemplo-enut.png)
---
.center[![:scale 50%](images/gits.jfif)]
---
## Fusionar por _merge_ _(pull request)_ desde Github

En la branch creada (en este caso rama-prueba2) hacer cambios, stage, commit, pull, push.

.center[![:scale 63%](images/merge1.png)]

---
## Fusionar por _merge_ _(pull request)_ desde Github

Ir a Github, hacer click en "Compare & pull request". Esto es para abrir una solicitus de _merge_ entre la _main_ y la _rama-prueba2_.

.center[![:scale 65%](images/merge2.png)]
---
## Fusionar por _merge_ _(pull request)_ desde Github

Añadir información relevante respecto a la solicitud _(pull request)_. Por defecto el título es el nombe del último commit. Hacer click en "Create pull request".

.center[![:scale 58%](images/merge3.png)]

---
## Fusionar por _merge_ _(pull request)_ desde Github

Solicitud creada _(pull request)_. Aqui se puede interactuar con los miembros del equipo, revisar los cambios etc. Para aceptar la solicitud hacer clik en "Merge pull request".

.center[![:scale 48%](images/merge4.png)]

---
## Fusionar por _merge_ _(pull request)_ desde Github

Al aceptar la solicitud se verá así:

.center[![:scale 51%](images/merge5.png)]

---
## Fusionar por _merge_ _(pull request)_ desde Github

Y en Github se verá así:

.center[![:scale 70%](images/merge6.png)]

---
# Conceptos centrales
## 7. Merge conflict

Un merge conflict ocurre cuando Git no puede fusionar automáticamente los cambios de dos ramas porque afectan la misma línea de un archivo de manera diferente. Git necesita ayuda para decidir cuál versión conservar.

.center[![](images/merge-conflict.png)]

---
# Conceptos centrales
## 7. Merge conflict

.center[![](images/merge-conflict1.png)]

---
# Ejemplo de un merge conflict

Supongamos que tenemos una rama _main_ y creamos una nueva rama _experimento_.

1️⃣ En la rama _main_, editamos un archivo y hacemos un commit:

```r
# archivo.txt
Este es un ejemplo de Git.
```

2️⃣ En la rama _experimento_, editamos la misma línea de manera diferente:

```r
# archivo.txt
Este es un ejemplo de control de versiones en Git.
```

---

# Ejemplo de un merge conflict

3️⃣ Intentmos fusionar experimento en _main_:

📢 **¡Conflicto detectado! Git no puede decidir qué versión usar, y el archivo queda así:**

```r
# archivo.txt
<<<<<<< HEAD
Este es un ejemplo de Git.
=======
Este es un ejemplo de control de versiones en Git.
>>>>>>> experimento
```

Los símbolos a continuación se conocen como "marcadores de conflicto":
```
<<<<<<< HEAD
=======
>>>>>>>
```

---

# Cómo resolver un merge conflict
Tenemos que editar el archivo manualmente y decidir qué versión mantener:

✅ Podemos elegir una de las versiones o combinarlas. Es necesario eliminar los marcadores de conflicto.

```r
# archivo.txt
Este es un ejemplo de control de versiones en Git.
```

✅ Luego, hacemos stage y commit:

`git add archivo.txt`

`git commit -m "Resuelto conflicto en archivo.txt"`

💡 **¡Listo!**

---
# Consejos para evitar conflictos

🔹 **Sincronizar antes de editar:** Descargar cambios con pull (⬇) antes de modificar o crear archivos en una rama compartida.

🔹 **Dividir cambios en ramas pequeñas:** Así se reduce la probabilidad de conflictos grandes.

🔹 **Usar herramientas de comparación:** Editores como VS Code o GitKraken ayudan a resolver conflictos visualmente.
---
# Conceptos centrales
## 8. HEAD

En Git, `HEAD` es un puntero especial que señala al commit actual en el que estás trabajando. Es como un marcador que indica en qué parte del historial de versiones te encuentras.

.left-column[

#### Atached state (normal)

![](images/head1.png)

]

.right-column[

#### Detached state

![](images/head2.png)
]
---
## Estados de HEAD

1️⃣ `HEAD` apunta a la última confirmación (commit) de la rama actual

En un flujo normal de trabajo, `HEAD` apunta al último commit de la rama activa.

```r
A - B - C (HEAD -> main)
```

Aquí, `HEAD` está en C, que es el último commit de la rama main.

---

## Estados de HEAD

2️⃣ `HEAD` cambia cuando haces un commit

Si agregas un nuevo commit (D), `HEAD` se moverá automáticamente a él:

`git commit -m "Nuevo commit"`

```r
A - B - C - D (HEAD -> main)
```

---
## Estados de HEAD

3️⃣ `HEAD` en un estado "desasociado" (detached `HEAD`)

Si `HEAD` apunta a un commit en lugar de una rama, estás en un estado desasociado.

`git checkout C`

Ahora `HEAD` apunta directamente al commit C, sin estar en una rama específica:

```r
A - B - C (HEAD) - D (main)
```
❗ **Advertencia: En este estado, si se hacen cambios y commits, estos podrían perderse si no se guardan en una nueva rama.**

Para volver a una rama normal:

`git checkout main`

---
# Conceptos centrales
## 9. Historial y deshacer cambios _(History, revert, reset)_

Git permite inspeccionar el historial y corregir errores.

`git log` → Muestra el historial de commits.

`git revert` → Revierte un commit sin eliminarlo del historial.

`git reset` → Borra commits o deshace cambios en el área de preparación.

💡**RStudio no tiene botones asociados al _revert_ y el _reset_, por lo que se debe hacer en la Terminal (o cambiarse a otra GUI).**

---
## Revert v/s reset
.center[![:scale 48%](images/rev.svg)]
---
## Git revert

1️⃣ git revert (forma segura)

Imaginemos que tenemos el siguiente historial de commits:

```r
A - B - C - D (HEAD)
```

Si queremos revertir el commit C, usamos:

`git revert C`

Esto creará un nuevo commit E que revierte los cambios de C sin alterar el historial:

```r
A - B - C - D - E (HEAD)
```
💡 **Útil cuando se trabaja en equipo y no se quiere borrar commits del historial.**
---
## Git reset

2️⃣ git reset (modifica el historial)

Tenemos:

```r
A - B - C - D (HEAD)
```

Si queremos eliminar los commits C y D, usamos:

`git reset --hard B`

Esto mueve HEAD a B, eliminando los commits C y D:

```r
A - B (HEAD)
```

❗ **Cuidado: `--hard` borra definitivamente los cambios. No se pueden recuperar fácilmente.**
---
## Tipos de reset

| Tipo | ¿Modifica el historial? | ¿Preserva cambios en el área de staging (`git add`)? | ¿Preserva cambios en el directorio de trabajo? |
|------|------------------------|-----------------------------------|----------------------------|
| **`--soft`** | ✅ Sí | ✅ Sí | ✅ Sí |
| **`--mixed`** (por defecto) | ✅ Sí | ❌ No (deshace `git add`) | ✅ Sí |
| **`--hard`** | ✅ Sí | ❌ No | ❌ No |

---
## ¿Cuándo usar cada uno?

| Tipo de `git reset` | ¿Qué hace? | ¿Cuándo usarlo? | ¿Se puede en un repo compartido? |
|---------------------|------------|----------------|----------------------------------|
| **`--soft`**  | Retrocede un commit pero mantiene cambios en staging y el directorio de trabajo. | Cuando solo quieres modificar el último commit sin perder los cambios. | ✅ Sí, si no has hecho `push`. |
| **`--mixed`** (por defecto) | Retrocede un commit y quita los cambios de staging, pero los mantiene en el directorio de trabajo. | Si agregaste archivos con `git add` por error y quieres corregir antes de hacer commit. | ✅ Sí, si no has hecho `push`. |
| **`--hard`** | Retrocede un commit y borra los cambios del directorio de trabajo y staging. | Si quieres descartar completamente los cambios sin recuperarlos. | ❌ No, podría causar conflictos si ya hiciste `push`. |

---

# Aplicando lo aprendido
## Parte I: creando un repositorio local

1. ⬜ En Rstudio, crear un repositorio local con el nombre "taller-git-local".
2. ⬜ Crear archivo que se llame "archivo_prueba.R" y escribir un comentario en él.
3. ⬜ Añadir los cambios al _stage area_.
4. ⬜ Hacer commit de los cambios.

---

# Aplicando lo aprendido
## Parte I: creando un repositorio local

1. ✅ En Rstudio, crear un repositorio local con el nombre "taller-git-local".
2. ✅ Crear archivo que se llame "archivo_prueba.R" y escribir un comentario en él.
3. ✅ Añadir los cambios al _stage area_.
4. ✅ Hacer commit de los cambios.

---

# Aplicando lo aprendido
## Parte II: remoto

1. ⬜ En Github, crear un repositorio remoto con el nombre "taller-git-remoto".
2. ⬜ Copiar el URL HTTPS del repositorio.
3. ⬜ En RStudio, clonar el repositorio remoto via HTTPS.
4. ⬜ Crear un archivo que se llamo "archivo_prueba.R" y escribir un comentario en él.
5. ⬜ Añadir los cambios en el _stage area_.
6. ⬜ Hacer commit de los cambios.
7. ⬜ Hacer pull.
8. ⬜ Hacer push.
9. ⬜ En Github, revisar los cambios.

---

# Aplicando lo aprendido
## Parte II: remoto

1. ✅ En Github, crear un repositorio remoto con el nombre "taller-git-remoto".
2. ✅ Copiar el URL HTTPS del repositorio.
3. ✅ En RStudio, clonar el repositorio remoto via HTTPS.
4. ✅ Crear un archivo que se llamo "archivo_prueba.R" y escribir un comentario en él.
5. ✅ Añadir los cambios en el _stage area_.
6. ✅ Hacer commit de los cambios.
7. ✅ Hacer pull.
8. ✅ Hacer push.
9. ✅ En Github, revisar los cambios.

---

# Aplicando lo aprendido
## Parte III: branches

1. ⬜ En Github, crear una branch llamada "branch1" desde el remoto.
2. ⬜ En Rstudio, hacer pull de "branch1".
3. ⬜ En Rstudio, crear una branch llamada "branch2" conectada con el remoto.
4. ⬜ En Github, revisar que existan las branches: main, branch1 y branch2.

---

# Aplicando lo aprendido
## Parte III: branches

1. ✅ En Github, crear una branch llamada "branch1" desde el remoto.
2. ✅ En Rstudio, hacer pull de "branch1".
3. ✅ En Rstudio, crear una branch llamada "branch2" conectada con el remoto.
4. ✅ En Github, revisar que existan las branches: main, branch1 y branch2.

---

# Aplicando lo aprendido
## Parte IV: merge (pull request)

1. ⬜ En RStudio, ir a "branch2".
2. ⬜ Crear un archivo "nuevo_archivo2.R" y añadir un comentario.
3. ⬜ Hacer stage, commit, pull, push.
4. ⬜ En Github, crear solicitud de pull request.
5. ⬜ Aceptar solicitud de pull request.
6. ⬜ Revisar main que los cambios se hayan incorporado correctamente.

---

# Aplicando lo aprendido
## Parte IV: merge (pull request)

1. ✅ En RStudio, ir a "branch2".
2. ✅ Crear un archivo "nuevo_archivo2.R" y añadir un comentario.
3. ✅ Hacer stage, commit, pull, push.
4. ✅ En Github, crear solicitud de pull request.
5. ✅ Aceptar solicitud de pull request.
6. ✅ Revisar main que los cambios se hayan incorporado correctamente.

---
## Bonus I: merge conflict

1. ⬜ En RStudio, asegúrate de estar en la rama _main_. Luego, anda a "nuevo_archivo.R" y escribe el siguiente comentario en la primera linea de código: "Esto es un comentario desde la main".
2. ⬜ Hace stage, commit, pull, push.
3. ⬜ En RStudio, ve la branch1 (también puedes hacerlo desde la terminal con `git checkout branch1`). En el archivo "nuevo_archivo.R" escribe el siguiente comentario en la primera linea de código: "Esto es un comentario desde la branch1".
4. ⬜ Hace stage, commit, pull, push.
5. ⬜ En Rstudio, ve a la branch main (también puedes hacerlo desde la terminal con `git checkout main`).
6. ⬜ En la Terminal, escribe `git merge branch1`.
7. ⬜ Resuelve manualmente el conflicto en el archivo "nuevo archivo.R".
8. ⬜ En la Terminal, escribe `git add nuevo_archivo.R`, luego `git commit -m "Resolver conflicto` y finalmente `git push`.
---
## Bonus I: merge conflict

1. ✅ En RStudio, asegúrate de estar en la rama _main_. Luego, anda a "nuevo_archivo.R" y escribe el siguiente comentario en la primera linea de código: "Esto es un comentario desde la main".
2. ✅ Hace stage, commit, pull, push.
3. ✅ En RStudio, ve la branch1 (también puedes hacerlo desde la terminal con `git checkout branch1`). En el archivo "nuevo_archivo.R" escribe el siguiente comentario en la primera linea de código: "Esto es un comentario desde la branch1".
4. ✅ Hace stage, commit, pull, push.
5. ✅ En Rstudio, ve a la branch main (también puedes hacerlo desde la terminal con `git checkout main`).
6. ✅ En la Terminal, escribe `git merge branch1`.
7. ✅ Resuelve manualmente el conflicto en el archivo "nuevo archivo.R".
8. ✅ En la Terminal, escribe `git add nuevo_archivo.R`, luego `git commit -m "Resolver conflicto` y finalmente `git push`.

---

## Bonus II: revert

1. ⬜ En Rstudio, en la main, crea un nuevo script de código y escribe un comentario en él.
2. ⬜ Hace stage, commit, pull y push.
3. ⬜ En la Terminal, escribe `git revert HEAD`. 
4. ⬜ Se abrirá el editor de mensaje en la Terminal. Tecla Esc > Escribir :wq y luego tecla Enter.
5. ⬜ En la Terminal, escribe `git push`.
6. ⬜ Ve a Github a revisar el commit de reversión.

---

## Bonus II: revert

1. ✅ En Rstudio, en la main, crea un nuevo script de código y escribe un comentario en él.
2. ✅ Hace stage, commit, pull y push.
3. ✅ En la Terminal, escribe `git revert HEAD`. 
4. ✅ Se abrirá el editor de mensaje en la Terminal. Tecla Esc > Escribir :wq y luego tecla Enter.
5. ✅ En la Terminal, escribe `git push`.
6. ✅ Ve a Github a revisar el commit de reversión.

---

# Recursos

## Más sobre ciencia abierta...

- Curso JC Castillo  ["Ciencia Social Abierta" 2021"](https://cienciasocialabierta.netlify.app/)
- Página web ["Laboratorio Ciencia Social Abierta" (LISA)](https://lisa-coes.netlify.app/)
- Escuela Invierno ELSOC 2024: [Investigación Reproducible](https://www.youtube.com/watch?v=-pPmtz29vZ8)

## Más sobre Git...

- Clase INE ["Git para usuarios de R"](https://www.youtube.com/watch?v=S-PzhB_-FKc)
- Libro ["Happy Git for the useR"](https://happygitwithr.com/) (inglés)
- [Tutorial interactivo Git](https://learngitbranching.js.org/) (inglés)
- [Git Cheatsheet](https://education.github.com/git-cheat-sheet-education.pdf) (inglés)
---
class: middle, center, inverse

### ¡Muchas gracias!