Workshop​ ​Gitflow​ ​I

Versión​ ​1.0

Introducción
El​ ​objetivo​ ​de​ ​este​ ​workshop​ ​es​ ​entender​ ​la​ ​filosofía​ ​y​ ​estructura​ ​del​ ​control​ ​de
versiones​ ​Git.​​ ​Aunque​ ​el​ ​uso​ ​de​ ​herramientas​ ​gráficas​ ​como​ ​SmartGit​ ​o​ ​SourceTree
facilitan​ ​el​ ​manejo​ ​Git,​ ​se​ ​usará​ ​exclusivamente​ ​la​ ​consola​ ​para​ ​entender​ ​los​ ​comandos
específicos.

Esta​ ​práctica​ ​consta​ ​de​ ​varios​ ​ejercicios​ ​simples​ ​en​ ​los​ ​que​ ​durante​ ​un​ ​corto​ ​periodo​ ​de
tiempo​ ​se​ ​deja​ ​a​ ​los​ ​asistentes​ ​la​ ​búsqueda​ ​de​ ​la​ ​solución​ ​de​ ​manera​ ​individual,
respondiendo​ ​a​ ​las​ ​dudas​ ​y​ ​problemas​ ​que​ ​se​ ​vayan​ ​encontrando.​ ​Una​ ​vez​ ​transcurrido​ ​el
tiempo,​ ​se​ ​explicará​ ​la​ ​solución​ ​a​ ​todo​ ​el​ ​público.

Requisitos​ ​previos:

● Tener​ ​instalada​ ​la​ ​versión​ ​2.0​ ​de​ ​Git​ ​o​ ​superior.

● Seguir​ ​los​ ​pasos​ ​del​ ​documento​ ​de​ ​configuración​ ​del​ ​PC​.
● Nociones​ ​básicas​ ​de​ ​shell​ ​(​vim​,​ ​mkdir,​ r​ m​,​ ​cd​,​ ​ls,​ ​touch,​ ​etc)

Notas
Aunque​ ​Git​ ​permite​ ​apuntar​ ​a​ ​varios​ ​repositorios​ ​remotos​ ​(lo​ ​que​ ​implica​ ​que​ ​para​ ​muchos
comandos​ ​se​ ​puede​ ​especificar​ ​el​ ​repositorio​ ​remoto​ ​que​ ​se​ ​usará),​ ​para​ ​simplificar​ ​este
taller​ ​sólo​ ​se​ ​tendrá​ ​en​ ​cuenta​ ​un​ ​repositorio​ ​remoto.
Control​ ​de​ ​ramas
Creando​ ​ramas:​ ​git​ ​branch
Una​ ​rama​ ​representa​ ​una​ ​línea​ ​independiente​ ​de​ ​desarrollo​ ​aislada,​ ​proporcionando​ ​un
espacio​ ​nuevo​ ​de​ ​trabajo,​ ​staging​ ​area​ ​e​ ​historia.​ ​Los​ ​nuevos​ ​commits​ ​son​ ​grabados​ ​en​ ​la
historia​ ​de​ ​la​ ​rama.
El​ ​comando​ g​ it​ ​branch​​ ​nos​ ​permite​ ​crear,​ ​listar,​ ​renombrar​ ​y​ ​borrar​ ​ramas.

Uso
listar​ ​ramas:
git​ ​branch

Para​ ​crear​ ​una​ ​rama​ ​desde​ ​la​ ​rama​ ​actual:

git​ ​branch​ ​<branch>

Para​ ​crear​ ​una​ ​rama​ ​a​ ​partir​ ​de​ ​un​ ​commit​ ​u​ ​otra​ ​rama​ ​distinta:
git​ ​branch​ ​<new-branch>​ ​[<existing-branch>|<commit>]

Para​ ​borrar​ ​una​ ​rama​ ​(de​ ​forma​ ​segura):

git​ ​branch​ ​-d​ ​<branch>

Para​ ​forzar​ ​la​ ​eliminación​ ​de​ ​una​ ​rama​ ​incluso​ ​cuando​ ​los​ ​cambios​ ​no​ ​han​ ​sido​ ​fusionados
en​ ​otra​ ​rama​ ​(desechar​ ​los​ ​cambios):
git​ ​branch​ ​-D​ ​<branch>

Para​ ​eliminar​ ​una​ ​rama​ ​remota:

git​ ​push​ ​origin​ ​--delete​ ​<branch>
...o...
git​ ​push​ ​origin​ ​:<branch>

Para​ ​renombrar​ ​la​ ​rama​ ​actual:

git​ ​branch​ ​-m​ ​<branch>

Acerca​ ​de​ ​las​ ​ramas

Es​ ​importante​ ​entender​ ​que​ ​una​ ​rama​ ​es​ ​simplemente​ ​un​ ​puntero​ ​a​ ​un​ ​commit.​ ​Es​ ​decir,
cuando​ ​se​ ​crea​ ​una​ ​rama,​ ​git​​ ​crea​ ​un​ ​nuevo​ ​puntero​ ​a​ ​ese​ ​commit.
git​ ​branch​ ​crazy-experiment

Una​ ​vez​ ​terminado​ ​el​ ​trabajo​ ​en​ ​la​ ​rama​ ​se​ ​puede​ ​borrar.​ ​En​ ​el​ ​caso​ ​de​ ​que​ ​la​ ​rama​ ​no
haya​ ​sido​ ​fusionada​ ​se​ ​produce​ ​un​ ​error​ ​al​ ​intentar​ ​eliminarla:
git​ ​branch​ - ​ d​ ​crazy-experiment
error:​ ​The​ b ​ ranch​ ​'crazy-experiment'​ ​is​ ​not​ ​fully​ ​merged.
If​ ​you​ ​are​ s ​ ure​ ​you​ ​want​ ​to​ ​delete​ ​it,​ ​run​ ​'git​ ​branch​ ​-D​ ​crazy-experiment'.

Esto​ ​protege​ ​de​ ​la​ ​pérdida​ ​de​ ​la​ ​referencia​ ​a​ ​esos​ ​commits,​ ​lo​ ​cual​ ​significa​ ​perder​ ​el
acceso​ ​a​ ​esa​ ​la​ ​línea​ ​de​ ​desarrollo.

Si​ ​se​ ​quieren​ ​desechar​ ​los​ ​cambios​ ​de​ ​la​ ​rama,​ ​se​ ​ha​ ​de​ ​usar​ ​el​ ​modificador​ ​-D:
git​ ​branch​ ​-D​ ​crazy-experiment

Seleccionar​ ​ramas:​ ​git​ ​checkout

El​ ​comando​ ​git​ ​checkout​​ ​permite​ ​apuntar​ ​el​ ​espacio​ ​de​ ​trabajo​ ​a​ ​diferentes​ ​ramas​ ​o
commits.​ ​Al​ ​hacer​ ​checkout​ ​a​ ​una​ ​rama​ ​se​ ​actualizan​ ​los​ ​ficheros​ ​en​ ​el​ ​directorio​ ​de​ ​trabajo
para​ ​que​ ​coincida​ ​con​ ​la​ ​versión​ ​almacenada​ ​en​ ​esa​ ​rama.​ ​A​ ​partir​ ​de​ ​ese​ ​momento,​ ​todos
los​ ​cambios​ ​se​ ​producirán​ ​en​ ​esa​ ​rama.

Uso
Para​ ​usar​ ​una​ ​rama:
git​ ​checkout​ ​<existing-branch>
Para​ ​crear​ ​y​ ​usar​ ​una​ ​rama​ ​a​ ​partir​ ​de​ ​la​ ​actual:
git​ ​checkout​ ​-b​ ​<new-branch>

Para​ ​crear​ ​y​ ​usar​ ​una​ ​rama​ ​a​ ​partir​ ​de​ ​otra​ ​o​ ​de​ ​un​ ​commit:
git​ ​checkout​ ​-b​ ​<new-branch>​ ​[<existing-branch>|<commit>]

Ejercicio:​ ​Eliminar​ ​y​ ​volver​ ​a​ ​crear​ ​una​ ​rama

1. Crear​ ​una​ ​nueva​ ​rama​ ​desde​ ​master​ ​llamada​ f​ eature-delete-feature​​ ​y​ ​hacer
checkout​ ​de​ ​esta​ ​rama.
2. Crear​ ​un​ ​commit​ ​añadiendo​ ​un​ ​nuevo​ ​fichero,​ ​por​ ​ejemplo:
file_on_feature_delete_feature
3. Borrar​ ​la​ ​rama​ ​feature-delete-feature​​ ​localmente.
4. Volver​ a​ ​ ​generar​ ​la​ ​rama​ ​feature​ ​a​ ​partir​ ​del​ ​commit,​ ​verificando​ ​que​ ​el​ ​contenido​ ​de
feature​ ​incluye​ ​el​ ​fichero​ ​file_on_feature_delete_feature​.

Se​ ​puede​ ​usar​ ​el​ ​comando​ ​git​ ​log​ ​--oneline​ ​--graph​ ​--decorate​​ ​para​ ​ver​ ​la​ ​historia.
Descargando​ ​cambios​ ​de​ ​otros​ ​en​ ​una​ ​rama:​ ​git​ ​pull
Si​ ​otra​ ​persona​ ​sube​ ​cambios​ ​en​ ​la​ ​rama​ ​en​ ​la​ ​que​ ​estás​ ​trabajando,​ ​antes​ ​de​ ​poder​ ​subir
tus​ ​cambios​ ​vas​ ​a​ ​tener​ ​que​ ​fusionar​ ​los​ ​ya​ ​subidos​ ​al​ ​repositorio​ ​remoto.

Para​ ​fusionar​ ​los​ ​cambios​ ​subidos​ ​al​ ​repositorio​ ​remoto​ ​en​ ​tu​ ​rama​ ​local:
git​ ​pull

Git​ ​intentará​ ​hacer​ ​un​ ​mezclado​ ​automático​ ​de​ ​los​ ​cambios​ ​existentes.​ ​Sin​ ​embargo,​ ​en
ocasiones​ ​se​ ​producirán​ ​conflictos​ ​que​ ​han​ ​de​ ​resolverse​ ​manualmente.​ ​Para​ ​ello,​ ​hay
herramientas​ ​que​ ​facilitan​ ​la​ ​resolución​ ​de​ ​conflictos.

Compartiendo​ ​cambios:​ ​git​ ​push

Además​ ​de​ ​otras​ ​muchas​ ​acciones,​ ​Git​ ​permite​ ​subir​ ​los​ ​cambios​ ​realizados​ ​en​ ​una​ ​rama
de​ ​código.

Para​ ​enviar​ ​los​ ​cambios​ ​realizados​ ​en​ ​una​ ​rama​ ​de​ ​código​ ​a​ ​la​ ​misma​ ​rama​ ​de​ ​código​ ​del
repositorio​ ​remoto:
git​ ​push

En​ ​el​ ​caso​ ​de​ ​que​ ​algún​ ​otro​ ​desarrollador​ ​haya​ ​subido​ ​cambios​ ​al​ ​repositorio​ ​remoto​ ​en
esa​ ​misma​ ​rama,​ ​git​ ​indicará​ ​que​ ​no​ ​es​ ​posible​ ​enviar​ ​esos​ ​cambios​ ​y​ ​será​ ​necesario​ ​traer
los​ ​cambios​ ​remotos.

Realizando​ ​peticiones​ ​de​ ​cambio:​ ​Pull​ ​Request

El​ ​mecanismo​ ​de​ ​Pull​ ​Requests​ ​permite​ ​revisar​ ​los​ ​cambios​ ​que​ ​se​ ​han​ ​producido​ ​en​ ​un
rama​ ​de​ ​código​ ​antes​ ​de​ ​ser​ ​mezclada​ ​con​ ​otra​ ​rama.​ ​Es​ ​una​ ​práctica​ ​habitual​ ​en​ ​ciertos
repositorios​ ​de​ ​código​ ​mundiales​ ​(como​ ​GitHub​ ​o​ ​GitLab)​ ​y​ ​sirve​ ​principalmente​ ​para
mejorar​ ​la​ ​calidad​ ​de​ ​código.

Una​ ​vez​ ​que​ ​la​ ​funcionalidad​ ​está​ ​codificada,​ ​ha​ ​sido​ ​suficientemente​ ​probada​ ​y​ ​se​ ​ha
hecho​ ​push​ ​al​ ​repositorio​ ​remoto,​ ​se​ ​puede​ ​iniciar​ ​el​ ​procedimiento​ ​de​ ​Pull​ ​Request.

Para​ ​ello​ ​hay​ ​dos​ ​formas:

1. Copiar​ ​y​ ​pegar​ ​en​ ​un​ ​navegador​ ​web​ ​la​ ​URL​ ​que​ ​muestra​ ​el​ ​repositorio​ ​remoto​ ​de
Bitbucket,​ ​siempre​ ​y​ ​cuando​ ​esté​ ​configurado​ ​para​ ​que​ ​muestre​ ​un​ ​mensaje​ ​remoto
con​ ​el​ ​enlace​ ​para​ ​crear​ ​la​ ​pull​ ​request.​ 1​

1
​ ​Ver:
https://confluence.atlassian.com/stashkb/how-do-i-disable-the-remote-create-pull-request-message-w
hen-pushing-changes-701268506.html
 2. Desde​ ​Bitbucket,​ ​entrando​ ​en​ ​el​ ​repositorio​ ​en​ ​el​ ​que​ ​se​ ​quiere​ ​hacer​ ​la​ ​Pull​ ​Request
y​ ​posteriormente​ ​pulsando​ ​el​ ​botón​ ​“Create​ ​Pull​ ​Request”​ ​de​ ​la​ ​botonera​ ​de​ ​la
izquierda.

Independientemente​ ​de​ ​la​ ​opción​ ​elegida​ ​se​ ​llega​ ​a​ ​la​ ​misma​ ​pantalla,​ ​en​ ​la​ ​que​ ​es
necesario​ ​elegir​ ​qué​ ​ramas​ ​se​ ​quieren​ ​integrar:

Una​ ​vez​ ​elegidas​ ​las​ ​ramas,​ ​se​ ​pulsará​ ​el​ ​botón​ ​“Continue”​ ​y​ ​se​ ​rellenan​ ​los​ ​campos​ ​de
título​ ​y​ ​descripción.​ ​Este​ ​suele​ ​ser​ ​el​ ​momento​ ​adecuado​ ​también​ ​para​ ​incluir​ ​los​ ​revisores
que​ ​aprobarán​ ​la​ ​Pull​ ​Request:
El​ ​sistema​ ​envía​ ​una​ ​notificación​ ​automática​ ​(en​ ​forma​ ​de​ ​correo)​ ​a​ ​todos​ ​los​ ​revisores
indicados,​ ​para​ ​que​ ​sepan​ ​que​ ​hay​ ​una​ ​nueva​ ​Pull​ ​Request​ ​que​ ​requiere​ ​su​ ​atención​ ​y
revisión.

Las​ ​personas​ ​encargadas​ ​deberán​ ​leer​ ​el​ ​código​ ​y​ ​anotar​ ​comentarios​ ​en​ ​las​ ​líneas​ ​que
necesiten​ ​ser​ ​revisadas​ ​o​ ​explicadas.

Tras​ ​una​ ​revisión​ ​de​ ​la​ ​calidad​ ​del​ ​código,​ ​la​ ​Pull​ ​Request​ ​se​ ​podrá:
● Aprobar.
● Declinar​ ​(esto​ ​es​ ​algo​ ​no​ ​que​ ​generalmente​ ​no​ ​debería​ ​ocurrir).
● Marcar​ ​para​ ​trabajar​ ​en​ ​ella,​ ​teniendo​ ​en​ ​cuenta​ ​los​ ​comentarios​ ​generados​ ​en​ ​el
proceso​ ​de​ ​revisión.

Es​ ​importante​ ​entender​ ​que​ ​este​ ​proceso​ ​de​ ​revisión​ ​sirve​ ​para​ ​mejorar​ ​el​ ​código​ ​y​ ​no
debería​ ​usarse​ ​para​ ​despreciar​ ​el​ ​código​ ​ajeno​ ​ni​ ​imponer​ ​unos​ ​criterios​ ​subjetivos​ ​(estilo
de​ ​código​ ​debatibles​ ​y​ ​similar).

Ejercicio
● Hacer​ ​una​ ​pull​ ​request​ ​de​ ​una​ ​rama​ ​que​ ​haya​ ​sido​ ​subida​ ​al​ ​servidor​ ​para​ ​mezclarla
con​ ​la​ ​rama​ ​develop.
Etiquetando​ ​versiones:​ ​git​ ​tag
El​ ​etiquetado​ ​es​ ​algo​ ​fundamental​ ​para​ ​identificar​ ​las​ ​diferentes​ ​versiones​ ​de​ ​código,
especialmente​ ​las​ ​desplegadas​ ​a​ ​producción.​ ​Hay​ ​dos​ ​tipos​ ​de​ ​etiquetas:​ ​simples​ ​y
anotadas.​ ​Las​ ​simples​ ​(lightweight)​ ​sólo​ ​contienen​ ​el​ ​identificador​ ​de​ ​la​ ​etiqueta,​ ​mientras
que​ ​las​ ​anotadas​ ​añaden​ ​un​ ​texto​ ​descriptivo.

Para​ ​listar​ ​todas​ ​las​ ​etiquetas​ ​del​ ​repositorio:

git​ ​tag

Para​ ​añadir​ ​una​ ​etiqueta​ ​simple​ ​al​ ​commit​ ​actual:

git​ ​tag​ ​<id_tag>

Para​ ​compartir​ ​las​ ​etiquetas​ ​con​ ​el​ ​repositorio​ ​remoto:

git​ ​push​ ​--tags

Ejercicio
● Hacer​ ​una​ ​etiqueta​ ​con​ ​una​ ​versión​ ​llamada​ ​“v1.0.0<país>/<id_usuario>”​ ​y​ ​subir​ ​la
etiqueta​ ​al​ ​servidor.

Actualizando​ ​las​ ​referencias​ ​de​ ​las​ ​ramas​ ​desde​ ​el​ ​repositorio

remoto:​ ​git​ ​fetch
Debido​ ​a​ ​la​ ​naturaleza​ ​distribuida​ ​de​ ​Git,​ ​podemos​ ​trabajar​ ​en​ ​local​ ​de​ ​manera
independiente​ ​hasta​ ​que​ ​necesitemos​ ​interactuar​ ​con​ ​el​ ​repositorio​ ​remoto.​ ​Durante​ ​este
tiempo,​ ​otros​ ​desarrolladores​ ​pueden​ ​haber​ ​creado​ ​nuevas​ ​ramas​ ​(o​ ​etiquetas)​ ​en​ ​el
repositorio​ ​remoto.​ ​Sin​ ​embargo,​ ​en​ ​nuestro​ ​repositorio​ ​no​ ​vamos​ ​a​ ​tener​ ​constancia​ ​de
estas​ ​ramas​ ​ni​ ​de​ ​los​ ​hasta​ ​que​ ​nos​ ​hayamos​ ​traído​ ​esta​ ​información.

Para​ ​obtener​ ​los​ ​nombres​ ​de​ ​las​ ​nuevas​ ​ramas​ ​(o​ ​etiquetas)​ ​del​ ​repositorio​ ​remoto:
git​ ​fetch

Ejercicio​ ​7
● Crear​ ​una​ ​rama​ ​nueva​ ​con​ ​el​ ​siguiente​ ​nombre:​ ​feature-fetch-<userID>​.​ ​Ejemplo:
feature-fetch-A040123​.
● Crear​ ​un​ ​nuevo​ ​fichero,​ ​añadirlo​ ​al​ ​área​ ​de​ ​trabajo​ ​(a​ dd​),​ ​hacer​ ​commit​ ​y​ ​subirlo​ ​al
repositorio​ ​remoto​ ​(p​ ush​).
● Una​ ​vez​ ​que​ ​todos​ ​los​ ​participantes​ ​del​ ​workshop​ ​hayan​ ​subido​ ​sus​ ​ramas​ ​al
repositorio,​ ​traer​ ​las​ ​referencias​ ​de​ ​las​ ​nuevas​ ​ramas​ ​a​ ​la​ ​copia​ ​local.
Deshaciendo​ ​los​ ​cambios:​ ​git​ ​checkout​ ​--,​ ​git​ ​reset
Durante​ ​la​ ​codificación​ ​de​ ​una​ ​nueva​ ​funcionalidad​ ​es​ ​posible​ ​que​ ​queramos​ ​deshacer
todos​ ​los​ ​cambios​ ​realizados​ ​en​ ​un​ ​determinado​ ​fichero.

Para​ ​deshacer​ ​los​ ​cambios​ ​de​ ​un​ ​fichero​ ​si​ ​no​ ​se​ ​han​ ​hecho​ ​commit​ ​del​ ​cambio:
git​ ​checkout​ ​--​ ​<filename>

Para​ ​quitar​ ​del​ ​área​ ​de​ ​trabajo​ ​(​staging​ ​area​),​ ​manteniendo​ ​los​ ​cambios​ ​en​ ​el​ ​directorio​ ​de
trabajo:
git​ ​reset​ ​HEAD​ ​<filename>

Ejercicio
● Modificar​ ​un​ ​fichero​ ​ya​ ​existente​ ​y​ ​volver​ ​a​ ​recuperar​ ​su​ ​contenido​ ​como​ ​estaba,
usando​ ​comandos​ ​de​ ​Git.

Ejercicio
● Modificar​ ​un​ ​fichero​ ​ya​ ​existente,​ ​añadirlo​ ​al​ ​Stage​ ​Area​ ​y​ ​posteriormente​ ​sacarlo.