5  git para trabajar individualmente

5.1 Objetivos de aprendizaje

• Identificar por qué el control de versiones, específicamente Git, es importante para el desarrollo de software y análisis de datos.
• Diferenciar métodos para trabajar con Git y R: integración con RStudio
• Aplicar el proceso de modificación-add-commit como el flujo de trabajo de Git para el seguimiento de los cambios y ver el historial de commits de un repositorio.
• Publicar repositorios en GitHub y coordinar versiones remotas y locales

5.2 ¿Por qué git?

¿Tenés algo así en tu computadora?

/home/pao/Documents/Clases/progrmacion
├── script.R
├── tp.Rmd
├── tp_corregido.Rmd
├── tp_corregido2.Rmd
├── tp_final.Rmd
├── tp_finalfinal.Rmd
├── este_es_el_final.Rmd
├── juro_que_esta_es_la_ultima_version_del_tp.Rmd
└── FINAL.Rmd

Probablemente todos lo tenemos, o tuvimos algo así en algún momento, porque necesitamos guardar nuestro trabajo pero seguir teniendo acceso a versiones anteriores. Existe una solución para esto. Los sistemas de control de versiones gestionan la evolución y los cambios de un conjunto de archivos que llamaremos repositorio. Si alguna vez has mirado el historial de un archivo de Google Docs, es así pero de una forma muy controlada. Git es un sistema de control de versiones muy popular, pero hay otros.

Si trabajas de manera individual, git es estupendo para hacer un seguimiento de los cambios y recuperar versiones anteriores de tus archivos. También puedes utilizar repositorio remoto (que veremos más adelante) para tener una copia de seguridad y compartir tu trabajo.

Si trabajas en equipo, podés aprovechar todo lo anterior y utilizar también el control de versiones como herramienta para colaborar y organizar las distintas versiones de un mismo archivo presentes en las múltiples computadoras que vos y las otras personas usen.

5.3 Pero, ¿qué entendemos por control de versiones?

Imaginemos que tenemos un repositorio funcionando (más adelante veremos cómo crear uno). Cuando creas un nuevo archivo como parte del repositorio (o repo), ese archivo no es trackeado o no está versionado. Esto significa que git ignorará el archivo y cualquier cambio que hayas hecho hasta que lo agregues al repositorio (add en inglés) y empieces a registrar sus cambios. En ese momento el archivo está en el area staging (en el escenario de git) y está listo para entrar en el repositorio. Para eso hay que confirmar (commit en inglés) esa versión del archivo en el repositorio. Este flujo de trabajo modify --> add --> commit se repetirá cada vez que quieras guardar una versión del archivo. No recomendamos hacer un commit cada vez que guardes el archivo o cambies una coma, y tampoco es buena idea hacer un commit con mil millones de cambios. Con la práctica y dependiendo de cómo trabajes, encontrarás un punto medio cómodo.

La figura muestra el ciclo de cambios en un archivo: versionado o sin versional. Cuando es versionado y forma parte del repositorio, las acciones son add, commit, y modificar. Con la acción add, el archivo se “prepara”; con la acción de commit, el archivo se “guarda” en el repositorio. Este ciclo se repite cada vez que se modifica el archivo.

Estas acciones son add y commit son comandos de git. Si tenes experiencia trabajando con la terminal podés utilizar git desde ahí, pero los mismos comandos pueden ejecutarse desde una GUI como GitHub Desktop o GitKraken. Durante este curso utilizaremos RStudio.

5.4 ¿Ya mencionamos “repositorio remoto”?

Antes revisamos el flujo de trabajo local. El repositorio (una carpeta oculta llamada .git) vive en tu computadora y con eso ya estas usando control de versiones. Pero, también podrías conectar el repositorio local con un repositorio remoto. En este curso vamos a utilizar GitHub para alojar repositorios remotos, pero hay otras opciones que podrías explorar, como GitLab.

Imaginemos que tenemos un repositorio local, hicimos cambios en un archivo y luego commits para guardar esa nueva versión. Ahora necesitamos enviar esos cambios al repositorio remoto (más adelante veremos cómo crear el repositorio remoto). Para ello empujamos (push en inglés) los commits al repositorio remoto y entonces, los dos repositorios están “actualizados”, tienen la misma versión de los archivos.

Luego, otra persona de tu equipo hace un cambio en un archivo en su repositorio local y lo sube al repositorio remoto. Ahora, tu repositorio local está “desactualizado” y necesitas descargar esos nuevos commits del repositorio remoto a tu computadora. Necesitas hacer pull.

Modelo conceptual de un flujo de trabajo utilizando proyectos RStudio y git. Los archivos se añaden al área de preparación y luego se envían al repositorio local. Puedes enviar commits al repositorio remoto y bajar nuevos commits a tu computadora.

Herramientas como GitHub también incluyen funciones que te ayudan a colaborar y gestionar repositorios. Por ejemplo, puedes modificar archivos y hacer commits con esos cambios utilizando la interfaz web.

5.5 Preséntate con Git

Antes de crear tu primer repositorio tenes que asegurarte de que git y RStudio entienden y de que git te conoce. Si seguiste las instrucciones instrucciones previas al curso seguro que RStudio, git y GitHub se hablan entre sí.

Podés comprobar que RStudio “sabe” donde está git yendo a Tools --> Global Options --> Git/SVN. Allí deberías encontrar la ruta en tu computadora a la instalación de git.

Para presentarte con git, es decir, para que reconozca tu nombre y correo electrónico, puedes utilizar el comando usethis paquete.

library(usethis) 
use_git_config(user.name = "Juan Perez",
               user.email = "juan@ejemplo.org")

Sustituyéndolo por tu nombre y el correo electrónico asociado a tu cuenta de GitHub.

5.6 Creando un nuevo repositorio

Hay muchas formas de iniciar un nuevo repositorio, localmente en tu computadora utilizando la Termianl, desde GitHub (o sus amigos) ¡o desde RStudio! Aca te mostraremos cómo crear un repositorio desde GitHub, asociarlo a un proyecto de RStudio y trabajar con él. Pero tené en cuenta que hay muchas otras formas de trabajar con git.

1. Creá un repositorio online.

• Entrá en github.com e inicia sesión.
• En la esquina superior derecha, hacé click en el botón “+” y luego en “New repository”.

A continuación completá la información del repositorio:

• Repository template: No template.
• Repository name: como quieras llamar a tu nuevo proyecto.
• Description: Una descripción breve del proyecto. Escribila para los humanos.
• Visibilidad: Public.
• Initialize this repository with: nada (podemos configurarlo todo desde R).

Antes de volver a RStudio, copia la url del repositorio. Por ejemplo https://github.com/paocorrales/myrepo.git

2. En RStudio, inicia un nuevo Proyecto:

• File > New Project > Version Control > Git. En la “URL del repositorio” pegá la URL de tu nuevo repositorio de GitHub, tiene que tener esta pinta: https://github.com/paocorrales/myrepo.git.
• Elejí la carpeta donde querés crear el proyecto.
• Elejí “Open in new sesion”.
• Y haz clic en “Create project”.

La nueva carpeta en tu computadora será un repositorio git, vinculado a un repositorio remoto de GitHub y un proyecto de RStudio al mismo tiempo. Este flujo de trabajo también se asegura de que toda la configuración entre los repositorios local y remoto se realice correctamente.

También agrema un archivo llamado .gitignore que incluye una lista de archivos que no queremos sumar al repositorio (por ejemplo .Rhistory).

5.7 Cambios locales

Es hora de poner en práctica algunas de las cosas de las que hemos estado hablando.

Add, commit

1. Creá un nuevo archivo RMarkdown y guardalo.
2. Agregalo al área de preparación con add y luego hace un commit. ¡Vas a tener que pensar un mensaje descriptivo!
3. Hace un cambio en el archivo, puede ser cualquier cosa. Guardalo.
4. Repetí el paso 2.

Panel Git con 3 archivos sin seguimiento.

Panel Git con 3 archivos con seguimiento añadidos al área de preparación.

Interfaz RStudio para ver las diferencias entre archivos, escribir el mensaje para el commit y enviarlo al repositorio remoto.

Si todo salió bien, empezaste a rastrear archivos, hiciste cambios y commits para guardar esa versión en el repositorio local. Puede que veas un mensaje en la pestaña de git diciendo que el repositorio local “is ahead of ’origin/master` by 2 commits”. No verás ningún cambio en GitHub hasta que hagas push y envíes esos commits al repositorio remoto. Podés hacer esto al final del día si preferis, pero si trabajas con otras personas puede ser una buena idea hacer push luego de cada commit.

¡Push!

1. Ahora, hacé push para enviar los commits al repositorio remoto utilizando el botón con la flecha verde apuntando hacia arriba.

5.8 Cambios remotos

Volvamos a GitHub. Si actualizas la página, ahora verás los archivos que acabas sumar al repositorio o modificar. Hagamos click en “Commits” para ver la historia del repositorio. Desde esta página, podés explorar el repositorio en el “estado” en el que estaba con cada commit y ver las diferencias entre las distintas versiones.

Ahora, podemos intentar hacer cambios aquí.

Crear un README

1. En la página principal, hacé click en el botón verde que dice “Add a README”.
2. Agregá algo en archivo. Los README suelen estar escritos en Markdown y contienen información sobre el repositorio.
3. Al final de la página añadí un mensaje hacé click en “Confirm changes…”.
4. Volvé a la página principal para ver el README.

El nuevo archivo y los cambios que hagas en GitHub sólo estarán en el repositorio remoto hasta que hagas un pull en el repositorio local. Si realizas cambios en el repositorio local mientras no está actualizado, podés encontrarte con conflictos cuando intentes unir las 2 versiones, lo que suele generar dolores de cabeza. Esto ocurre cuando la versión de un archivo en el repositorio local no es compatible con su versión en el repositorio remoto. En esos casos, git no puede decidir qué versión es la correcta y tenés que hacerlo vos.

Para evitar este problema (lo más posible), tenes que hacer un pull antes de empezar a hacer cualquier otra cosa. La mayoría de las veces RStudio mostrará el mensaje “Already up to date”, pero es bueno hacerlo un hábito.

Pull desde GitHub

1. Volvé a RStudio.
2. Revisá panel de Git.
3. Hacé click en la flecha azul que dice “Pull”.
4. Revisá el archivo README en la pestaña Archivos.

5.9 Anatomía de un repositorio de GitHub

• Archivos README. Utilizá un README.md para explicar de que se trata es tu proyecto y cómo utilizarlo. README.md es el archivo que se muestra automáticamente cuando abrís un repositorio de GitHub.

• Licencia. La licencia le indica a las personas cómo puede utilizar el contenido de tu repositorio. Generalmente, utilizamos licencias permisivas para que las personas pueda utilizar los materiales de cualquier manera. Algunos ejemplos son la Licencia MIT o Apache. Podés revisar algunos recursos extra:

  • Elejí una licencia para proyectos de código.
  • Licencias de software en lenguaje sencillo: explica la jerga legal de las licencias en términos sencillos

• Guía para colaborar. Un archivo llamado CONTRIBUTING.md que incluye las instrucciones que personas que quieren conlaborar en tu proyecto sepan lo que deben hacer si quieren ayudarte.

• Código de conducta. Los buenos proyectos tienen códigos de conducta para garantizar un ambiente amigable donde las personas puede colaborar. Github tiene atajos para agregar Código de Conducta facilmente.

• Issues. Te permiten gestionar el proyecto, discutir problemas y mejoras con otras personas.

Para practicar git y de paso lo que estuvimos viendo sobre manipulación de datos vamos a usar GitHub Classroom.

¿Cómo funciona?

Preparamos repositorios con distintos ejercicios para que resuelvan. Cada persona tendrá su repositorio para trabajar de manera individual, aunque siempre pueden resolver los ejercicios en gruupos (pequeños!)

En el campus encontrarás las instrucciones para acceder a tu repositorio.