Ejercicios git

Básico

  1. Configura tu instalación de git globalmente. Añade tu username, tu email y editor favorito
  2. Usando git init, crea un repositorio de git a partir de una carpeta que contenga dos archivos; README.txt y calc.c. El contenido de estos archivos es irrelevante para el objetivo del ejercicio.
  1. Comprueba el estado del repositorio recién creado.
  2. Añade todos los ficheros al área de staging y comprueba el estado del repositorio.
  3. Haz un commit de los ficheros y comprueba el estado del repositorio.
  4. Crea dos nuevos ficheros: button.c y config.json y comprueba el estado del repositorio.
  5. Modifica los archivos button.c y README.txt, añadelos al área de staging y comprueba el estado del repositorio.
  6. Realiza un commit y comprueba el estado del repositorio.
  7. Modifica el fichero calc.c,  añadelo al área de staging y comprueba el estado del repositorio.
  8. Vuelve a modificar el fichero calc.c y y comprueba el estado del repositorio. Observa que el fichero está en dos áreas. ¿Porqué?
  9. Haz commit del fichero calc.c. ¿Se han confirmado todas las modificaciones realizadas al archivo?
  1. Comprueba el efecto del fichero especial .gitignore añadiendo a él un directorio denominado dependencias. Crea para ello un directorio con ese nombre y añade algunos archivos a él. Intenta añadir ese directorio al área de staging. Quita ese directorio del fichero .gitignore y añade ese directorio de nuevo al área de staging y comprueba qué ocurre.
  2. Comprueba el funcionamiento del comando git diff.
  1. Modifica los archivos calc.c y button.c
  2. Añade al área de staging el fichero calc.c
  3. Comprueba las diferencias entre esos ficheros y la última versión de los mismos en el repositorio.
  1. Borrando y recuperando ficheros
  1. Asegurate que todos los archivos del proyecto están confirmados
  2. Borra directamente usando el comando de borrado de ficheros de tu terminal el fichero calc.c
  3. Comprueba el estado y recupéralo de nuevo.
  4. Borra directamente el fichero README.txt y pásalo al área de staging. Comprueba el estado y recupéralo de nuevo.
  5. Borra el fichero button.c usando el comando git rm, comprueba el estado y recupéralo de nuevo.
  1. Modifica el fichero button.c y confírmalo. Una vez confirmado cambia el mensaje de log.
  2. Modifica el fichero calc.c y confírmalo. Una vez confirmado modifica el fichero button.c y confirmalo en el mismo commit anterior.
  3. Haz un clonado del proyecto Symfony (https://github.com/symfony/symfony) y muestra:
  1.  Un listado de todas las confirmaciones.
  2. Un listado de todas las confirmaciones que muestre las diferencias introducidas en cada una de ellas
  3. Un listado con las 3 últimas confirmaciones.
  4. Un listado con las confirmaciones en una sola línea
  5. Un listado con las confirmaciones en el que se muestre el email del autor y la fecha

Remotos

  1. Create una cuenta en gitlab.com y crea un nuevo repositorio
  2. Añade el repositorio que acabas de crear como remoto del repositorio que has creado en el ejercicio 2.
  3. Sincroniza el código con el remoto. Es decir,
  1. Añade la rama master de tu repositorio al remoto (git push origin master).
  2. Modifica los ficheros button.c y README.txt, confírmalos y envía al remoto los cambios (git push origin master).
  1. Ahora vamos a hacer lo mismo que en 11 pero de una manera más adecuada para simplificar las operaciones pull y push.
  1. Borra el remoto origin (git remote remove origin)
  2. Crea otro repositorio en gitlab
  3. Añade de nuevo la rama master de tu repositorio al remoto pero esta vez con la opción -u (git push -u origin master).
  4. Modifica los ficheros button.c y README.txt, confírmalos y envía al remoto los cambios (ahora solo hace falta hacer git push).
  1. En este ejercicio estudiarás como varios colaboradores pueden trabajar conjuntamente sobre un mismo remoto. Clona el repositorio remoto que acabas de crear en dos directorios distintos. Llámalos proyecto1 y proyecto2, por ejemplo.
  1. Entra en proyecto1 y modifica los archivos button.c y calc.c. Confírmalos.
  2. Entra en proyecto2 y modifica el archivo README.txt. Confírmalo y súbelo al repositorio remoto (git push).
  3. Cambia de nuevo al repositorio proyecto1 y sube las confirmaciones que hiciste en a al repositorio remoto. Verás que no puedes. ¿Porqué?
  4. Traete los cambios realizados y sincronizados con el remoto en el repositorio proyecto2 a proyecto1 (git fetch).
  5. Mezcla los cambios que te has traído con el repositorio proyecto1
  6. Vuelve a repetir los apartados a, b y c, pero en lugar de hacer fetch y merge, como en los apartados d y e, haz las dos cosas juntas con git pull.
  1. En este ejercicios comprobarás como podemos tener asociados varios remotos a un mismo repositorio local.
  1. Haz un clon del siguiente repositorio: https://gitlab.com/juandalibaba/parejas
  2. Comprueba que en esa operación se ha creado un remoto con nombre origin
  3. Crea en tu cuenta de gitlab un repositorio nuevo. Puedes llamarle parejas.
  4. Añade ese repositorio recién creado a los remotos del repositorio local que has clonado.
  5. Envía el código al repositorio que has creado.
  6. Realiza algún cambio en el código y envíalo al repositorio que tú has creado.
  7. Intenta enviar los cambios también al repositorio original.
  8. Habrás visto que no puedes enviar cambios al repositorio original pues no tienes permisos de escritura. Para que no tengas que hacer cada vez que quieras enviar cambios a tu repositorio remoto git push <tu_remoto> master, convierte la rama master de este remoto en la upstream de la rama master local (git branch -u <tu_remoto>/master).

Etiquetas

  1. Etiquetas anotadas vs. no anotadas
  1. Realiza un cambio sobre el archivo button.c, confirmalo y crea una etiqueta anotada sobre ese commit.
  2. Realiza un cambio sobre el archivo button.c, confirmalo y crea una etiqueta no anotada sobre ese commit.
  3. Comprueba las diferencias entre ambas formas de etiquetar usando git show nombre_tag
  1. Etiqueta alguno de los commits anteriores y comprueba que está bien anotado usando git log.
  2. Envía las etiquetas al repositorio remoto.
  3. Coloca la copia de trabajo en el commit correspondiente a una de las etiquetas que has creado (git checkout nombre_etiqueta). Lee atentamente el mensaje que aparece al realizar la operación.
  4. Realiza algunos cambios y haz commit. Visualiza el estado completo con git log --oneline --all. Apunta el nº de commit en que estás.
  5. Ahora vuelve a la rama master y lee atentamente el mensaje que aparece al realizar la operación. Vuelve a ver el estado. ¿Qué ha pasado con el commit anterior?.
  6. Un comando muy útil para visualizar el estado de un repositorio es git log --oneline --graph --all. Como es un poco largo, añade un alias, por ejemplo logc, para ejecutarlo sin necesidad de escribir el comando completo.

Ramas

Para realizar estos ejercicios es muy útil el uso de los siguientes comandos:

git log --oneline --graph --all, que muestra las confirmaciones indicando la o las confirmaciones padre y,

gitk, que es una herramienta gráfica para examinar el repositorio.

  1. Clona un proyecto sobre el que puedas escribir (por ejemplo el del ejercicio 14).
  2. Crea una rama para investigar una idea nueva. Cambiate a esa rama y realiza algunos cambios. Confirma todos los cambios realizados (commit).
  3. Supón que los cambios que has hecho en la rama de investigación resultan adecuados para el desarrollo y quieres incorporarlos a la rama master. Vuelve a la rama master y fusiona con la rama de investigación. ¿Qué ha pasado? Explica sobre papel, con diagramas, la evolución del árbol de confirmaciones y, a la luz de ese diagrama reflexiona acerca del término fast forward.
  4. Elimina la rama de investigación.
  5. Ahora tienes que resolver urgentemente un bug en la rama master. Crea una rama para realizar esa tarea y realiza algunos cambios sobre ella.
  6. Mientras tanto alguien del equipo ha enviado algunos cambios a la rama master. Simula esta situación cambiando a la rama master, realizando algunos cambios sobre ella y confirmándolos.
  7. Ahora fusiona la rama master con la rama del bug. Puede ser que en la fusión ocurra algún que otro conflicto. Resuélvelos en tal caso. Explica sobre papel, con diagramas, la evolución del árbol de confirmaciones y, a la luz de ese diagrama reflexiona acerca del proceso de fusión.
  8. Elimina la rama de bugs.
  9. Ahora supón que se desea abrir una rama para la implementación de una nueva funcionalidad, y el origen de la rama resulta ser un commit anterior al último (por ejemplo dos commits antes). Realiza dicha operación y modifica y confirma varios cambios.
  10. Ahora fusiona sobre la rama master los cambios realizados en la rama anterior.
  11. La operación de clonado automáticamente crea un remoto denominado origin, una rama de seguimiento remoto denominada origin/master y una rama local de seguimiento denominada master cuyo up stream es origin/master. Comprueba que todo esto es así.
  12. Clona de nuevo el mismo repositorio en otro directorio. Entra en él y crea una nueva rama. Haz varias modificaciones sobre ella, confírmalas y súbelas al repositorio. Esto simula a un colaborador que ha modificado el remoto añadiendo una nueva rama.
  13. Vuelve al directorio original y comprueba la lista de todas las ramas (locales y de seguimiento remoto) con git branch -a. Traete todos los cambios del repomo con git fetch y vuelve a listar las ramas.
  14. Crea una nueva rama que se llame de manera distinta al nombre de la rama remota que acabas de traerte. Cambiate a esa rama y fusiona la rama de seguimiento remoto sobre ella. Esta rama coincide con
  15. Intenta enviar los cambios al remoto con git push. ¿Qué ocurre?.
  16. Para que puedas enviar los cambios al remoto debes hacer git push origin <nombre_de_tu_rama>, con lo cual en el remoto vamos a tener dos ramas distintas que se refieren a la misma línea de desarrollo. Lo cual significa “follón” asegurado.
  17. Para hacer bien el punto 35, basta que al crear la rama le pongamos el nombre de la rama de seguimiento remoto. Entonces esta se convertirá en upstream de nuestra rama local y todas las operaciones de push y pull estarán claramente definidas. Házlo y compruebalo.
  18. Este es un buen momento para repasar todo lo que hemos hecho hasta ahora. Ejecuta la herramienta gitk e interpreta el árbol de confirmaciones.