Diferencias

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

--- informatica:programacion:cursos:control_version_git_avanzado:branching [2023/06/03 11:44] – 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 28: / Línea 28: @@
 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.
-<WRAP center round todo 60%>
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-ramas.png?nolink |}}
-Poner gráfico con la representación de commits y dos ramas
-</WRAP>
 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).
@@ Línea 138: / Línea 136: @@
 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.
-<WRAP center round todo 60%>
-Mostrar gráfico con la explicación de arriba.
-</WRAP>
 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.
@@ Línea 151: / Línea 145: @@
 Objetivo: que una rama tenga los commits de otra.
-<WRAP center round todo 60%>
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-merge.png?nolink |}}
-Mostrar gráfico con la explicación de arriba.
-</WRAP>
 Tipos de merge:
@@ Línea 168: / Línea 160: @@
 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.
-<WRAP center round todo 60%>
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-merge-fast-forward.png?nolink |}}
-Mostrar gráfico con la explicación de arriba.
-</WRAP>
 <WRAP center round tip 60%>
@@ Línea 178: / Línea 168: @@
 Con el merge **a tres bandas**, en los casos en que tanto la rama principal y la secundaria avanzan por caminos distintos.
-<WRAP center round todo 60%>
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-merge-3-way-no-conflicts.png?nolink |}}
-Mostrar gráfico con la explicación de arriba.
-</WRAP>
 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".
-<WRAP center round todo 60%>
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-merge-3-way-no-conflicts-result.png?nolink |}}
-Mostrar gráfico con la explicación de arriba.
-</WRAP>
 Esta fusión puede ocasionar conflictos. Por ejemplo si estamos en la siguiente situación:
-<WRAP center round todo 60%>
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-merge-3-way-conflicts.png?nolink |}}
-Mostrar gráfico con la explicación de arriba.
-</WRAP>
 Git no podrá decidir por nosotros y nos pedirá solucionar.
@@ Línea 238: / Línea 222: @@
 A diferencia del **merge**, el **rebase** se aplica desde la rama origen.
-<WRAP center round todo 60%>
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-rebase.png?nolink |}}
-Añadir gráfico con resultado de rebase
-</WRAP>
 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.
+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>
@@ Línea 267: / Línea 249: @@
   * Confictos: lanzar siempre ''git status''
-<WRAP center round todo 60%>
+{{ :informatica:programacion:cursos:control_version_git_avanzado:git-branching-cherry-pick.png?nolink |}}
-Añadir gráfico con ejemplo de cherry pick
-</WRAP>
 Al igual que el **merge**, **cherry-pick** se usa también desde la rama destino.
@@ Línea 288: / Línea 268: @@
 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 =====
@@ Línea 356: / Línea 341: @@
 ===== 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 ====
-El modelo git flow
+Este modelo se basa es tener dos ramas principales:
-master branch
-develop branch
+  * **master** branch
-feature branch
+  * **develop** branch
-bugfix branch
-hotfix branch
+A diferencia del modelo general, ambas ramas estarán vivas siempre, nunca se borrarán.
-release branch
-Git avanzado
+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**.
-El programa git flow
-(en Windows ya viene instalado con Git)
+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
-Cerrar 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 =====