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

¿Por qué un analista de datos utilizaría el control de versiones alojado?

Esta introducción se ha convertido en un artículo independiente que posiblemente sea una mejor introducción en este momento. Hasta que lo vuelva a fusionar, considere leer el artículo: “Disculpe, ¿tiene un momento para hablar sobre el control de versiones?” https://dx.doi.org/10.7287%2Fpeerj.preprints.3159v2.

1.1 ¿Por qué Git?

Git es un sistema de control de versión. Su propósito original era ayudar a grupos de desarrolladores a trabajar en colaboración en grandes proyectos de software. Git gestiona la evolución de un conjunto de archivos, llamado repositorio, de una manera sensata y altamente estructurada. Si no tiene idea de lo que estoy hablando, considérelo como las funciones de “Seguimiento de cambios” de Microsoft Word con esteroides.

Git ha sido reutilizado por la comunidad científica de datos. Además de usarlo para el código fuente, lo usamos para administrar la variada colección de archivos que componen los proyectos típicos de análisis de datos, que a menudo consisten en datos, cifras, informes y, sí, código fuente.

Un analista de datos en solitario que trabaje en una sola computadora se beneficiará de la adopción del control de versiones. Pero no lo suficiente como para justificar el dolor de la instalación y la agitación del flujo de trabajo. Hay formas mucho más sencillas de obtener copias de seguridad versionadas de sus archivos, si eso es lo único que le preocupa.

En mi opinión, para los nuevos usuarios, las ventajas de Git sólo superan las desventajas cuando se tienen en cuenta los gastos generales de comunicación y colaboración con otras personas. ¿Quién de nosotros no necesita hacer eso? Su vida es mucho más fácil si esto está integrado en su flujo de trabajo, en lugar de ser un proceso separado que teme o descuida.

1.2 ¿Por qué GitHub?

Aquí es donde los servicios de hosting como GitHub, Bitbucket, y GitLab intervienen. Proporcionan un hogar para sus proyectos basados en Git en Internet. Si no tienes idea de lo que estoy hablando, considéralo DropBox, pero es mucho, mucho mejor. El host remoto actúa como canal de distribución o centro de compensación para su proyecto administrado por Git. Permite que otras personas vean tus cosas, se sincronicen contigo y tal vez incluso realicen cambios. Estos proveedores de alojamiento mejoran los servidores Unix Git tradicionales con interfaces basadas en web bien diseñadas.

Incluso para proyectos privados en solitario, es una buena idea trasladar su trabajo a una ubicación remota para su tranquilidad. ¿Por qué? Porque es bastante fácil arruinar tu repositorio Git local, especialmente cuando eres nuevo en esto. La buena noticia es que a menudo sólo se daña la infraestructura de Git. ¡Tus archivos están bien! Lo que hace que tu Git se vuelva aún más frustrante. Existen soluciones oficiales de Git para estos problemas, pero pueden requerir experiencia y paciencia a las que no puedes acceder a las 3 a.m. Si recientemente subiste tu trabajo a GitHub, es fácil obtener una copia nueva, arreglar las cosas con los cambios que solo existe localmente y continúa con tu vida.

En este libro se expone la integración con GitHub, no con Bitbucket o GitLab, por el bien de especificidad. Sin embargo, todos los principios generales e incluso algunas mecánicas se trasladarán a estas plataformas de alojamiento alternativas.

No se deje atrapar demasiado por lo público versus lo privado en este momento. Hay muchas formas de obtener repositorios privados de los principales proveedores a bajo costo o sin costo alguno. ¡Simplemente comience y descubra si Git/GitHub funcionará para usted y cómo! Si supera este acuerdo, puede invertir alguna combinación de conocimiento técnico y dinero en el problema. Puede pagar por un nivel superior de servicio o alojar usted mismo una de estas plataformas.

1.3 ¿Va a doler?

Sí.

Debe instalar Git, hacer que Git local se comunique con GitHub y asegurarse de que RStudio pueda comunicarse con Git local (y, por lo tanto, con GitHub). Este es un dolor que ocurre una sola vez o una vez por computadora.

Para proyectos nuevos o existentes, usted:

• Dedícale un directorio (también conocido como “carpeta”).
• Conviértalo en un proyecto RStudio.
• Conviértalo en un repositorio Git.
• Continúe con sus asuntos habituales. Pero en lugar de solo guardar archivos individuales, periódicamente realiza una confirmación(commit), que toma una instantánea de varios archivos de todo el proyecto.
  • ¿Alguna vez ha versionado un archivo agregando sus iniciales o la fecha? Eso es efectivamente un commit, aunque solo para un único archivo: es una versión que es importante para usted y que quizás desee inspeccionar o volver a consultar más adelante.
• Envíe (push) comits a GitHub periódicamente.
  • Esto es como compartir un documento con colegas en DropBox o enviarlo como archivo adjunto de correo electrónico. Indica que estás listo para hacer que tu trabajo sea visible para otros e invitar a comentar o editar.

Este es un cambio en su flujo de trabajo diario normal. Al principio se siente extraño, pero rápidamente se convierte en algo natural. FWIW, STAT 545 los estudiantes deben enviar todos los trabajos del curso a través de GitHub. Este es un tema importante en las horas de clase y de oficina durante las primeras dos semanas. Luego prácticamente nunca volvemos a hablar de ello.

Más malas noticias. El dolor de STAT 545 dura poco porque los estudiantes trabajan principalmente en sus propios repositorios. ¿Utilizas GitHub para trabajar con otras personas o para coordinar tu propio trabajo desde varias computadoras? Si es así, después de que te recuperes de la configuración inicial, Git te aplastará nuevamente con conflictos de fusión. Y este no es un dolor que ocurre una sola vez, sino que puede ser un dolor sordo que dure mucho tiempo. El mejor remedio es la prevención, pero también comprender cómo salir de situaciones difíciles y abordarlas en sus propios términos.

El resto de este sitio está dedicado a guiarlo a través de la configuración necesaria y a crear sus primeros proyectos Git. Concluimos con indicaciones que lo 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 tu trabajo o si quieres que pruebe tu código, puede obtenerlo fácilmente desde GitHub. Si usan Git, pueden clonar o bifurcar su repositorio. Si no usan Git, aún pueden explorar su proyecto en GitHub como un sitio web normal e incluso obtener todo descargando un archivo zip.

¡Sea más entusiasta! Si le importa mucho el proyecto de otra persona, como un paquete R que usa mucho, puede realizar un seguimiento de su desarrollo en GitHub. Puede ver el repositorio para recibir notificaciones sobre actividades importantes. Puedes bifurcarlo para conservar tu propia copia. Puede modificar su bifurcación para agregar características o corregir errores y enviarlos de regreso al propietario como una propuesta de cambio.

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

• Editar, guardar, adjuntar. En este flujo de trabajo, todos tienen una (¡o más!) copias del documento y circulan como archivo adjunto por correo electrónico. ¿Cuál es “maestro”? ¿Es siquiera posible decirlo? ¿Cómo se relacionan las diferentes versiones entre sí? ¿Cómo deben conciliarse las versiones? Si quieres ver la mejor versión actual, ¿cómo la consigues? Todo esto normalmente se soluciona mediante un contrato social y un proceso bastante manual.
• Google Doc. En este flujo de trabajo, solo hay una copia del documento y se encuentra en la nube. Cualquiera puede acceder a la versión más reciente bajo demanda. Cualquiera puede editar, comentar o proponer un cambio y esto estará inmediatamente disponible para todos los demás. Cualquiera puede ver quién ha estado editando el documento y, si ocurre un desastre, puede volver a una versión anterior. Se ha eliminado una gran cantidad de ambigüedades y molestos trabajos de reconciliación.

Gestionar un proyecto a través de Git/GitHub se parece mucho más 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 te pone en la mentalidad correcta.

1.5 ¿Quién puede hacer qué?

Un repositorio público es legible por todo el mundo. El propietario puede otorgar niveles más altos de permiso a otros, como la capacidad de push commits.

Un repositorio privado es invisible para el mundo. El propietario puede otorgar acceso de lectura, escritura (push) o administrador a otras personas.

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

1.6 Características especiales de GitHub

esto quizás sea demasiado detallado… ¿punto final? ¿o pertenece a otra parte?

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

• Problemas(Issues). ¿Recuerda que estamos secuestrando herramientas de desarrollo de software? Bueno, este es el rastreador de errores. Es una lista de cosas… errores, solicitudes de funciones, tareas pendientes, lo que sea.
  • Los problemas están estrechamente integrados con el correo electrónico y, por lo tanto, le permiten copiar/incrustar conversaciones importantes en el repositorio asociado.
  • Los problemas se pueden asignar a personas (por ejemplo, para hacer) y etiquetarlos (“error” o “informe de progreso”).
  • Los problemas están estrechamente integrados con las confirmaciones y, por lo tanto, le permiten registrar que los cambios en esta confirmación resuelven el problema que se discutió en esa edición.
  • Como nuevo usuario de GitHub, una de las cosas más productivas que puede hacer es utilizar los problemas de GitHub para proporcionar un informe de error claro o una solicitud de función para un paquete que utiliza.
• Solicitudes de cambio (Pull request). Git permite que un proyecto tenga múltiples ramas de desarrollo independientes, con la idea de que algunas eventualmente deberían fusionarse nuevamente en la rama de desarrollo principal. Estos son términos técnicos de Git, pero es de esperar que también tengan sentido por sí solos. Una solicitud de cambio es una propuesta formal que dice: “Aquí hay algunos cambios que me gustaría realizar”. Podría estar vinculado a un problema específico: “Relacionado con el n.º 14”. o “Soluciona n.º 56”. GitHub facilita y preserva la discusión de la propuesta, de manera integral y línea por línea.

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

• La comunidad activa de desarrollo de paquetes R en GitHub. Lea acerca de las búsquedas y los recursos de GitHub específicos de R aquí.
• Los flujos de trabajo específicos hacen que sea gratificante compartir código fuente, informes renderizados y proyectos completos. Leer más sobre R Markdown, R scripts, y R-heavy projects.
• Funciones relacionadas con Git y GitHub de RStudio IDE. Este aspecto se cubre a lo largo del libro.

1.8 Audiencia y requisitos previos

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

El sitio está dirigido a usuarios de R de nivel intermedio a avanzado, que se sienten cómodos escribiendo scripts de R y gestionando proyectos de R. Debe tener un buen conocimiento de los archivos y directorios y, en general, tener conocimientos sobre dónde se encuentran las cosas en su computadora.

Aunque mostraremos alternativas para la mayoría de las operaciones de Git, inevitablemente pasaremos algún tiempo en el shell y asumimos cierta experiencia previa. Por ejemplo, debe saber cómo abrir un shell, navegar a un directorio determinado y enumerar los archivos allí. Debería sentirse cómodo usando comandos de shell para ver/mover/renombrar archivos y trabajar con su historial de comandos.

1.9 Lo que esto NO es

Nuestro objetivo es enseñar a los principiantes sobre Git basándose estrictamente en la “necesidad de saberlo”. Git fue creado para gestionar el desarrollo del kernel de Linux, que probablemente sea muy diferente de lo que hace usted. La mayoría de la gente necesita un pequeño subconjunto de la funcionalidad de Git y ese será nuestro enfoque. Si desea una exposición completa de Git como un gráfico acíclico dirigido o un tratado sobre la estrategia de ramificación Git-Flow, no lo encontrará en este libro.