Git y GitHub

Curso R AEET 2026

Author

Elena Quintero

Published

May 5, 2026


¿Por qué resulta útil el control de versiones?

Nos evitan:

  • Sobreescribir archivos
  • Múltiples versiones finales
  • Trabajar por error en versiones no finales
  • Creación de copias “en conflicto” cuando dos personas trabajan a la vez
  • Ediciones sin control de cambios

Nos permiten:

  • Saber quién ha hecho qué y cuándo
  • Llevar un registro de todos los cambios
  • Deshacer cambios
  • Facilitan la colaboración
  • Ediciones sin control de cambios


¿Qué es Git?

Git es un sistema de control de versiones distribuido. Nos permite el seguimiento de cambios en nuestros archivos, colaborar con otras personas y manejar nuestros proyectos de forma más eficiente, permitiendo mantener un historial de cambios.

Características clave de Git:

  • Local: Funciona completamente en tu máquina, no requiere internet para la mayoría de las operaciones.
  • Distribuido: Cada usuario tiene su propio repositorio completo en su máquina, con todo el historial del proyecto y no depende de un servidor central para realizar muchas de las tareas (a diferencia de otros sistema de control).
  • Línea de comandos: Git se usa principalmente a través de comandos en la terminal o consola.

¿Qué es GitHub?

GitHub es una plataforma basada en Git para el alojamiento de proyectos o repositorios, que facilita la colaboración entre personas y ofrece herramientas adicionales como pull requests, issues o acciones automatizadas, entre otras.

Características clave de GitHub:

  • Remoto: Requiere internet para acceder a los repositorios almacenados en la nube.
  • Interfaz gráfica: Proporciona una interfaz gráfica para visualizar y gestionar proyectos. Además existen apps de escritorio.
  • Herramientas para equipos de personas: por ejemplo, revisión de código (pull requests), tareas y seguimiento de errores (issues), integración y automatización de procesos (GitHub Actions).

Excuse me, do you have a moment to talk about version control? - Jennifer Bryan


Instalación y Configuración Inicial

Git se puede operar a través de la terminal (más difícil), a través de Rstudio o a través de la aplicacion “GitHub desktop” (más fácil).

Lo primero es hacerse una cuenta en GitHub.

1. Crear una cuenta en GitHub

https://github.com

Consejos para nombre de usuario

2. Asegurar que R y Rstudio están instalados

Y actualizados!

3a. GitHub Desktop App

Descarga de GitHub Desktop - https://desktop.github.com/download/

Este programa nos instalará Git automáticamente.

3b. GitHub en Rstudio

Para usar Git desde Rstudio hay que (1) instalar Git, (2) hacer que Git local hable con GitHub y (3) asegurarse de que RStudio puede hablar con Git local (y, por tanto, con GitHub). Esto se hará una única vez (por ordernardor).

Guía completa: https://happygitwithr.com

3b.1 Instalación de Git

Primero asegurarse que Git no está ya instalado en nuestro ordenador (en la terminal: which git y git --version y git config --list)

https://happygitwithr.com/install-git - Instrucciones de instalación en diferentes sistemas operativos

https://happygitwithr.com/troubleshooting.html - Resolución de problemas durante la instalación

3b.2. Hacer que Git local hable con GitHub

install.packages("usethis")

library("usethis")

use_git_config(user.name = ”Jane Doe”, user.email = ”jane@example.org”)

3b.3. Crear y guardar Personal Access Token (PAT)

usethis::create_github_token()

Esto abrirá una ventana en la web de GitHub - Hacer click en ‘Generate token’ (botón verde).

Pegar y guardar el PAT:

# install.packages("gitcreds")
# library("gitcreds")
gitcreds::gitcreds_set()


Introducción a GitHub

Perfil e interfaz de GitHub


¿Qué es un repositorio?

Un repositorio es un “contenedor” donde desarrollar un proyecto.

Figure: (Braga et al. 2023)

Un repositorio tiene numerosos apartados:

  • Code - contenido del proyecto
  • Issues - crear y gestionar problemas o tareas
  • Pull requests
  • Discusions
  • Actions
  • Project - tareas y manejo de proyectos
  • Wiki - espacio para documentar proyecto
  • Security
  • Insights - estadísticas del proyecto
  • Settings - configuración
  • Watch/Fork/Star
  • Commit history
  • Contributors

… y más


Nomenclatura de Git

  • Un repositorio es una coleccion de archivos y directorios de un proyecto.
  • Un commit es una snapshot (foto fija) de la historia de un repositorio, i.e. un punto en el tiempo.
  • El desarrollo del proyecto puede llevarse a cabo en varias ramas o branches, permitiendo trabajo en paralelo dentro del mismo repositorio y transicionar entre código funcional y código en desarollo o work-in-progress.
  • Subir los cambios al repositiorio remoto se llama pushing mientras que bajar los cambio se llama pulling.

Flujo de Trabajo Básico con GitHub

  1. Crear un repositorio en GitHub

  2. Clonar un repositorio

  3. Hacer cambios (nuevo fichero) y sincronizar commit

  4. Subir cambios al repositorio remoto git push

  5. Abrir issue en GitHub (e.g. nuevo plot)

  6. Hacer cambios en R y sincronizar de nuevo (commit y git push)

  7. Ver cambios en fichero diff

  8. Hacer cambios en GitHub (e.g. README.md)

  9. Descargar cambios del remoto git pull

  10. Ver commit history del repositorio


Colaboración en GitHub

El historial de un proyecto es como una linea del tiempo de la que podemos generar ramas que trabajen en paralelo y que se pueden unir a la principal.

Image source: https://medium.com/@jacoblogan98/understanding-git-branching-5d01f3dda541

Fork y Pull Request

Hacer un fork es un modo de hacer una copia de un repositorio en tu cuenta para hacer cambios sin afectar el repositorio original. Un fork crea una rama o branch en la que poder trabajar en paralelo a la rama principal.

Una vez estamos seguros que nuestros cambios se pueden unir a la rama principal (master o main) hacemos un pull request - es una solicitud para que los propietarios del repositorio revisen y acepten los cambios.

Trabajar en diferentes ramas (branches) puede facilitar la colaboración y evitar conflictos en la rama principal.

Image source: https://build5nines.com/introduction-to-git-version-control-workflow/


Resolución de conflictos - Merge conflicts

Git puede encontrar conflictos al intentar fusionar dos versiones distintas del mismo archivo. En estos casos que hay que arreglar el conflicto manualmente.

Esto sucede cuando se edita un archivo en local que ha sido modificado en remoto y no se ha hecho un pull primero (por ejemplo por dos usuarios diferentes). Por eso es importante hacer pull antes de empezar a trabajar en un proyecto colaborativo.

Tambien puede suceder cuando dos ramas distintas han modificado las mismas líneas de un archivo.

Aparecerá un mensaje: “Can’t automatically merge”.

Git muestra dónde están los conflictos así:

<<<<<<código remoto=======código local>>>>>>

<<<<<<código del main=======código de la rama a unir>>>>>>

Para resolverlo, debes elegir que cambios conservar o cómo combinarlos según sea necesario. Una vez realizada esta selección, Git permitirá completar la fusión creando un nuevo commit que integre ambas versiones o ramas.

Buenas prácticas para trabajar en GitHub

  • Mantener repositorio ordenado (estructura clara y un archivo README.md)
  • Commits informativos (no sólo “update”)
  • Mensajes de commit claros y cortos
  • Hacer commits pequeños y frecuentes - evitar cambios grandes en un solo commit
  • Uso de .gitignore - ignorar archivos no deseados o muy pesados: e.g. “archivo.log”
  • Uso de issues para:
    • dudas
    • dejar reflejadas decisiones importantes
    • peticiones a otro miembros
    • tareas pendientes
  • Los issues se pueden etiquetar por temas (labels) y asignar a miembros (assignees)
  • Colaboración en ramas cuando se trabaja en el mismo documento o si los cambios necesitan revisión

Recursos Adicionales

Documentación oficial de Git: https://git-scm.com/doc

Documentación oficial de GitHub: https://docs.github.com

Tutorial interactivo: https://learngitbranching.js.org/

Beneficios extra con cuenta de GitHub Education - https://education.github.com/


Manuscritos sobre Git y GitHub:

Astigarraga, Julen, and Verónica Cruz-Alonso. 2022. Se puede entender cómo funcionan Git y GitHub! Ecosistemas 31 (1): 2332–32. https://doi.org/10.7818/ECOS.2332.
Blischak, John D., Emily R. Davenport, and Greg Wilson. 2016. “A Quick Introduction to Version Control with Git and GitHub.” PLOS Computational Biology 12 (1): e1004668. https://doi.org/10.1371/journal.pcbi.1004668.
Braga, Pedro Henrique Pereira, Katherine Hébert, Emma J. Hudgins, Eric R. Scott, Brandon P. M. Edwards, Luna L. Sánchez Reyes, Matthew J. Grainger, et al. 2023. “Not Just for Programmers: How GitHub Can Accelerate Collaborative and Reproducible Research in Ecology and Evolution.” Methods in Ecology and Evolution 14 (6): 1364–80. https://doi.org/10.1111/2041-210X.14108.
Bryan, Jennifer. 2017. “Excuse Me, Do You Have a Moment to Talk about Version Control?” e3159v2. PeerJ Preprints. https://doi.org/10.7287/peerj.preprints.3159v2.
Galeano, Javier. 2018. Por qué usar GitHub? Diez pasos para disfrutar de GitHub y no morir en el intento: Ecosistemas 27 (2): 140–41. https://doi.org/10.7818/ECOS.1604.
Perez-Riverol, Yasset, Laurent Gatto, Rui Wang, Timo Sachsenberg, Julian Uszkoreit, Felipe da Veiga Leprevost, Christian Fufezan, et al. 2016. “Ten Simple Rules for Taking Advantage of Git and GitHub.” PLOS Computational Biology 12 (7): e1004947. https://doi.org/10.1371/journal.pcbi.1004947.
Ram, Karthik. 2013. “Git Can Facilitate Greater Reproducibility and Increased Transparency in Science.” Source Code for Biology and Medicine 8 (1): 7. https://doi.org/10.1186/1751-0473-8-7.

Este documento está basado en:

intro_git-github - Julen Astigarraga y Verónica Cruz https://github.com/DatSciR/intro_git-github

github-workshop - Developing efficient workflows with git & GitHub - Paco Rodríguez https://github.com/Pakillo/github-workshop