1 ¿Por qué Git? ¿Por qué GitHub?

¿Por qué un analista de datos usaría un sistema de control de versiones alojado?

Esta introducción se ha convertido en un artículo independiente que podría decirse que es una mejor introducción en este momento. Hasta que vuelva a fusionarlo, considere leer el artículo en su lugar: “Excuse me, do you have a moment to talk about version control?” https://dx.doi.org/10.7287%2Fpeerj.preprints.3159v2.

1.1 ¿Por qué Git?

Git es un sistema de control de versiones. Su propósito inicial era ayudar a grupos de desarrolladores a trabajar colaborativamente en grandes proyectos de software. Git gestiona la evolución de un conjunto de archivos - llamado repositorio - de una manera sencilla y altamente estructurada. Si no tiene ni idea de lo que se está hablando, piense en ello como las características de “Control de Cambios” de Microsoft Word pero con esteroides.

Git ha sido re-propuesto por la comunidad de ciencia de datos. Además de usarlo para el código fuente, se utiliza para administrar la colección heterogénea de archivos que conforman los típicos proyectos analíticos de datos, que a menudo consisten en datos, figuras, informes y, también, código fuente.

Un analista de datos en solitario, trabajando en un solo computador, se beneficiará de la adopción del control de versiones. Pero no lo suficiente como para justificar el dolor de instalación y los trastornos del flujo de trabajo. Hay maneras mucho más fáciles de obtener copias de seguridad versionadas de sus archivos, si eso es todo lo que le preocupa.

En la opinión del autor, para los nuevos usuarios, las ventajas de Git sólo superan a las desventajas cuando se interactúa en la comunicación y la colaboración con otras personas. ¿Quién no necesita hacer eso? La vida es mucho más fácil si se interactúa en un flujo de trabajo, en lugar de ser un proceso separado que se descuida.

1.2 ¿Por qué GitHub?

Aquí es donde entran los servicios de hosting como GitHub, Bitbucket y GitLab. Estos proporcionan un hogar para sus proyectos basados en Git en Internet. Si no tiene idea de lo que se está hablando, piense en esto como si fuera DropBox pero mucho, mucho mejor. El host remoto actúa como un canal de distribución o un centro de intercambio de información para su proyecto gestionado por Git. Esto le permite a otras personas ver sus cosas, sincronizarse con usted, e incluso hacer cambios. Estos proveedores de hosting mejoran los servidores Unix Git tradicionales con interfaces web bien diseñadas.

Incluso para proyectos en solitario, es una buena idea subir su trabajo a un lugar remoto por tranquilidad. ¿Por qué? Porque es bastante fácil arruinar su repositorio local de Git, especialmente cuando se es nuevo en esto. La buena noticia es que muy pocas veces la infraestructura de Git colapsa. ¡Sus archivos están bien! Lo que hace que sus problemas con Git sean aún más frustrantes. Existen soluciones oficiales de Git para estos problemas, pero pueden requerir experiencia y paciencia a los que no puede acceder en una situación de urgencia manifiesta. Si recientemente ha subido su trabajo a GitHub, es fácil acceder a una copia nueva, arreglar las cosas con los cambios que sólo existen localmente y seguir adelante con su proyecto.

Se hará énfasis en GitHub – no en Bitbucket o GitLab – en aras de la especificidad. Sin embargo, todos los grandes principios e incluso algunos asuntos mecánicos se trasladarán a estas plataformas de alojamiento alternativo.

No se discute demasiado frente a la controversia entre qué debe ser público frente a lo privado en este punto. Hay muchas maneras de obtener repositorios privados de los principales proveedores de bajo o ningún costo. ¡Sólo empiece y decida si Git/GitHub va a trabajar para usted y cómo va a hacerlo! Si supera este asunto, puede obtener algunos conocimientos técnicos y ahorrar dinero arreglando el problema. Usted puede pagar por un nivel de servicio superior o auto-hospedar en una de estas plataformas.

1.3 ¿Dolerá?

Sí.

Tiene que instalar Git, comunicar el Git local con GitHub, y asegurarse de que RStudio pueda comunicarse con el Git local (y, por ende, con GitHub). Este es un dolor de una sola vez o una vez por computadora.

Para proyectos nuevos o existentes, usted deberá:

• Dedicarle un directorio (mejor dicho, una “carpeta”).
• Hacerle un proyecto en RStudio.
• Hacerle un repositorio de Git.
• Hacer las cosas normalmente. Pero en lugar de sólo guardar periódicamente archivos individuales, realizar un commit, el cual toma una foto instantánea de varios archivos de todo el proyecto.
  • ¿Alguna vez ha versionado un archivo añadiendo sus iniciales o la fecha? Eso es efectivamente un commit, aunque sólo sea para un solo archivo: es una versión que es importante para usted y que puede ser que desee inspeccionar o volver a ver más adelante.
• Subir commits a GitHub periodicamente.
  • Esto es como compartir un documento con colegas en DropBox o enviarlo como un archivo adjunto de correo electrónico. Esto señala que está listo para hacer que su trabajo sea visible a los demás e invita a otras personas a realizar comentarios o ediciones.

Este es un cambio en el flujo de trabajo normal y diario. Se siente raro al principio, pero rápidamente se convierte en una segunda naturaleza. Por si sirve de algo, los estudiantes de STAT 545 están obligados a presentar todos las tareas a través de GitHub. Este es un tema importante en las horas de clase y de atención docente durante las primeras dos semanas. Después de eso, prácticamente nunca se discute de nuevo

Más malas noticias. El dolor en STAT 545 es de corta duración porque los estudiantes trabajan principalmente en sus propios repositorios. ¿Utiliza GitHub para trabajar con otras personas o para coordinar su propio trabajo desde múltiples computadoras? Si es así, después de recuperarse de la configuración inicial, Git lo aplastará de nuevo con merge conflicts. Y este no es un dolor de una sola vez, esto podría ser como un dolor de oído durante mucho tiempo. El mejor remedio es la prevención, pero también la comprensión de cómo salir de situaciones difíciles y abordarlas en sus propios términos.

El resto de este sitio está dedicado a caminar a través de la configuración necesaria y la creación de sus primeros proyectos Git. Se concluye con instrucciones que le guiarán a través de algunos de los usos más avanzados que hacen que todo este dolor inicial valga la pena.

1.4 ¿Cuál es la recompensa?

Exposición: Si alguien necesita ver su trabajo o si quiere que prueben su código, pueden obtenerlo fácilmente desde GitHub. Si utilizan Git, pueden clonar o hacer fork a su repositorio. Si no utilizan Git, de todas formas pueden navegar por su proyecto en GitHub como en un sitio web normal e incluso obtener todo descargando un archivo zip.

¡Estar más atento! Si se preocupa profundamente por el proyecto de otra persona, como por ejemplo un paquete de R que utiliza con mucha frecuencia, puede seguir su desarrollo en GitHub. Puede ver el repositorio para recibir notificaciones de la actividad principal. Puede hacerle fork para guardar su propia copia. Puede modificar su fork para agregar características o corregir errores y enviarlos de vuelta al propietario como un cambio propuesto.

Colaboración: Si necesita colaborar en el análisis de datos o en el desarrollo de código, todos deberían usar Git. Utilice GitHub como su centro de distribución: las personas trabajan de forma independiente, luego envían el trabajo a GitHub para la concatenación y transmisión al resto del equipo. La ventaja de Git/GitHub se resalta comparando estas dos maneras de colaborar en un documento:

• Editar, guardar, adjuntar En este flujo de trabajo, todo el mundo tiene una (¡o más!) copias del documento y circulan a través de archivos adjuntos de correo electrónico. ¿Cuál es el documento “maestro”? ¿Es posible opinar? ¿Cómo se relacionan entre sí las diferentes versiones? ¿Cómo se deben concatenar las versiones? Si quiere ver la mejor versión actual, ¿cómo la consigue? Todo esto, por lo general, se resuelve por acuerdos grupales y mediante un proceso bastante manual.
• Documento de Google En este flujo de trabajo, sólo hay una copia del documento y vive en la nube. Cualquiera puede acceder a la versión más reciente bajo demanda. Cualquier persona puede editar o comentar o proponer un cambio y esto está inmediatamente disponible para todos los demás. Cualquiera puede ver quién ha estado editando el documento y, en caso de un desastre, puede volver a una versión anterior. Han surgido una gran cantidad de inconvenientes por la ambigüedad y molestos trabajos de concatenación.

Administrar un proyecto a través de Git/GitHub es mucho más parecido al escenario de Google Doc y disfruta de muchas de las mismas ventajas. Definitivamente es más complicado que colaborar en un Documento de Google, pero esto lo pone en el camino correcto.

1.5 ¿Quién puede hacer qué?

Un repositorio público es legible alrededor del mundo. El propietario puede conceder niveles más altos de permiso a otras personas, como la capacidad de subir commits.

Un repositorio privado es invisible al mundo. El propietario puede conceder acceso de lectura, escritura (subida) o acceso de administrador a otros.

También hay una noción formal de una organización, que puede ser útil para gestionar permisos de repositorio para equipos completos de personas.

1.6 Características especiales de GitHub

Esto es, quizás, demasiado detallado … ¿paramos o continuamos?

Además de una interfaz de usuario bien diseñada, GitHub ofrece dos características especialmente importantes:

• Issues ¿Recuerda cómo se están usando herramientas de desarrollo de software de alto nivel? Bien, este es el rastreador de errores. Es una lista de cosas … bugs, peticiones, lo que sea.
  • Los issues están estrechamente integrados con el correo electrónico y, por lo tanto, le permiten copiar/incrustar conversaciones importantes en el repositorio asociado.
  • Los issues pueden ser asignados a personas y etiquetados como (“error” o “informe de progreso”).
  • Los issues están estrechamente integrados con los commits y, por ende, le permiten registrar casos como el de que los cambios en este commit resuelven el problema que se discutió.
  • Como un nuevo usuario de GitHub, una de las cosas más productivas que puede hacer es utilizar los issues para proporcionar un informe de errorres claro o solicitud de características para un paquete que utiliza.
• Pull requests Git permite que un proyecto tenga múltiples branches independientes de desarrollo, con la noción de que algunas deberían eventualmente ser fusionadas de nuevo en la branch principal de desarrollo. Estos son términos técnicos de Git, pero se espera que también tengan sentido por sí mismos. Un pull request es una propuesta formal que dice: “Aquí hay algunos cambios que me gustaría hacer”. Podría estar vinculado a un tema específico: “Relacionado con #14” o “arreglos #56”. GitHub facilita y preserva la discusión de la propuesta, de manera holística y línea por línea.

1.7 ¿Qué hay de especial en usar R con Git y GitHub?

• La activa comunidad de desarrollo de paquetes de R en GitHub. Lea acerca de los recursos específicos de R con GitHub y busque aquí para más información.
• Los flujos de trabajo específicos hacen gratificante compartir código fuente, informes compartidos y proyectos enteros. Lea más información sobre R Markdown, R scripts y R-heavy projects.
• Las características de Git y GitHub relacionadas con RStudio IDE.

1.8 Audiencia y pre-requisitos

El público objetivo de este sitio es alguien que analice datos, probablemente con R, aunque parte del contenido puede ser útil para analistas que utilizan otros lenguajes. El desarrollo de paquetes con R mediante Git(Hub) tiene un alcance absoluto, pero no es un enfoque o requisito explícito.

El sitio está dirigido a usuarios de R intermedio a avanzado, que están cómodos escribiendo scripts en R y manejando proyectos en R. Debe tenerse un buen conocimiento acerca de archivos y directorios y saber en dónde viven las cosas en su computadora.

Aunque se mostrarán alternativas para la mayoría de las operaciones de Git, inevitablemente habrá algún tiempo dentro del shell y se asumirá alguna experiencia previa. Por ejemplo, debe saber cómo abrir un shell, navegar a un directorio determinado y listar los archivos allí. Debería sentirse cómodo al usar comandos de shell para ver/mover/renombrar archivos y trabajar con su historial de comandos.

1.9 Qué NO es esto

El objetivo es enseñar a los principiantes acerca de Git sobre una estricta base de “cosas necesarias”. Git fue construido para gestionar el desarrollo del kernel de Linux, que es probablemente muy diferente de lo que un usuario común y corriente hace generalmente. La mayoría de las personas necesitan un pequeño subconjunto de las funcionalidades completas de Git y ese será el enfoque de este documento. Si quiere una exposición completa de Git como un grafo acíclico dirigido o un tratado sobre la estrategia de ramificación de Git-Flow, se aburrirá.