18 Proyecto existente, GitHub luego

Un flujo de trabajo explícito para conectar un proyecto local en R existente a GitHub, cuando por alguna razón no puede o no quiere hacer un flujo de trabajo “GitHub primero” (ver capítulos 16 y 17).

¿Cuándo podría surgir esto? Tal vez si es un proyecto existente que también es un repositorio Git con una historia que le importa? Entonces tiene que hacerlo apropiadamente.

Esto es menos deseable para un principiante porque implica la línea de comandos Git. No puede hacerse desde RStudio.

18.1 Hacer o verificar un proyecto de RStudio

Se asume que tiene un proyecto en R existente aislado en un directorio en su computadora.

Si aun no es un proyecto RStudio, hágalo así:

  • Cree un nuevo proyecto RStudio: File > New Project > Existing Directory.
  • Yes: “Open in new session”.

Si ya es un proyecto RStudio, inícielo.

18.2 Hacer o verificar un repositorio de Git

Debería estar en RStudio ahora, en el Proyecto.

¿Ya es un repositorio de Git? La presencia del panel de Git debe indicarle. Si es así, ya está.

Si no:

Tools > Project Options … > Git/SVN en Sistema de control de versiones, seleccione “Git”. ¿Confirmar nuevo repositorio de Git? ¡Sí!

El proyecto debería volver a iniciarse en RStudio y ahora debería tener un panel Git.

18.3 Stage y commit

Si su proyecto local ya era un repositorio de Git y estaba actualizado, siga adelante. De lo contrario, es probable que tenga que hacer stage y commit.

  • Haga clic en la pestaña “Git” en el panel superior derecho
    • Compruebe la casilla “Staged” para todos los archivos a los que desee hacer commit.
      • Predeterminado: haga stage.
      • Cuándo reconsiderar: todo esto irá a GitHub. Así que considere si eso es apropiado para todos los archivos. Puede mantener un archivo localmente, sin hacerle commit en el repositorio de Git y enviarlo a GitHub. Simplemente deje que esté allí en su panel de Git, sin hacerle staged. No se dañará. Si se trata de una situación a largo plazo, liste el archivo en .gitignore.
    • Si aún no está en la ventana emergente de Git, haga clic en “Commit”
    • Escriba un mensaje en “Commit message”.
    • Haga clic en “Commit”

18.4 Hacer un repositorio en GitHub

Vaya a https://github.com y asegúrese de estar logueado.

Haga clic en el botón verde “New repository”. O bien, si está en su propia página de perfil, haga clic en “Repositories” y, a continuación, haga clic en el botón verde “New”.

Elija un nombre de repositorio –probablemente debería coincidir con el nombre de su proyecto y directorio local. ¿Por qué confundirse?

Pública o privada, según sea apropiado y mejor NO inicialice este repositorio con un README.

Haga clic en el botón verde grande “Create repository”.

Copie la URL del clon HTTPS en su portapapeles a través del botón verde “Clonar o descargar”. O copie la URL SSH si escogió configurar las claves SSH.

18.5 Conectarse a GitHub

Inicie la relación “upstream” o “tracking” agregando un control remoto. Vaya a Tools>shell y haga esto dentro de la carpeta donde está su Proyecto al que le va a hacer control de versiones, sustituyendo la URL HTTPS o SSH por su repositorio GitHub, de acuerdo con su configuración:

    git remote add origin https://github.com/jennybc/myrepo.git
  • Haga push y añada la relación de seguimiento entre su repositorio GitHub y el repositorio local subiendo y haciendo “upstream”:

    git push -u origin master

18.6 Confirme el cambio local extendido al control remoto GitHub

Vuelva al navegador. Se supone que todavía está viendo su nuevo repositorio de GitHub.

Refresque la página del navegador.

Debería ver todos los archivos del proyecto a los que les haya hecho commit allí.

Si hace clic en “commit”, debería ver uno con el mensaje “init”.

18.7 Finalmente

Ahora sólo … repita. Trabaje donde quiera. Haga Commit. Haga pull o push dependiendo de dónde lo hizo, pero obtenga “sincronización” local y remota. Repita.

  • Tenga en cuenta que en general (y especialmente en el futuro al colaborar con otros desarrolladores) usualmente tendrá que hacer pull de los cambios desde el mando a distancia (GitHub) antes de hacer push de los cambios locales que haya hecho. Por esta razón, es una buena idea tratar de adquirir el hábito de hacer pull antes de intentar hacer push.