Diferencias

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

--- informatica:programacion:cursos:control_version_git_avanzado:branching [2023/06/03 16:25] – [El modelo de ramas de Git] 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 136: / 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 149: / 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 166: / 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 176: / 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 236: / 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 265: / 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 370: / Línea 352: @@
 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 ====
@@ Línea 418: / Línea 403: @@
 <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
+Si no estuviésemos en esa rama, el comando tendría que ser ''git flow tipo_rama finish nombre_rama''
 </WRAP>