Administrar ramas de lanzamiento en Mercurial

branch (2)

Creo que deberías considerar esto: un exitoso modelo de ramificación git .

No soy el gran admirador de git, pero este modelo también es útil para mercurial.

Recientemente cambié de SVN a Mercurial. Ahora me pregunto cómo realizar mi flujo de trabajo de ramificación previsto en Mercurial de acuerdo con las buenas prácticas, con la esperanza de que otros desarrolladores entiendan lo que sucede en el repositorio.

Este es el flujo de trabajo:

Usualmente tengo una rama troncal / predeterminada donde sucede el trabajo en la serie de lanzamiento actual. Digamos que es 1.x. Al mismo tiempo, uso una rama 2.x para trabajar en la próxima versión principal. Los cambios en esta rama pueden ser radicales, por lo que fusionarse con la rama trunk / default / 1.x no tiene sentido aquí.
- Después de un tiempo, el trabajo en 2.x puede finalizar y la versión 2.0 se libera. Ahora quiero que la rama 2.x sea la nueva rama predeterminada / troncal y la troncal / troncal predeterminada actual sea la rama 1.x.
- Repitiendo este proceso, puede venir una nueva rama 3.x. Como antes, si se lanza 3.0, 3.x debería convertirse en la nueva rama predeterminada, mientras que el valor predeterminado en ese momento debería convertirse en la rama 2.x (nuevamente).

Mi pregunta no es si este flujo de trabajo es bueno (supongo que no es fundamentalmente incorrecto). Mi pregunta es si la forma en que me doy cuenta de esto en Mercurial puede verse como una buena práctica o si hay mejores oportunidades.

Así que aquí es cómo planeo administrar ramas en Mercurial ...

Comenzando desde un repositorio con una única rama que contiene el código de la serie de lanzamiento actual 1.x:

$ hg init $ echo "hello world" > file1.txt $ hg ci -A -m "Initial commit of 1.x code"

Comience a trabajar en la versión 2.x:

$ hg branch 2.x $ hg ci -m "Create new branch for 2.x development" $ echo "Big new feature for 2.x" > file2.txt $ hg ci -A -m "Add big new feature"

Mientras tanto, haz algo de trabajo en la serie de lanzamientos actual (1.x):

$ hg up default $ echo "Minor adjustments specific for 1.x" > file3.txt $ hg ci -A -m "Minor adjustments"

¡Después de un tiempo el lanzamiento 2.0 está listo, yippee! Haga que la rama predeterminada sea 1.x y 2.x predeterminada :

$ hg up default $ hg branch 1.x $ hg ci -m "Make default branch to 1.x branch" $ hg up 2.x $ hg ci --close-branch -m "Close branch 2.x" $ hg branch --force default $ hg ci -m "Make former 2.x branch to new default"

Ahora cree una nueva rama 3.x y trabaje en ella, también trabaje en el valor predeterminado . Una vez más, después de un tiempo 3.0 está listo y es hora de administrar los nombres de las sucursales:

$ hg up default $ hg branch --force 2.x # (reuse previously closed 2.x branch name) $ hg ci -m "Make default branch to 2.x branch" $ hg up 3.x $ hg ci --close-branch -m "Close branch 3.x" $ hg branch --force default $ hg ci -m "Make former 3.x branch to new default"

El repositorio ahora puede verse así (''o'' son las cabezas):

El punto principal del que no estoy seguro es si la reutilización de nombres de sucursales y el malabarismo con el nombre predeterminado de la rama es una buena práctica.

Mucho texto para esa pregunta, lo siento, pero quería dejar en claro lo que estoy haciendo.

Esto es lo que haría:

Establezca por default su rama "mainline". La punta de esta rama es la versión "actualmente lanzada al público" de su código. Las correcciones de errores críticas se pueden asignar directamente a esta rama y fusionarse en ramas de desarrollo.

Para comenzar a trabajar en la versión 2.0, cree una rama 2.0-dev . Confirme los cambios para 2.0 en esa rama y fusione las correcciones de errores críticas de la línea principal ( default ). Una vez que haya terminado con 2.0, fusione 2.0-dev en el default y marque el resultado como 2.0 .

Hacer las cosas de esta manera significa que no tiene que preocuparse por hacer malabares con los nombres de las sucursales, y puede unir correcciones de errores críticas a la línea principal en las ramas de desarrollo con bastante facilidad.

También se adapta bien cuando trabajas en múltiples versiones futuras a la vez (digamos 2.1 y 3.0). Puede fusionar periódicamente los cambios 2.1 en 3.0 para mantener 3.0 actual.

Terminarás con un gráfico como este: