GIT básico

Lectura OBLIGATORIA => blog de Diego Martín.

Y en modo vídeo:

1. Introducción a GIT por TodoCode
2. Curso completo - Makigas

Resumen de zonas:

Para crear un README en texto plano, pero con un formato agradable y convertible recurriremos al formato Markdown (Fazt Code - Markdown )

Ejercicio:

1. Crear un repo con README.md conectado con GitHub.
2. Añadir colaborador (profe @luiscastelar).
3. El README.md contendrá vuestro nombre y email coorporativo.
4. Clonar repositorio en otra ubicación y realizar una captura. Añadirla (integrada) al READMe.md.
5. Crear un archivo de credenciales (nombre de usuario y contraseña) denominado .env.
6. Crear archivo .gitignore con el contenido: *.env

Aplicaciones auxiliares: GitFiend o GitG como apoyo visual a git bash. También Git Extensions como plug-in de VS.

Conectando nuevos equipos

Nuevo repositorio

Cuando queramos conectar nuevos equipos, p.e. el de casa, al repositorio BARE (central) deberemos:

1. Tener acceso al repositorio BARE mediante pares de llaves público/privadas, o por token[^1].
2. Obtener la dirección del repositorio BARE al que queremos conectar. Ésta debe ser del tipo git@github.com:luiscastelar/pruebasDAW1.git. Ésta dirección tiene 3 partes:
3. git@github.com -> el servidor al que nos estamos conectando [^2].
4. luiscastelar -> vuestro nombre de usuario en github (o el servidor al que os conectéis).
5. pruebasDAW1.git -> el repositorio al que os estáis conectando.
6. Clonar el repositorio sobre el directorio que deseemos con git clone git@github.com:luiscastelar/pruebasDAW1.git {{NOMBRE DEL DIRECTORIO}}.

A repositorio ya existente

También podemos conectar un repositorio local ya creado anteriormente y con contenido con el comando git remote add origin git@github.com:luiscastelar/pruebasDAW1.git, y posteriormente sincronizar sus contenidos con:

git pull origin main
git push -u origin main

Con el primer comando descargamos el contenido remoto y con el segundo subimos el contenido local y establecemos origin como push por defecto.

A menudo se producirán conflictos en el git pull que deberemos resolver a mano.

Revisión de la historia

• Detallado: git log
• Resumido en una línea: git log --pretty=oneline
• Con más datos: git log --pretty=format:"%h - %an, %ar : %s"
• En árbol: git log --graph

Y por supuesto combinados: git log --pretty=oneline --graph

Ver cambios entre versiones

git diff <commit-id-1> <commit-id-2> -- file-to-check

Pudiendo ser hash de commit, etiquetas o nombre de ramas.

Revertir cambios

• git reset --soft HEAD~1
• git reset --hard HEAD~1

Fuente: @midudev

Merge y rebase

¿Qué ocurre cuando trabajamos con ramas o hemos realizado cambios desde 2 equipos distintos? \

Pues que tenemos que unir los caminos. Tenemos 2 opciones: merge y rebase.

• git merge crea un commit MERGE de unión de ambas ramas.
• git rebase crea un commit REBASE que contiene los commits de la línea temporal alternativa y elimina la elimina. Como si nunca hubiera existido, pero con el mismo resultado que el merge.

Ventaja: Visualmente más sencillo ya que el historial aparece lineal.

Inconveniente: Los creadores de los commits que desaparecen pierden el seguimiento de sus cambios por los HASH. => SÓLO REALIZAR EN REPOSITORIOS UNIPERSONALES o nunca.

cherry-pick

• trayendo cambios

Nooooo:

PRÁCTICA (voluntaria)

Haz sólo lo que no tengas ya en el ejercicio anterior:

1. Crea una cuenta en github (con el email corporativo).
2. Crea un repositorio privado (vacío).
3. Sigue los pasos que te proporciona para crear un git local o subir uno existente.
4. Crea un README.md con:
5. Autor del repositorio
6. eMail de contacto (corporativo)
7. Crea un directorio para la UT1 con un README.md donde documentes esta práctica.
8. En otra carpeta, clona tu repositorio remoto.
9. Captura de pantalla.
10. Súbela a ./img
11. Enlázala al README de la práctica.
12. Crea un archivo “a.txt” con 3 líneas y sincroniza con el repositorio remoto.
13. Modifica la primera línea del archivo en la web y la tercera en local con contenidos distintos e intenta sincronizarlos. Captura el conflicto y añádelo a la documentación.
14. Busca la estrategia de solucionar el conflicto y realiza un merge.
15. Mediante gitfiend o gitg captura la línea de tiempo.
16. Regresa al punto 7 (en el tiempo) y muestra el contenido del archivo a.txt mediante una captura.
17. Vuelve al HEAD y documentalo todo.

Trabajando con ramas:

Creación y fusión de ramas

• Doc OFICIAL
• Ramas - YT:TodoCode

Sincronización de ramas

En ocasiones aparecen nuevas ramas en remoto que debemos crear en local para poder descargar las actualizaciones. ¿Lo más sencillo?

for remote in `git branch -r | grep -v /HEAD`; do git checkout --track $remote ; done`
git pull -a

Gestión de ramas

• Doc OFICIAL

Traer commits a la rama RAMA

Cuando en la rama dev hemos realizado commits interesantes puede ser de gran relevancia poder traérnoslos a la rama main.

Para ello sólo necesitamos conocer su hash (1) y, desde la rama main (a la que lo queremos llevar) deberemos escribir git cherry-pick HASH.

(1) Para capturar su hash, nos ubicaremos en la rama dev con git checkout dev y veremos el historial de commits con git log. Ésto nos arrojará el hash de cada commit, además de la descripción, autor y marca temporal.

Jugando con ramas

• learnGitBranching

Ejercicios

Git ramas

Forks

• forks

Pull request

• pull request

Preguntas que todo programador debería conocer

Eso

Mover ramas

Resulta que me he liado y he creado una rama main en remoto y en local no leí y deje por defecto la rama master. ¿Qué puedo hacer?

Tenemos varias opciones, pero voy a simplificarlas en 2:

1. Renombrar la rama remota de main a master y seguir las indicaciones que nos proporciona github: bash git branch -m main master git fetch origin git branch -u origin/master master git remote set-head origin -a
2. Clonar la rama main en un nuevo repositorio remoto, aplicar los cambios en local a mano (sugiero la aplicación Meld) y subir los cambios.

Hooks

Algo general: Hooks - Jeremy Holcombe

Pre-commit

Como estamos trabajando sobre Java, utilizaremos un pre-commit inicial para verificar el estilo de código.

Si estuviéramos en otros lenguajes, especialmente aquellos sin tipado fuerte, podríamos verificar algunas cosas sobre tipos y analizadores sintácticos en lenguajes no compilados.

1. Instalación
2. Configuración de git para utilizar el analizador
3. Ajustes de estilos. Podemos querer adaptarlo a nuestra necesidades (de empresa).
4. Probarlo: bash git commit -m"style fix google" Comenzando auditoría... Auditoría concluida. [main e0eaeed] style fix google 1 file changed, 128 insertions(+), 105 deletions(-) rewrite Palindromos.java (96%)

Podemos ver en las líneas 2 y 3 que realiza la auditoría de código y la pasa sin warnings.

En este punto, podría ser interesante plantearnos si deberá pasar los test antes de los commits, después o antes del push.

Post-receive

Utilizado para CI/CD... lo veremos ampliamente más adelante.

Referencias:

• Documentación OFICIAL -> Git reference manual y en español
• David Poza
• Manuel Cillero
• Vídeos aclarativos -> PildorasInformáticas 1-5, 10-11
• Pelao Nerd - 1 y Pelao - 2

Notas al pie

[^1]: Es un sistema de acceso a nuestro repositorio que se genera un token con los permisos necesarios a el repositorio adecuado y con fecha de caducidad, lo cual otorga bastante seguridad. [Información sobre acceso por token]. [^2]: Puede haber otros servidores interesantes, p.e. gitlab, gitbucket, o el vuestro privado.