Para la creación y desarrollo de la presente práctica se ha usado Git Flow.
Primeramente se debe crear un repositorio remoto en cualquier alojador de proyecto Git.
Los comandos de Git Flow que se usaron, son los siguientes:
Para iniciar el el repositorio git se usa el siguiente comando:
git init
Para la utilización del flujo de trabajo Git Flow se usa el siguiente comando:
git flow init
Agregar -d para que cree todas las ramas por defecto, sin necesidad de aceptar línea a línea.
Se realiza un commit de la configuración inicial del proyecto.
Realizar conexión entre repositorio local y repositorio remoto, para que los cambios puedan ser accedidos por todos los colaboradores.
Se envía el commit de la configuración inical al repositorio remoto, ejecutando:
git push orogin develop
Ahora ya puede comenzar a crear y usar las ramas feature.
git flow feature start nombre para crear la rama.
Terminados los cambios, se realiza una publicación de los cambios usando git push y en caso de no ejecutarse correctamente se debe usar git flow feature publish nombre que, básicamente, sirve para publicar en repositorio remoto.
Para finalizar la rama basta con ejecutar git flow feature finish nombre, con este comando lo que internamente realiza para git son las siguientes instrucciones: git checkout develop
git merge --no-ff feature/nombre
git checkout -d feature/nombre
Esto consiste en enviar los cambios a develop y desechar la rama, dado que su vida útil ha terminado.
Rama para empaquetar develop y enviarla a master
Una vez se haya completado una versión estable, se subirá una copia a master
Para crear una rama release se debe ejecutar git flow release start numeroVersion
En este punto se revisa si se necesita realizar ajustes antes de ser enviado a fase de producción. Seguido, se puede finalizar usando got flow release finish numeroVersion, automáticamente apareceran 3 ventanas que se deben completar (si se desea saber mas visitar Git Flow).
En la primer ventana, se agrega el mensaje del merge a la rama master
En lugar de esta línea, si no usaramos git flow, deberiamoms ejecutar:git checkout master
Subir todos los cambios a master git merge --no-ff release/numeroVersion
Crear etiqueta git tag -a numeroVersion
git checkout develop
Realizar merge en develop git merge --no-ff release/numeroVersion
Con esto ya se debe eliminar la rama git branch -d release/numeroVersion.
Para concluir el proceso de release.
Subir estos cambios al repositorio remoto: git pull origin develop
Ubicarse en master git checkout master y realizar un git pull --alow-unrelated-histories
Las etiquetas deben ser publicadas usando git push origin --tags
En el repositorio remoto, aparecen las versiones estables que se hayan agregado, listas para ser descargadas. Estan identificadas con sus respectivos tags
Esta rama se utiliza cuando se presentan bugs en la fase de producción y deben ser corregidos.
Para inicializarla, basta con ejecutar: git flow hotfix start numeroSubversion (numeroSubversion será como etiquete a la nueva versión corregida del proyecto).
Una vez terminada la corrección se termina la rama insertando la siguiente instrucción: git flow hotfix finish numeroSubversion con esto aparece una ventana donde se agrega un mensaje para referenciar etiqueta.
La siguiente ventana que aparece, realiza un merge a develop.
El resultado terminado esto, deberá verse similar a los que se presenta a continuación.
Para publicarlas a repositorio remoto se repite el proceso aplicada a la rama release ejecutando: git push origin developgit push origin mastergit push origin --tags
En el repositorio remoto se verá de la siguiente manera.
Desde la consola se optione un árbol de trabajo a partir de git log que nos muestra todos los cambios realizados sobre el repositorio, pero para que aparezca un poco más ordenado se ejecuta git log --all --decorate --oneline --graph
Usando un software administrador de git, en este caso, GitKraken, es así como se puede visualizar el flujo de trabajo
Estas instrucciones sirven para traer los commits de una rama a otra.
| Merge | Rebase |
|---|---|
| Deja el árbol de cambios con sus respectivas ramas | Unifica las ramas que se van a combinar dejando un árbol de cambios lineal |
| Cuando queremos unificar los cambios, es necesario realizar un commit más, el cual puede llegar a ser hasta innecesario | No tiene la necesidad de hacer un nuevo commit |
| No pierde el historial de los commits | Si pierde el historial de los commit, lo cual puede llegar a ser una desventaja |
| Mantiene los commits por separado | Monta los commits encima de la otra rama, sin importar la cronología |