20 Repo, commit, diff, tag
20.1 Repos o repositorios
Git es un sistema de control de versiones cuyo propósito original era ayudar a grupos de desarrolladores a trabajar de forma colaborativa en grandes proyectos de software. Git gestiona la evolución de un conjunto de archivos, llamado repositorio o repo, de una manera altamente estructurada. Históricamente, estos archivos habrían consistido en código fuente e instrucciones sobre cómo crear una aplicación a partir de su fuente.
Git ha sido reutilizado por la comunidad científica de datos (Ram 2013; Bartlett 2016; Perez-Riverol et al. 2016). Lo usamos para gestionar la variada colección de archivos que componen los proyectos típicos de análisis de datos, que consisten en datos, cifras, informes y, sí, algo de código fuente.
Para proyectos nuevos o existentes, le recomendamos que:
- Dedicarle un directorio o carpeta local.
- Conviértalo en un proyecto RStudio. Opcional pero recomendado; obviamente solo se aplica a proyectos que involucran R y usuarios de RStudio.
- Conviértelo en un repositorio Git.
Esta configuración ocurre una vez por proyecto y puede ocurrir al inicio del proyecto o en cualquier momento posterior. Es probable que sus proyectos existentes ya se encuentren en un directorio dedicado. Hacer de dicho directorio un proyecto RStudio y un repositorio Git se reduce a permitir que esas aplicaciones dejen notas en archivos o directorios ocultos. El proyecto sigue siendo un directorio normal en su computadora, que puede ubicar, nombrar, mover y, en general, interactuar con él como desee. ¡No es necesario manipularlo con guantes especiales!
El flujo de trabajo diario probablemente no sea dramáticamente diferente de lo que hace actualmente. Trabaja de la forma habitual, escribiendo scripts R o creando informes en LaTeX o R Markdown. Pero en lugar de guardar únicamente archivos individuales, periódicamente realiza una confirmación, que toma una instantánea de todos los archivos de todo el proyecto. Si alguna vez ha versionado un archivo agregando sus iniciales o la fecha, efectivamente ha realizado una confirmación, aunque solo para una sola archivo. Es una versión que es importante para usted y que quizás desee inspeccionar o volver a consultar más adelante. Periódicamente, envías confirmaciones a GitHub. Esto es como compartir un documento con colegas en DropBox o enviarlo como archivo adjunto de correo electrónico. Al acceder a GitHub, haces que tu trabajo y todo tu progreso acumulado sean accesibles para otros.
Este es un cambio moderado en su flujo de trabajo diario normal. Al principio se siente extraño, pero rápidamente se convierte en algo natural. En STAT 545, los estudiantes deben enviar todos los trabajos del curso a través de GitHub, a partir de la primera semana. La mayoría nunca ha visto Git antes y no se identifican como programadores. Es un tema importante en las horas de clase y de oficina durante las dos primeras semanas. Entonces prácticamente nunca volvemos a hablar de ello.
20.2 Commits, diffs, y tags
Ahora conectamos los conceptos fundamentales de Git con el flujo de trabajo de la ciencia de datos:
- repository
- commit
- diff
Recuerde que un repo o repositorio es solo un directorio de archivos que Git administra de manera integral. Una confirmación(commit) funciona como una instantánea de todos los archivos del repositorio, en un momento específico. En el fondo, no es así exactamente como Git implementa las cosas. Aunque los modelos mentales no tienen que ser precisos para ser útiles, en este caso ayuda alinear ambos.
Figura 20.1 es una mirada a un análisis ficticio de los datos del iris, centrándose en la evolución de un guión, iris.R. Considere la versión A de este archivo y una versión modificada, la versión B. Supongamos que la versión A fue parte de una confirmación de Git y la versión B fue parte de la siguiente confirmación. El conjunto de diferencias entre A y B se llama “diff” y los usuarios de Git contemplan mucho las diferencias. La inspección de diferencias es la forma en que usted se vuelve a explicar en qué se diferencia la versión A de la versión B. La inspección de diferencias no se limita a confirmaciones adyacentes. Puede inspeccionar las diferencias entre dos confirmaciones cualesquiera.
De hecho, la noción de Git de cualquier versión específica de iris.R es una acumulación de diferencias. Si retrocede lo suficiente, encontrará la confirmación donde se creó el archivo en primer lugar. Git almacena cada versión posterior como esa versión inicial, más todas las diferencias intermedias en el historial que afectan el archivo. Dejaremos de lado estos detalles internos ahora, pero comprender la importancia de estos deltas hará que las operaciones de Git sean menos desconcertantes a largo plazo.
Entonces, al observar las diferencias, es fácil ver en qué se diferencian dos instantáneas, pero ¿qué pasa con el por qué?
Cada vez que realiza una confirmación, también debe escribir un mensaje de confirmación breve. Idealmente, esto transmite la motivación para el cambio. Recuerde, la diferencia mostrará el contenido. Cuando vuelves a visitar un proyecto después de un descanso o necesitas digerir los cambios recientes realizados por un colega, mirar el historial, leer los mensajes de confirmación y hojear las diferencias, es una forma extremadamente eficiente de ponerte al día. Figura 20.1 muestra los mensajes asociados con las últimas tres confirmaciones.
Cada confirmación necesita algún tipo de apodo para que puedas identificarla. Git hace esto automáticamente, asignando a cada confirmación lo que se llama un SHA, una cadena aparentemente aleatoria de 40 letras y números (de hecho, no es aleatoria, sino que es un hash de suma de verificación SHA-1 de la confirmación). Aunque estará expuesto a estos, no es necesario que los maneje directamente con mucha frecuencia y, cuando lo hace, normalmente los primeros 7 caracteres son suficientes. Los mensajes de confirmación en Figura 20.1 tienen el prefijo SHA truncado. También puedes designar ciertas instantáneas como especiales con una etiqueta, que es el nombre que elijas. En un proyecto de software, es típico etiquetar una versión con su versión, por ejemplo, “v1.0.3”. Para un manuscrito o proyecto analítico, puede etiquetar la versión enviada a una revista o transmitida a colaboradores externos. Figura 20.1 muestra una etiqueta, “draft-01”, asociada con la última confirmación.