... | ... | @@ -61,7 +61,7 @@ El comando anterior establece una permanencia en caché de 3600 segundos (1 hora |
|
|
|
|
|
## Conexión al repositorio por SSH
|
|
|
|
|
|
Al clonar o interactuar con un repositorio remoto necesitamos una URL de identificación del mismo. Git trabajo con dos tipos de protoclos de acceso:
|
|
|
Al clonar o interactuar con un repositorio remoto necesitamos una URL de identificación del mismo. Git trabajo con dos tipos de protocolos de acceso:
|
|
|
|
|
|
* HTTPS
|
|
|
|
... | ... | @@ -75,7 +75,7 @@ un ejemplo de git clone del mismo repositorio utilizando ssh sería: |
|
|
|
|
|
`git clone git@gitlab.iessanclemente.net:documentacion/doc.git`
|
|
|
|
|
|
Al utilizar https, si el repositorio no es de escritura pública, siempre que hagamos alguna escritura en el repositorio tendremos que indicar el usuario y password, lo cual puede ser molesto y poco práctico.
|
|
|
Al utilizar https, si el repositorio no es de escritura pública, siempre que hagamos alguna escritura en el repositorio tendremos que indicar el usuario y password, lo cual puede ser molesto y poco práctico. Además, con la configuración actual de Gitlab es recomendable utilizar la opción de autenticación mediante ssh, como se explica a continuación.
|
|
|
|
|
|
Con ssh, podemos añadir nuestra **public key ssh** a nuestro perfil de usuario para que cada vez que enviemos una solicitud de escritura en el repositorio utilizando este protocolo no sea necesario indicar el usuario y la password de forma manual. Si no disponemos todavía de un par de claves para nuestro usuario de trabajo en local, es decir, nuestra máquina en desarrollo, en la que disponemos de la copia local del repositorio conectado a un repositorio remoto, podemos generarlas, en GNU/Linux o MacOS (en Windows podemos usar el programa Putty) con el comando:
|
|
|
|
... | ... | |