Proyectos en RStudio y control de versiones: trabajar sin perderse en archivos

Trabajar con archivos sueltos y versiones duplicadas genera confusión, sobre todo en trabajos colaborativos. Este post introduce el uso de proyectos en RStudio combinados con control de versiones en GitHub y propone un flujo de trabajo más ordenado y reproducible.

Quienes empiezan a trabajar con datos suelen hacerlo a partir de archivos sueltos. Un script que se llama analisis_final.R, luego otro analisis_final_v2.R, después analisis_final_ahora_si.R. Cuando el trabajo avanza, aparecen copias en distintos dispositivos, versiones enviadas por mail y carpetas duplicadas. Si además participan varias personas, la situación se vuelve rápidamente confusa: no queda claro cuál es el archivo más actualizado, qué cambios hizo cada quien o qué versión se usó para obtener un resultado.

Dale, ¿quién no estuvo en esta situación?

Una respuesta habitual a este problema es mover todo a la nube. Servicios como Google Drive o Dropbox permiten que los archivos estén disponibles desde distintos lugares y dispositivos. Esto resuelve parte del inconveniente, porque reduce la circulación de copias desconectadas entre sí. Sin embargo, sigue quedando una pregunta importante abierta: cómo registrar los cambios a lo largo del tiempo, volver atrás si algo sale mal o entender qué se modificó entre una versión y otra de un mismo archivo.

Ahí es donde entra el control de versiones, y en particular plataformas como GitHub¹. El control de versiones permite guardar la historia de un proyecto, registrar cada cambio de manera ordenada y trabajar de forma coordinada sin pisarse el trabajo. GitHub agrega a esto una infraestructura en la nube que facilita compartir proyectos, colaborar y mantener una referencia clara de qué versión es la vigente. En lugar de intercambiar archivos terminados, se trabaja sobre un mismo proyecto, con un registro explícito de su evolución.

En pocas palabras, el funcionamiento de git es el siguiente: tenemos un repositorio (podemos pensarlo como una carpeta alojada en la nube) de la cual nos descargamos una copia en nuestra computadora. Realizamos cambios a ese repositorio, pero mientras no hagamos nada más, la versión que está en la nube (en Github) va a seguir como antes. Una vez que terminamos de trabajar o llegamos a un resultado satisfactorio, “subimos” esos cambios a ese repositorio y el que estaba en la nube se actualiza (y tanto el repositorio en la nube como el que tenemos en nuestra computadora van a ser idénticos).

Distintas personas pueden trabajar con un mismo repositorio y “subir” sus cambios, siempre y cuando esos cambios no entren en conflicto. Cuando esto ocurre (y va a ocurrir, camaradas, inevitablemente), git nos permite saber dónde se da ese conflicto, cuáles fueron las versiones que entraron en conflicto (“hasta la versión 4 estaba todo bien, en la 5 de Pepito ya se pudrió todo”) y nos da la posibilidad de retrotraer los cambios hasta una versión previa (o aceptar a la fuerza los cambios). Lo bueno es que git guarda registro de todo, lo cual nos puede sacar de un apuro más de una vez.

Crear un proyecto de RStudio conectado a GitHub

Rstudio ya trae incorporada una funcionalidad que permite integrar nuestros proyectos con un repositorio de Github. Para combinar RStudio con control de versiones, el punto de partida sigue siendo un proyecto. La diferencia es que ese proyecto estará asociado desde el inicio a un repositorio.

1. Crear un repositorio en GitHub Ingresá a tu cuenta de GitHub y creá un repositorio nuevo, haciendo click en el botón verde que está arriba a la derecha, New.

   

   Elegí un nombre sencillo y marcá la opción de inicializarlo con un archivo README.md. Copiá la URL del repositorio, que la vamos a usar en el siguiente paso.

2. Crear el proyecto desde RStudio En RStudio, andá a File > New Project. Elegí la opción Version Control y luego Git. Pegá la URL del repositorio de GitHub y seleccioná la carpeta local donde querés que se descargue el proyecto. Al aceptar, RStudio crea una carpeta que ya incluye el vínculo con el repositorio.

3. Reconocer el entorno de trabajo Una vez creado el proyecto, vas a notar un panel nuevo en RStudio llamado Git. Desde ahí se pueden ver los archivos modificados, guardar cambios y enviarlos al repositorio remoto. A partir de este momento, todo el trabajo debería hacerse dentro de esta carpeta del proyecto.

4. Guardar y registrar cambios Acá tenés dos formas distintas para subir los cambios: una es a través de la interfaz gráfica integrada en RStudio y la otra es a través de la terminal también integrada a Rstudio. Para la primera versión, tenés que identificar la solapa que dice “Git”, al lado de “Environmente” y de “History”. Cuando editás un script o agregás un archivo, RStudio marca esos cambios en el panel Git. Para subirlos al repositorio, seleccionás los archivos en la columna Staged, hacés click en el botón Commit (aquí escribís un mensaje breve que describa qué hiciste) y confirmás el cambio. Ese registro queda guardado como parte de la historia del proyecto. Finalmente, hacés click en Push y se suben los archivos. La próxima vez que empieces a trabajar, tenés que hacer “Pull” para asegurarte de bajar en tu repositorio local todos los cambios que otras personas (o vos en otro dispositivo) hayan hecho.

   La segunda forma es a través de la terminal, que está al lado de la solapa “Console”. La lógica es la misma: seleccionás los archivos, le agregás un mensaje descriptivo que indique lo que hiciste (el commit) y luego los subís. La diferencia es que lo hacés con comandos:

   git add .
   git commit -m "mensaje descriptivo"
   git push
   
   # la próxima vez que retomes el trabajo
   git pull

   Cada vez que escribís un comando, hacés enter para ejecutarlo. En mi experiencia, es más rápido y sencillo que usar la interfaz gráfica de RStudio, pero es cuestión de gustos.

Este flujo permite trabajar de manera más ordenada y transparente. Cada decisión queda registrada, los errores pueden revertirse y el proyecto se convierte en un espacio compartido con memoria.

Trabajar con proyectos y control de versiones no es solo una cuestión técnica. Es una forma de organizar el trabajo intelectual, de hacerlo más legible y de reducir la fricción cuando se colabora con otras personas. Debemos advertirte que, como dijo el tío Ben, un gran poder viene con una gran responsabilidad, y es normal encontrarse con errores a la hora de usar git (sobre todo si usamos varios dispositivos y nos olvidamos de actualizar los cambios). Existen muchísimos comandos para miles de situaciones y aprietes en los que te podés encontrar, por lo cual te sugiero tener a mano guías como esta o incluso este curso de FreeCodeCamp.

Footnotes

1. Si bien acá vamos a hablar de Github, en rigor de verdad una cosa es Git y otra cosa es Github. git es el sistema de control de versiones que se instala localmente y se encarga de registrar los cambios en los archivos, algo así como la tecnología que permite el seguimiento de los cambios. GitHub, GitLab y plataformas similares son servicios que alojan repositorios git en la nube y agregan herramientas para compartir, colaborar y gestionar proyectos.