Diferencia entre revisiones de «Cherry-picking»

De Wiki de EGC
Saltar a: navegación, buscar
(Página creada con «Cuando estamos implementando en nuestra rama puede ser necesario o recomendable traernos a la rama principal solo alguno de los commits que hicimos en la rama donde hemos d...»)
 
m
 
(No se muestran 5 ediciones intermedias de otro usuario)
Línea 1: Línea 1:
Cuando estamos implementando en nuestra rama puede ser necesario o recomendable traernos a la rama principal solo alguno de los commits que hicimos en la rama donde hemos desarrollado nuestra nueva funcionalidad. Es ene ste escenario donde podemos utilizar cherrypicking.  
+
Cuando estamos implementando en nuestra rama puede ser necesario o recomendable traernos a la rama principal solo alguno de los commits que hicimos en la rama donde hemos desarrollado nuestra nueva funcionalidad. Es en este escenario donde podemos utilizar cherrypicking.  
  
 
1) Nos movemos a la rama donde estemos implementando la nueva funcionalidad:
 
1) Nos movemos a la rama donde estemos implementando la nueva funcionalidad:
 
+
<source>
 
git checkout new-feature
 
git checkout new-feature
 +
</source>
 +
2) Tras movernos, realizaremos los cambios que necesitemos. Supongamos que obtenemos una salida parecida a la siguiente
  
2) Tras movernos, realizaremos los cambios que necesitemmos. Supongamos que obtenemos una salida parecida a la siguiente
+
<source>
 
 
 
git log --oneline
 
git log --oneline
 +
</source>
 +
[[Archivo:log_git_example.png|400px]]
  
 
+
3) Bien, pues ¿qué necesitamos hacer para traernos a la rama master los commits d05aa97 4394783?
 
+
<source>
 
 
3) Bien, pues que necesitamos hacer para traernos a la rama master los commits XXXX y YYYY?
 
 
 
 
git checkout master
 
git checkout master
  
git cherry-pick XXXX YYYY
+
git cherry-pick d05aa97 4394783
 
+
</source>
 
4) En este momento,  
 
4) En este momento,  
  
 
4a) Si nos aparecen conflictos tendremos que resolverlos y posteriormente
 
4a) Si nos aparecen conflictos tendremos que resolverlos y posteriormente
 
+
<source>
 
git cherry-pick --continue
 
git cherry-pick --continue
 
+
</source>
 
4b) Si por el contrario queremos abortar el cherrypick
 
4b) Si por el contrario queremos abortar el cherrypick
 
+
<source>
 
git cherry-pick --abort
 
git cherry-pick --abort
 
+
</source>
 
¡OJO!!
 
¡OJO!!
El cherry-picking esta desaconsejado normalmente por los desarrolladores. La razón principal es porque crean dos commits duplicados con los mismos cambios y se pierde la capacidad de rastrear el historial de la confirmación original. Es decir, en casos donde es posible hacer un merge completo. Mejor optar por el.
+
El cherry-picking está desaconsejado normalmente por los desarrolladores. La razón principal es porque crean dos commits duplicados con los mismos cambios y se pierde la capacidad de rastrear el historial de la confirmación original. Es decir, en casos donde es posible hacer un merge completo. Mejor optar por el.

Revisión actual del 19:47 10 nov 2019

Cuando estamos implementando en nuestra rama puede ser necesario o recomendable traernos a la rama principal solo alguno de los commits que hicimos en la rama donde hemos desarrollado nuestra nueva funcionalidad. Es en este escenario donde podemos utilizar cherrypicking.

1) Nos movemos a la rama donde estemos implementando la nueva funcionalidad:

git checkout new-feature

2) Tras movernos, realizaremos los cambios que necesitemos. Supongamos que obtenemos una salida parecida a la siguiente

git log --oneline

Log git example.png

3) Bien, pues ¿qué necesitamos hacer para traernos a la rama master los commits d05aa97 4394783?

git checkout master

git cherry-pick d05aa97 4394783

4) En este momento,

4a) Si nos aparecen conflictos tendremos que resolverlos y posteriormente

git cherry-pick --continue

4b) Si por el contrario queremos abortar el cherrypick

git cherry-pick --abort

¡OJO!! El cherry-picking está desaconsejado normalmente por los desarrolladores. La razón principal es porque crean dos commits duplicados con los mismos cambios y se pierde la capacidad de rastrear el historial de la confirmación original. Es decir, en casos donde es posible hacer un merge completo. Mejor optar por el.