Professional Documents
Culture Documents
Workshop Gitflow I: Introducción
Workshop Gitflow I: Introducción
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:
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 a partir de un commit u otra rama distinta:
git branch <new-branch> [<existing-branch>|<commit>]
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>
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
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>]
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.
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.
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.
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.
Ejercicio
● Hacer una etiqueta con una versión llamada “v1.0.0<país>/<id_usuario>” y subir la
etiqueta al servidor.
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.