Diferencias

Muestra las diferencias entre dos versiones de la página.

--- informatica:programacion:cursos:control_version_git_avanzado:branching [2023/05/29 11:13] – creado tempwin
+++ informatica:programacion:cursos:control_version_git_avanzado:branching [2023/06/03 16:41] (actual) – [Fusionando código: merge, rebase y cherry-pick] tempwin
@@ Línea 1: / Línea 1: @@
 ====== Branching ======
+Sección perteneciente al curso [[informatica:programacion:cursos:control_version_git_avanzado|Control de versiones con Git Avanzado]].
 ===== Introducción =====
+Las ramas en git no son más que una referencia que apunta a un commit.
+Para nosotros, por comodidad, es más recomendable pensar en las ramas como itinerarios de commits.
+El modelo de trabajo será normalmente:
+  - Abrir nueva rama
+  - Trabajar en ella
+  - La volcamos en la rama principal
+  - Borramos la rama
+  - Abrir nueva rama
+  - Trabajar en ella
+  - La volcamos en la rama principal
+  - Borramos la rama
+  - ...
+Veremos la metodología **git flow**.
 ===== El modelo de ramas de Git =====
+Tenemos dos concepciones de ramas, una más "humana" que sería un **itinerario de commits** (la rama apunta al último commit de dicho itinerario); y otra "técnica" donde una rama no es más que una referencia a un commit.
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-ramas.png?nolink |}}
+Esto hace que sea muy cómodo trabajar con ramas porque es muy fácil movernos entre ellas al ser un "cartelito" en lugar de números y letras (commit).
+<WRAP center round info 60%>
+Un commit no tiene información sobre a qué rama pertenece.
+</WRAP>
+Recordemos: una rama es una referencia a un commit.
+La **rama master** se crea automáticamente al iniciar un repositorio git.
+Cuando HEAD apunta a una rama, al hacer un commit, avanza HEAD y esto hace que la rama también avance con él.
+Cuando decimos, por ejemplo, que estamos en **master** estamos queriendo decir que tenemos HEAD apuntando a la referencia **master**.
+Cuando creamos una nueva rama, lo que hacemos es crear una nueva referencia que apunta al commit en el que estamos. En ese momento nos podemos cambiar a esa nueva rama (''checkout'')  para que HEAD apunte a ella y crear commits sin que **master** cambie.
+Las ramas las vamos a entender siempre como entornos paralelos que creamos para desarrollar una característica o corregir un fallo y, al terminar, volcaremos a la rama principal. Borraremos la rama alternativa.
 ===== Trabajo con ramas =====
-==== Comandos para trabajar con ramas ====
+==== Listar ramas ====
+<code>
+git branch
+</code>
+Git nos señala la rama en la que estamos añadiendo un asterisco delante.
+<WRAP center round info 60%>
+Si el repositorio de git está recién iniciado, el comando anterior no mostrará nada porque no hay ningún commit.
+</WRAP>
+Recordamos que "estar en master" es que HEAD está apuntando a master (''HEAD -> master'').
+==== Creación de ramas ====
+<code>
+git branch nombre_rama [<commit>]
+</code>
+Cuando no indicamos nada, la rama se crea en el commit en el que estemos.
+Al crear la rama, se crea una referencia que apunta a un commit
+Ir a una rama:
+<code>
+git checkout nombre_rama
+</code>
+El comando anterior saltará al commit al que apunte dicha rama y HEAD apuntará a esa rama.
+Para evitar olvidarnos de cambiar de rama al crearla, podemos usar el siguiente comando que no solo creará la rama sino nos moveremos a ella:
+<code>
+git checkout -b nombre_rama
+</code>
+==== Eliminar una rama ====
+<code>
+git branch -d / -D nombre_rama
+</code>
+  * ''-d'': nos avisa si los commits de la rama que queremos borrar no han sido fusionados.
+  * ''-D'': borra la rama sin advertirnos de que se perderán los cambios.
+**Importante**: para eliminar una rama, debemos salir antes de ella.
+<WRAP center round info 60%>
+Recordamos que no se borran los commits realmente sino la referencia, quedando ese itinerario "huérfano". Si los quisiéramos recuperar, nos ayudaríamos de ''git refloj''.
+</WRAP>
+==== Renombrar una rama ====
+<code>
+git branch -m nombre_antiguo nombre_nuevo
+</code>
 ==== Ejemplo de trabajo con ramas ====
+<WRAP center round todo 60%>
+Poner ejemplo en consola del gráfico anterior con dos ramas
+</WRAP>
+Si queremos "mover" una rama existente, podemos hacer:
+<code>
+git branch -f nombre_rama <COMMIT>
+</code>
+Si quisiéramos mover una rama a la rama en la que nos encontramos no hace falta indicar commit:
+<code>
+git branch -f nombre_rama
+</code>
 ===== Fusionando código: merge, rebase y cherry-pick =====
+Generalmente cuando queramos desarrollar una nueva característica de nuestra aplicación/código, abriremos una rama nueva. Trabajaremos en esta rama. La rama principal puede quedarse quita o avanzar.
+En algún momento, al terminar de trabajar en la nueva rama, querremos volcarla a la rama principal. Decimos entonces que **fusionamos** el código.
+En esta fusión de código lo que se hace es crear un nuevo commit que fusiona ambas ramas, así que este nuevo commit tendrá como padres uno de la rama principal y otro de la rama nueva.
+El propósito de una rama es que cuando terminemos con ella, la volquemos a otra rama principal. En este proceso de volcado, los commits que estaban en la rama paralela formarán parte de la rama principal.
+Aunque hay otras metodologías, una buena práctica es desarrollar en una rama nueva, terminar, volcar y borrar la nueva rama. De esta forma podemos asegurarnos que se produzcan menos conflictos.
 ==== Fusionando código: merge ====
+''merge'' sirve para fusionar ramas: volcar el trabajo de una rama en otra
+Objetivo: que una rama tenga los commits de otra.
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-merge.png?nolink |}}
+Tipos de merge:
+  * **Fast forward**: no crea un nuevo commit, sin conflictos. Es el más rápido.
+  * **A tres bandas** (//3-way merge//): crea un nuevo commit, existe posibilidad de conflictos
+Si surgen conflictos, lo primero que tenemos que hacer es ''git status''
+**master** es una rama que solo se actualiza cada vez que se hace una subida a producción del código. La rama sobre la que se trabaja diariamente es **develop** (puede recibir otro nombre, pero por convención, se emplea esa).
+El **merge** se hace desde la rama destino.
+Con el merge **fast forward** el código no cambia, sencillamente git apunta la rama master a donde la rama secundaria, no se crea ningún commit.
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-merge-fast-forward.png?nolink |}}
+<WRAP center round tip 60%>
+Recordemos que tras fusionar una rama, borraremos la rama secundaria puesto que lo que nos interesa es la rama principal.
+</WRAP>
+Con el merge **a tres bandas**, en los casos en que tanto la rama principal y la secundaria avanzan por caminos distintos.
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-merge-3-way-no-conflicts.png?nolink |}}
+La fusión **a tres bandas** crea un nuevo commit con el commit común a las dos ramas, el código de una rama y el código de la otra, por eso lo de "a 3 bandas".
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-merge-3-way-no-conflicts-result.png?nolink |}}
+Esta fusión puede ocasionar conflictos. Por ejemplo si estamos en la siguiente situación:
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-merge-3-way-conflicts.png?nolink |}}
+Git no podrá decidir por nosotros y nos pedirá solucionar.
+<WRAP center round tip 60%>
+Con ''git merge %%--%%abort'' podemos volver al estado anterior del intento de fusión
+</WRAP>
 ==== Ejemplo práctico de merge ====
+Si tenemos una rama principal llamada **develop** y una secundaria llamada **experimento** y esta segunda está más avanzada que la primera y la que queremos volcar en la primera:
+  - Nos situamos en la rama destino de la fusión (**develop**): ''git checkout develop''
+  - Hacemos el merge: ''git merge experimento''
+Git habrá pasado la etiqueta **develop** al commit al que está apuntado **experimento**
+<WRAP center round todo 60%>
+Poner ejemplo en la línea de comandos donde se ve que Git indica que ha hecho un **fast forward**
+</WRAP>
+Ahorra borraremos la rama **experimento**:
+<code>
+git branch -d experimento
+</code>
+<WRAP center round tip 60%>
+Al borrar una rama, Git comprueba si sus commits quedarían huérfanos. En caso positivo, Git no dejaría que borrásemos la rama porque se "perderían" los commits
+</WRAP>
+En un merge a 3 bandas con conflictos, hacemos ''git status'' para ver qué es lo que sucede y obtener pistas. Lo resolvemos con alguno de los métodos que vimos en la unidad de [[informatica:programacion:cursos:control_version_git_avanzado:conflictos|Conflictos]].
 ====  Fusionando código: rebase ====
+En el **rebase** el resultado de la fusión siempre es una línea, no hay bifurcaciones.
+  * El **rebase** sirve para aplicar una rama al final de otra.
+  * Volcar el trabajo de una rama en otra
+  * Objetivo: que una rama tenga los commits de otra
+  * No crea un nuevo commit
+  * A diferencia del **merge**, con **rebase** hay confictos por pasos: lanzar siempre ''git status''
+  * No hacer rebase si ya se ha subido la rama (auxiliar/accesoria) al remoto
+A diferencia del **merge**, el **rebase** se aplica desde la rama origen.
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-rebase.png?nolink |}}
+Después de un rebase tenemos que adelantar la rama principal (''git branch -f develop'').
+<WRAP center round important 60%>
+Si vamos a hacer un rebase, hay que pensar si hemos subido al repositorio remoto la rama secundaria. Si lo hemos subido, no podemos hacer **rebase** sino **merge**. **rebase** es una de las opciones de rescritura de la historia. Si seguimos un modelo correcto de ramas, esto no debería ser un problema porque las ramas auxiliares nunca se suben al escritorio remoto pues las vamos borrando, solo son útiles en nuestro repositorio local mientras vamos desarrollando.
+</WRAP>
 ==== Ejemplo práctico de rebase ====
+<WRAP center round todo 60%>
+Poner ejemplo de consola
+</WRAP>
+Regla de oro: en el momento en que aparezca un conflicto, usamos ''git status''.
+<WRAP center round tip 60%>
+Con ''git rebase %%--%%abort'' podemos volver al estado anterior del intento de fusión
+</WRAP>
 ====  Fusionando código: Cherry-pick ====
+  * Aplicar un commit aislado a una rama
+  * No se aplican los commits anteriores
+  * Modificador ''-x'' para que añada al mensaje "Cherry-picked from XXXX"
+  * Confictos: lanzar siempre ''git status''
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-cherry-pick.png?nolink |}}
+Al igual que el **merge**, **cherry-pick** se usa también desde la rama destino.
+<code>
+git cherry-pick <COMMIT> -x
+</code>
+Si surgen conflictos, ''git status''.
+<WRAP center round tip 60%>
+Con ''git cherry-pick %%--%%abort'' podemos volver al estado anterior del intento de fusión
+</WRAP>
+Cuando terminamos de solucionar conflictos:
+<code>
+git cherry-pick --continue
+</code>
+<WRAP center round tip 60%>
+cherry-pick se podrá utilizar siempre y cuando se hayan hecho commits "con cabeza" sin mezclar funcionalidades de tal manera que cada commit se centre en una cosa y se vea claro, de esa manera se podrán coger funcionalidades o características concretas. Los commits deberían organizarse de manera que formen una unidad más o menos lógica.
+</WRAP>
 =====  Métodos para mover referencias =====
+métodos para mover referencias.
+Uno de los más usados:
+<code>
+git branch -f nombre_rama [<commit>]
+</code>
+Cuando no especificamos el commit, moverá la rama al HEAD.
+Para usar el método anterior, tenemos que estar en una rama distinta a la que nos queramos mover.
+Otro método es el ''git reset'':
+<code>
+git reset <commit> --hard
+</code>
+Movemos tanto la referencia de rama y HEAD. Como no queremos guardar los cambios de los commits que quedan huérfanos, usamos el modificador ''%%--%%hard''.
+Por último, si solo queremos avanzar la referencia de una rama hasta un commit más avanzado (cuando es el mismo itinerario):
+<code>
+git merge rama_destino
+</code>
 ===== Deshacer errores con las ramas =====
+La facilidad a la hora de mover referencias (ramas) en git hace que no sea tan complicado deshacer errores. Esto no afecta ni al log ni al contenido de los commits.
 ==== Cómo corregir errores con las ramas ====
+Si tenemos HEAD por delante de la rama principal. Dos formas
+<code>
+git branch -f develop
+</code>
+Alternativa (desde develop):
+<code>
+git merge <COMMIT_DESTINO>
+</code>
+Y finalmente hacemos que HEAD apunte a develop:
+<code>
+git checkout develop
+</code>
 ==== Cómo deshacer un merge ====
+Si queremos deshacer un merge fast-forward, primero tenemos que ver la situación anterior al merge. No existe un comando para deshacer un merge.
+Si no se ha añadido ningún commmit, es decir, el cambio ha sido de referencias, primero creamos una referencia (la que borramos) y luego movemos **develop** tantos commits para atrás como estuviese en la situación anterior del merge **fast forward**
+En el caso de un merge **a 3 bandas**, pasa lo mismo. Hay que estudiar lo que ha ocurrido al hacer el merge para saber cómo podemos volver al estado anterior.
 ==== Cómo deshacer una rebase y un Cherry-pick ====
+Para deshacer un **rebase**, lo mismo que antes, tenemos que saber cómo estaban las cosas antes para recuperarlas.
+Lo mismo con deshacer **cherry-pick**, pero suele ser más sencillo porque puede bastar con un ''git reset %%--%%hard <COMMIT>'' para mover tanto la rama como HEAD.
 ===== Git Flow =====
+Hasta ahora hemos ido viendo el **modelo general** de cómo trabajar con rama en git:
+  - Creamos una rama auxiliar
+  - Trabajamos en ella
+  - Fusionamos con **develop**
+  - Eliminamos la rama auxiliar
+Esta metodología es un conjunto de buenas prácticas que nos aseguran no tener conflictos o al menos tener pocos y fáciles de resolver.
+Cada empresa o programador puede tener su propio flujo. Hay una serie de métodos que comparte la comunidad. Uno de ellos es **git flow**, un modelo de //branching// [[https://nvie.com/posts/a-successful-git-branching-model/|presentado por un desarrollador]] en 2010 como su propia forma de trabajar con las ramas.
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-git-flow.png?nolink |}}
+Tuvo mucho éxito y se ha convertido en uno de los métodos más utilizados.
 ==== El modelo git flow ====
+Este modelo se basa es tener dos ramas principales:
+  * **master** branch
+  * **develop** branch
+A diferencia del modelo general, ambas ramas estarán vivas siempre, nunca se borrarán.
+Cada vez que el código alcance un estado tal que podamos publicar la aplicación, volcaremos a **master**. Mientras desarrollamos una nueva versión, los cambios se hacen en **develop**.
+Ambas ramas son las únicas que  compartiremos con el resto de desarrolladores, es decir, las únicas que se subirán al repositorio remoto.
+Este modelo además tiene una serie tipos de ramas auxiliares:
+  * **feature** branch: cada vez que programemos algo nuevo, abrimos este tipo de rama (se abre a partir de la última versión de **develop**). Al terminar, se vuelca en develop y se borra la rama auxiliar.
+  * **bugfix** branch: similares a las //features//, pero se utiliza para corregir fallos. Se crea también a partir de develop, se vuelca a ella y la borramos al terminar.
+  * **hotfix** branch: para corregir errores que detectamos en **master**. Nace desde master y al terminar, la rama se fusionará con develop y master.
+  * **release** branch: sirven para hacer una puesta a producción. Cuando develop está lista para pasar a producción, abrimos una rama //release// donde damos las últimas pinceladas a los cambios. Esto lo hacemos en una rama separada para que el resto de desarrolladores puedan seguir trabajando en la siguiente versión y vaya avanzando develop. Al terminar con la rama //release//, la volcamos tanto a master como develop. Borramos la rama //release//.
+Toda esta metodología existe en un software llamado **git flow** que se puede instalar en Windows (ya lo incluye), Linux y macOS.
+Empezar a usar git flow en un repositorio:
+<code>
+git flow init
+</code>
+Nos preguntará cómo queremos llamar a las ramas. Git nos da unas propuestas, pero podemos poner lo que queramos.
+El uso sería el siguiente:
+Iniciar rama:
+<code>
+git flow tipo_rama start nombre_rama
+</code>
+Cuando hayamos terminado con la rama:
+<code>
+git flow finish
+</code>
+<WRAP center round important 60%>
+Si no estuviésemos en esa rama, el comando tendría que ser ''git flow tipo_rama finish nombre_rama''
+</WRAP>
+Usando el programa **git flow**, no tenemos que recordar de dónde salen las ramas, a dónde se deben volcar, ya se encarga él.
 ==== Poniendo en práctica git flow ====
+Vemos el uso del programa **git flow** para facilitar el flujo de trabajo git flow.
+Empezamos:
+<code>
+git flow init
+</code>
+<WRAP center round todo 60%>
+Poner ejemplo de salida por consola
+</WRAP>
+Comenzamos a trabajar:
+<code>
+git flow feature start readme
+</code>
+Y se habrá creado la rama ''feature/readme'' basada en develop y nos llevará a esa nueva rama.
+Cuando terminemos de hacer cambios, cerramos la rama:
+<code>
+git flow feature finish readme
+</code>
+<WRAP center round tip 60%>
+Recordemos que si vamos a cerrar la rama en la que estamos, podemos abreviar con ''git flow finish
+</WRAP>
+<WRAP center round info 60%>
+El git flow está programado de manera que los **merge** sean a tres bandas, evitando el fast forward
+</WRAP>
+Cuando tengamos listo todo para publicar una versión, creamos un rama //release//:
+<code>
+git flow release start v1.0.0
+</code>
+Al terminar:
+<code>
+git flow finish
+</code>
+Si tenemos un error en producción, queremos abrir una rama de tipo **hotfix**:
+<code>
+git flow hotfix start idioma
+</code>
+Git flow ya sabe que tiene que crearla a partir de master. Cuando terminemos de hacer los cambios y queramos cerrar la rama:
+<code>
+git flow finish
+</code>
+El "fix" se propagará tanto a master como develop.
 ===== Conclusión =====
+Hemos aprendido a trabajar con ramas, que es básicamente trabajar con referencias.
+El **rebase** solo se puede hacer si la rama origen no la hemos subido al repositorio remoto.
+El cherry-pick es muy útil para cuando no queremos traernos todo el trabajo de una rama.
+El modelo git flow permite un flujo de trabajo con bajo número de conflictos.
 ===== Recursos =====