Mercurial. Abandonado – Implementación alternativa ¿Práctica de sucursal?

Usamos Mercurial como control de fuente, principalmente usando twigs con nombre para las principales características que cerramos y fusionamos en la twig de desarrollo una vez finalizado.

Recientemente tuve dos soluciones divergentes a un problema en particular. No pude decidir cuál elegir ya que ambos tenían sus pros y sus contras, así que los implementé a ambos pero tuve que elegir uno para fusionarme en la twig principal .

La segunda implementación no está destinada a fusionarse en la twig principal. Pero todavía quiero savelo por si acaso podría ser útil algún día.

Una solución obvia es simplemente abrir una twig con nombre para cada uno. Cierra ambos y solo combina 1 en el principal.

Pero esto deja una especie de "desorder" en el tree fuente.

¿Hay alguna otra alternativa o mejores prácticas?

Nosotros en RhodeCode usamos completamente la solución basada en marcadores, y la funcionalidad de request de extracción.

Usamos rebase como estrategia de fusión, esto deja el gráfico de compromiso agradable y limpio. Si necesitamos hacer un seguimiento de los cambios, siempre puede volver a la request de extracción original y ver cuál fue el process de desarrollo, incluidas las testings de CI / los comentarios del código.

Los marcadores son, desde nuestro punto de vista, una opción mucho mejor, ya que es un puntero liviano, esto te permite hacer fácilmente rebases / commit squash y simplemente empujar el nuevo puntero de marcador y actualizar la request de extracción con esta información. Esto combinado con el soporte de fases de Mercurial ofrece una manera muy agradable de trabajar con nuevos envíos de código. (Público en el repository principal, borradores en los tenedores de donde provienen los commits)

Hasta ahora, hemos realizado pocos miles de requestes de extracción desarrollando internamente RhodeCode, y todos acordamos con el equipo que es el process más flexible y también el más simple.