|
|
|
# Repositorio git. Construcción y desarrollo
|
|
|
|
Como base para los artefactos del proyecto, tanto documentales como de código fuente y herramientas se usan los repositorios git. Cada proyecto dispone de su propio repositorio con el que se puede trabajar de la forma habitual a través de alguno de los clientes, como el comando git de Linux, o herramientas de tipo cliente git de otros sistemas operativos.
|
|
|
|
|
|
|
|
Para Windows puede descargarse desde:
|
|
|
|
|
|
|
|
[https://git-scm.com/download/win](https://git-scm.com/download/win)
|
|
|
|
|
|
|
|
En Linux derivados de Debian podemos ejecutar el comando:
|
|
|
|
|
|
|
|
`apt update && apt install -y git`
|
|
|
|
|
|
|
|
Sobre el uso de repositorios git hay muchos tutoriales disponibles en Internet. Podéis tomar como referencia el siguiente:
|
|
|
|
|
|
|
|
[https://git-scm.com/doc](https://git-scm.com/doc)
|
|
|
|
|
|
|
|
A continuación un archivo con una lista de comandos más utilizados y opciones
|
|
|
|
|
|
|
|
[Chuleta Git](https://about.gitlab.com/images/press/git-cheat-sheet.pdf)
|
|
|
|
|
|
|
|
## Iniciando trabajo con el repositorio
|
|
|
|
|
|
|
|
Vamos a ver a continuación el procedimiento para descargar el repositorio git de un proyecto gitlab a vuestro equipo de desarrollo. Estos comandos harán uso de la herramienta de línea de comandos git, la cual podéis obtener del modo comentado más arriba.
|
|
|
|
|
|
|
|
En primer lugar deberemos iniciar el entorno de trabajo git:
|
|
|
|
|
|
|
|
`git config --global user.name "Javier Fernández Peón"`
|
|
|
|
|
|
|
|
`git config --global user.email "javierfp@iessanclemente.net"`
|
|
|
|
|
|
|
|
Estos dos pasos anteriores son necesarios para identificar los envíos al repositorio (commits)
|
|
|
|
|
|
|
|
A continuación clonamos el repositorio para obtener nuestra copia local. Supongamos que la URL del repositorio es
|
|
|
|
|
|
|
|
*https://gitlab.iessanclemente.net/javierfp/test*
|
|
|
|
|
|
|
|
`git clone https://gitlab.iessanclemente.net/javierfp/test`
|
|
|
|
|
|
|
|
El paso anterior podrá solicitar un usuario y password en caso de que el proyecto fuese de ámbito restringido, es decir no público. Usaremos el usuario y password de nuestro usuario de gitlab. Si el repositorio fuese público no sería necesario introducirlo.
|
|
|
|
|
|
|
|
Si todo ha ido bien y se ha descargado el repositorio podremos ingresar el directorio del repositorio
|
|
|
|
|
|
|
|
`cd test`
|
|
|
|
|
|
|
|
y comprobar la referencia con el repositorio origen
|
|
|
|
|
|
|
|
`git remote show origin`
|
|
|
|
|
|
|
|
### Mantener credenciales de acceso en caché
|
|
|
|
|
|
|
|
Si vamos a trabajar con repositorios remotos a los que haremos push periódicamente es conveniente tener en cuenta que:
|
|
|
|
|
|
|
|
* El flujo de trabajo suele seguir el patrón **cambios en local->commit local->push remoto**
|
|
|
|
* Conviene estructurar la realización de commits de un modo organizado y bien documentado, no es buena práctica el hacer "commits compulsivos", es decir es recomendable organizar el envío de cambios al repositorio, tratando de tener un histórico lo más limpio y legible posible. Suele ser recomendable utilizar una **rama para desarrollo** que periódicamente se fusiona con la **rama principal** a través del mecanismo de **merge**.
|
|
|
|
* Una vez que decidamos hacer un envío al remoto efectuar el **push**.
|
|
|
|
|
|
|
|
Si necesitamos hacer varios envíos al remoto en la misma sesión de trabajo utilizando URL **https** será necesario introducir el usuario y password del usuario para validar el envío. Podemos mejorar la usabilidad ejecutando el comando siguiente, el cual nos permite asignar un tiempo de permanencia de las credenciales de acceso en la caché local para evitar que nos pida el usuario y password cada vez:
|
|
|
|
|
|
|
|
`git config --global credential.helper 'cache --timeout=3600'`
|
|
|
|
|
|
|
|
El comando anterior establece una permanencia en caché de 3600 segundos (1 hora) de las credenciales de acceso. Por defecto este valor está establecido a 300 (5 minutos)
|
|
|
|
|
|
|
|
## 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:
|
|
|
|
|
|
|
|
* HTTPS
|
|
|
|
|
|
|
|
por ejemplo un clone de un repositorio https tendría la forma:
|
|
|
|
|
|
|
|
`git clone https://gitlab.iessanclemente.net/documentacion/doc.git`
|
|
|
|
|
|
|
|
* SSH
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
`ssh-keygen -t rsa -b 4096 -C "javierfp@iessanclemente.net"`
|
|
|
|
|
|
|
|
el comando anterior, del cual aceptamos todas las opciones por defecto, generará el par de claves RSA en el directorio **.ssh** (oculto) dentro del directorio home del usuario. La opción -C, no obligatoria, añade un comentario identificativo a la clave. Los archivos con las claves generadas son:
|
|
|
|
|
|
|
|
* **id_rsa**: Clave privada del par de claves. Esta clave NUNCA debe de salir de nuestro equipo
|
|
|
|
* **id_rsa.pub**: Clave pública. Esta es la clave que DEBEMOS PUBLICAR en el servidor para poder autenticarnos de forma segura en él.
|
|
|
|
|
|
|
|
En nuestro caso vamos a copiar el contenido del archivo de text con la clave pública, **id_rsa.pub**, en nuestro perfil de usuario de Gitlab, en **Configuración** del usuario, **Claves SSH** (User Settings->SSH Keys). En ese apartado damos de alta una nueva clave con un nombre identificativo, copiamos el contenido del archivo **id_rsa.pub** en la caja de texto y guardamos. A partir de este momento el acceso utilizando URLs ssh con git desde nuestro usuario de trabajo a nuestra cuenta en Gitlab serán autenticadas automáticamente.
|
|
|
|
|
|
|
|
![clavessh](uploads/8beb47f81fce30425ea7ff473def0fb7/clavessh.png)
|
|
|
|
|
|
|
|
Más información en: <a href="https://gitlab.iessanclemente.net/help/ssh/README#generating-a-new-ssh-key-pair" target="_blank">Autenticación con par de claves SSH</a>
|
|
|
|
|
|
|
|
|
|
|
|
|