Mejoras en el sistema de merge (usabilidad, Cherry Picking,...)

Mejoras en el sistema de merge (usabilidad, Cherry Picking,...)

18:15 1 Comments

En las últimas releases se ha trabajado en mejorar el sistema de merge. Se ha buscado que sea más rápido, más efectivo y que de más información útil para el usuario (que contribuidor/es lo ha modificado, porque se ha descartado), siempre hay que mejorar, uno no se puede quedar estancado.

Pero no solo hay que mejorar las cosas, sino cambiarlas, adaptarlas. Tras observar la diversidad de patrones de SCM aplicados durante el desarrollo, se ha optado por ampliar las posibilidades de merge y de esta manera facilitar o tratar de ayudar en un patrón distinto al de rama por tarea que se propone.

Hasta ahora el comando de merge permitía incorporar los cambios realizados en una rama en el espacio de trabajo. A la hora de hacerlo se podía mezclar el último contenido de la rama o bien el contenido de la rama que hubiese sido etiquetado. Todo ello estaba orientado a facilitar el trabajo cuando se usaba el patrón de rama por tarea. A partir de ahora como origen del merge también se podrá elegir un changeset, una etiqueta o una revisión concreta.

Con todo, la forma de entender el merge como la mezcla del contenido del origen con el contenido del destino seguía siendo la misma. Para tratar de dar un mayor número de posibilidades se introdujo la posibilidad de realizar el merge no sólo con el contenido de la revisión, sino que también hacerlo con el cambio concreto introducido en una revisión (cherry picking) o de los cambios introducidos por un intervalo de revisiones.

El cherry picking es un merge mediante el cual un cambio (delta) introducido por una revisión es aplicado en el espacio de trabajo. Aunque está operación no suele ser muy común, dado que normalmente lo que se quiere es incorporar todo el contenido (la suma de todos los cambios que sufrió el origen), aunque en ocasiones incorporar sólo el último cambio puede resultar de utilidad.

Pongamos un escenario donde el cherry picking puede ser de gran utilidad. En una rama se está añadiendo nueva funcionalidad y durante el proceso se ha corregido un error, puede darse el caso de queramos incorporar esa corrección de error pero no la nueva funcionalidad en ese caso se usuaria el cherry picking.

Concretando tenemos una clase en la que hemos añadido varias propiedades y métodos, y posteriormente hemos corregido un pequeño error. Cuando se haga el cherry picking de la revisión (o changeset) que corrige el error como resultado se incluirá la corrección de ese error pero no la funcionalidad que había sido añadida previamente, la cual puede estar incompleta, sin probar, etc.

El caso de hacer el merge de un intervalo de revisiones extiende el concepto del cherry picking permitiendo incluir no sólo un cambio sino todos los cambios que se han realizado entre dos revisiones de un mismo elemento.

Aun así para realizar todas esto es más aconsejable crear una rama nueva que permita aislar el cambio tranquilamente de forma que la trazabilidad del mismo y su aislamiento sea mayor. Pero en caso de no querer realizar ramas para este tipo de cosas el cherry picking puede ser de gran utilidad.