di.png

Resumen

$$$

Objetivos

  • Introducir la necesidad del control de versiones

  • Aprender a usar las operaciones y flujos básicos de Git en repositorios locales y remotos

  • Conocer las principales plataformas Git online actuales

  • Aprender a trabajar de forma colaborativa con Git

1. Introducción

1.1. Qué es Git

Git is a distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

— https://git-scm.com/

Sitio oficial (Descargas, documentación, …​):

1.2. Plataformas Git online

  • GitHub, el más popular, ofrece repos públicos. También ofrece un plan de repos privados para docencia

  • BitBucket es otra alternativa (permite repos privados)

  • GitLab ofrece repositorios privados y ofrece una versión Community para instalar on-premise

Diferencias básicas entre el modelo privado de GitHub y BitBucket

  • GitHub: Limita el número de repos. Usuarios ilimitados

  • BitBucket: Limita el número de usuarios. Repos ilimitados

1.3. gitlabdoc.ual.es

  • Repos privados y recursos propios

  • Acceso vía LDAP con login y pass de Campus virtual

gitlabdoc.png

2. Operaciones básicas con repositorios locales

2.1. Configuración local

Cada commit irá firmado con nuestro email y nombre.

$ git config --global user.email "mtorres@ual.es"
$ git config --global user.name "Manuel Torres Gil"

Configuración almacenada en ~/.gitconfig

2.2. git init

Crea un repo local en la carpeta de proyecto

Creamos carpeta para pruebas denominada holagit y entramos a ella.

$ git init
Initialized empty Git repository in C:/Users/Administrator/holagit/.git/

2.3. Working dir, Staging Area y Repo

stagingarea.svg

Otra forma de verlo

addcommit.png

2.4. Crear un archivo de ejemplo

README.md

# Hola Git

Este es mi primer archivo para control de versiones.

2.5. git status

Muestra las diferencias entre el Working dir, la Staging Area y el repo.

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        README.md

nothing added to commit but untracked files present (use "git add" to track)

2.6. git add

Añade desde Working dir a Staging area (index)

La sintaxis es git add files

Algunos ejemplos:

$ git add README.md
$ git add .
$ git add --all

Vemos los cambios con git status para ver cómo ha pasado a la Staging area y está listo para pasarlo al repositorio.

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md

2.7. git commit

Añade desde Staging Area al repo

La sintaxis es git commit -m commitText

$ git commit -m "README.md creado"
[master (root-commit) 1f86692] README.md creado
 1 file changed, 3 insertions(+)
 create mode 100644 README.md

Podemos ver el estado con git status

$ git status
On branch master
nothing to commit, working tree clean

2.8. git blame

Quién ha cambiado un archivo y cuándo

$ git blame README.md
^1f86692 (Manuel Torres Gil 2018-11-27 17:39:47 +0000 1) # Hola Git
^1f86692 (Manuel Torres Gil 2018-11-27 17:39:47 +0000 2)
^1f86692 (Manuel Torres Gil 2018-11-27 17:39:47 +0000 3) Este es mi primer archivo para control de versiones.

2.9. git log

Muestra los comentarios comenzando por el más reciente.

$ git log
$ git log --oneline (1)
1 Versión compacta

Más información sobre la presentación de logs en: https://stackoverflow.com/questions/1441010/the-shortest-possible-output-from-git-log-containing-author-and-date

 
$ git log (1)
commit 1f8669231adc380d96261f91495018ba2791b0b3 (HEAD -> master)
Author: Manuel Torres Gil <mtorres@ual.es>
Date:   Tue Nov 27 17:39:47 2018 +0000

    README.md creado

$ git log --oneline (2)
1f86692 (HEAD -> master) README.md creado
1 Versión normal
2 Versión compacta

2.10. Ejercicio

  1. Añadir una línea nueva al archivo README.md con el texto que aparece a continuación

    # Aprende latín

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

  2. Añadir los cambios a la Staging area

  3. Añadir los cambios al repositorio con el mensaje Nuevo epígrafe

  4. Mostrar el log

  5. Obtener el estado del repositorio

Se debería obtener algo similar a lo siguiente

$ git log (1)
commit 706c9ab817425ea714b758cbcf7934dcf0a6ecb4 (HEAD -> master)
Author: Manuel Torres Gil <mtorres@ual.es>
Date:   Tue Nov 27 17:55:13 2018 +0000

    Nuevo epígrafe (2)

commit 1f8669231adc380d96261f91495018ba2791b0b3
Author: Manuel Torres Gil <mtorres@ual.es>
Date:   Tue Nov 27 17:39:47 2018 +0000

    README.md creado

$ git status (3)
On branch master
nothing to commit, working tree clean
1 Mostrando los cambios
2 El nuevo commit aparece el primero
3 Mostrando el estado

3. Operaciones básicas con repositorios remotos

3.1. Configuración de claves SSH en gitlabdoc.ual.es

Las claves SSH evitan introducir login y pass en cada operación de subida al repositorio remoto (push)

En GitLab, cada usuario tiene que modificar sus Settings en Profile Settings → SSK Keys → Add SSH Key:

3.1.1. Crear SSH Key

Desde una terminal ejecutaremos

$ ssh-keygen

Esto genera dos archivos:

  • Clave privada: id_rsa

  • Clave pública: id_rsa.pub

3.1.2. Actualizar SSH Key en GitLab

Copiar el contenido de la clave pública id_rsa.pub en GitLab y asignarle un nombre

$ cat ~/.ssh/id_rsa.pub

addsshkey.png

3.2. git clone

Clona un repo remoto (bare) en nuestro equipo

clone.png

Si el repositorio clonado es nuestro podremos propagar posteriormente los cambios del repositorio local al repositorio remoto. En cambio, si el repositorio no es nuestro sólo podremos subir cambios al repositorio remoto si nos autorizan a ello.
Merge requests y Pull requests

Una forma de colaboración que veremos más adelante consiste en crear una copia del proyecto remoto. Esta operación se conoce como Fork. Al hacer un fork se crea un repositorio remoto de nuestra propiedad, el cual es copia del repositorio original.

Para solicitar que nuestros cambios puedan ser considerados para pasar al proyecto original realizaremos una Merge request en GitLab (Pull request en GitHub). Esto inicia un proceso de revisión que finaliza con la aceptación, rechazo (o ignoando) de nuestros cambios por parte del propietario del repositorio remoto original.

3.3. Ejemplo

  1. Crear repo prueba en GitLab

  2. Clonar repo remoto en la carpeta del usuario que estés usando git clone URL usando el protocolo SSH.

    Actualmente, hay un detalle sobre la identificación del certificado que usa gitlabdoc.ual.es al clonar con el protocolo mediante HTTPS. Si recibes este mensaje de error:

    server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

    puedes salir del paso desactivando la verificación del certificado con este comando:

    $ git config --global http.sslverify false

  3. Entrar al directorio del nuevo proyecto y crear archivo README.md con el texto que aparece a continuación

    # Git

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

  4. Añadir los cambios a la staging area

  5. Añadir los cambios al repositorio con el mensaje Commit inicial

Al mostrar los cambios de aparecer algo similar a esto:

$ git log
commit 6aabc98f79034f3ea505b33bead4fa807e5ee59d (HEAD -> master)
Author: Manuel Torres Gil <mtorres@ual.es>
Date:   Tue Nov 27 18:14:20 2018 +0000

    Commit inicial

3.4. git push

Envia los cambios del repositorio local a un repo remoto

git push remoto ramaLocal

En nuestro ejemplo haríamos git push origin master

origin es el alias que damos al repositorio remoto. master es la rama que contiene los commits que queremos subir. Al hacer push se subirán todos los commits pendientes de sincronizarse con el repositorio remoto.

Tras hacer el push se debe obtener algo similar a esto:

$ git push origin master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 2 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 337 bytes | 168.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To gitlabdoc.ual.es:mtorres/prueba.git (1)
 * [new branch]      master -> master (2)
1 Repositorio remoto al que se suben los cambios (origin).
2 Crea la rama master en el repositorio remoto ya que antes no estaba.

En el archivo .git/config de la carpeta de trabajo está la URL con la que se corresponde origin.

Si tenemos dos repositorios remotos con los que sincronizar, añadiríamos una segunda URL en la sección de [remote "origin"]

4. Escenario colaborativo basado en control de acceso

El propietario del proyecto añade nuevos miembros configurando sus privilegios.

En GitLab, en la propiedades del proyecto añadimos miembros al proyecto indicando sus privilegios (guest, reporter, developer, master) en función de las operaciones permitidas.

addmembers.png

A continuación, se especifican las ramas en las que están autorizados a subir cambios (Desproteger ramas).

En GitLab, en las propiedades del proyecto seleccionamos Settings → Protected Branches

unprotectbranch.png

Por último, se selecciona la rama y se indica que los desarrolladores pueden realizar push

allowpush.png

5. Escenario colaborativo basado en merge requests (pull requests en GitHub)

colaboracion.png

5.1. origin y upstream

upstream.png

6. Recursos de interés