Tutorial de Git: crear un repositorio en GitHub o GitLab y clonarlo

Un recordatorio útil antes de empezar, desarrollado en la introducción del tutorial: Git se ejecuta en tu máquina, y GitHub y GitLab no son más que alojamientos de repositorios Git.

Hay dos formas de llegar a un proyecto versionado con Git y conectado a GitHub o GitLab, y la elección depende únicamente del orden en que existen las cosas. O el repositorio remoto ya existe y lo recuperas: eso es clonar. O tienes una carpeta en tu máquina y la publicas: eso es inicializar y luego hacer push. Este capítulo cubre los dos casos.

Crear el repositorio remoto

En GitHub, el botón New desde la página de inicio, o la dirección github.com/new. En GitLab, New project y luego Create blank project.

Hay tres decisiones que tomar en el momento de la creación.

El nombre. Pasa a formar parte de la URL del repositorio. Usa minúsculas y guiones, sin acentos ni espacios.

La visibilidad. Público significa legible por cualquiera, incluido el historial completo y, por tanto, todo lo que hayas metido en un commit por error. Privado limita el acceso a las personas que invites. En caso de duda, empieza en privado: pasar de privado a público más adelante es inmediato, mientras que lo contrario no borra lo que ya se haya copiado.

El archivo README. Marca la casilla solo si piensas clonar el repositorio. Si ya tienes una carpeta que publicar, deja el repositorio completamente vacío, si no, tendrás que reconciliar dos historiales que no tienen nada en común.

Elegir entre la dirección SSH y la dirección HTTPS

Una vez creado el repositorio, la página te ofrece una URL en dos formas. Apuntan al mismo repositorio y solo se diferencian en el método de autenticación.

Fíjate bien en la diferencia de forma: la dirección SSH lleva dos puntos después del nombre de host, no una barra. Y sobre todo, el dominio cambia según el servicio. Dar una URL github.com para un proyecto alojado en GitLab es un error de copiar y pegar clásico.

Si dejaste puesta una clave SSH en el capítulo anterior, usa la dirección SSH: no volverá a pedirte nada. La dirección HTTPS obliga a facilitar un token de acceso personal, que el gestor de credenciales puede memorizar.

Primer caso: el repositorio existe y lo clonas

Es la situación cuando te incorporas a un proyecto, o cuando has creado el repositorio con un README.

git clone git@github.com:utilisateur/projet.git

Git crea una carpeta projet en el directorio actual, descarga en ella todo el historial y registra el repositorio remoto con el nombre origin. Para elegir otro nombre de carpeta, añádelo como segundo argumento:

git clone git@github.com:utilisateur/projet.git mon-dossier

Comprueba lo que has obtenido:

cd projet
git remote -v
git branch --show-current

origin	https://github.com/git/git.git (fetch)
origin	https://github.com/git/git.git (push)
master

Dos observaciones sobre esta salida. origin aparece dos veces porque Git distingue la dirección de lectura de la de escritura, casi siempre idénticas. Y la rama se llama aquí master porque es el nombre de la rama por defecto del repositorio clonado: el clonado toma el nombre del servidor e ignora por completo tu ajuste init.defaultBranch, que solo afecta a los repositorios que creas tú.

Segundo caso: la carpeta existe y la publicas

Es la situación cuando has empezado a trabajar antes de acordarte de Git. Sitúate en la carpeta del proyecto.

cd ~/projets/ma-boutique
git init

Initialized empty Git repository in /root/a2/.git/

Git acaba de crear una subcarpeta .git que contiene todo el historial. Borrarla equivaldría a eliminar el control de versiones, el resto de tus archivos no se toca.

Registra a continuación un primer commit, sin el cual no hay nada que publicar:

git add .
git commit -m "Premier commit"

Declara ahora el repositorio remoto y haz push:

git remote add origin git@github.com:utilisateur/ma-boutique.git
git branch -M main
git push -u origin main

Estas tres líneas merecen una explicación, porque muchas veces se copian sin entenderlas.

git remote add origin asocia el nombre corto origin a la URL del repositorio. origin no tiene nada de mágico, es una convención, podrías llamarlo de otra forma, pero nadie lo hace.

git branch -M main renombra la rama actual a main. La -M mayúscula fuerza el renombrado aunque ya exista una rama main. Esta línea sobra si configuraste init.defaultBranch en el capítulo anterior, pero tampoco molesta.

git push -u origin main envía la rama y, gracias a -u, memoriza el vínculo entre tu rama local y la del servidor. Es ese vínculo el que permite escribir después git push y git pull a secas. Sin él, Git te para:

fatal: No configured push destination.
Either specify the URL from the command-line or configure a remote repository using

    git remote add <name> <url>

and then push using the remote name

    git push <name>

To push to multiple remotes at once, configure a remote group using

    git config remotes.<groupname> "<remote1> <remote2>"

and then push using the group name

    git push <groupname>

La trampa del README marcado

Si has creado el repositorio remoto con un README cuando tu carpeta local ya tenía commits, cada lado tiene su propio primer commit, sin ningún antepasado común. Git se niega entonces a unirlos:

fatal: refusing to merge unrelated histories

La solución es pedírselo de forma explícita, una sola vez:

git pull origin main --allow-unrelated-histories

Merge made by the 'ort' strategy.
 README.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Los dos historiales quedan unidos por un commit de fusión y el README se suma a tus archivos. A partir de ahí ya puedes hacer push con normalidad.

Gestionar los repositorios remotos

Unos cuantos comandos que conviene conocer para lo que viene.

git remote -v                                    # listar los repositorios remotos
git remote set-url origin git@github.com:u/p.git # cambiar la URL, por ejemplo pasar de HTTPS a SSH
git remote rename origin upstream                # renombrar
git remote remove origin                         # desvincular

git remote set-url es el comando que hay que recordar: es el que arregla un repositorio clonado por HTTPS que quieres pasar a SSH, sin tener que volver a clonarlo todo.

Un repositorio local puede vivir sin servidor

Nada te obliga a publicar. Un git init seguido de commits funciona perfectamente en una carpeta que nunca saldrá de tu máquina, y ya tienes el historial y la posibilidad de volver atrás. El repositorio remoto aporta tres cosas: una copia de seguridad fuera de tu disco, un punto de intercambio con otras personas y el acceso a las herramientas del alojamiento.

Tu proyecto ya está en marcha. El capítulo siguiente pasa a los comandos del trabajo diario y a cómo deshacer un error.