Diferencias

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

--- informatica:programacion:cursos:control_version_git_avanzado:branching [2023/06/03 16:32] – 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 164: / 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 174: / 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 364: / 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 412: / 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>