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.Administrar ramas de publicación en Mercurial
Este es el flujo de trabajo:
- Por lo general tienen una rama del tronco/default donde trabajo en la serie versión actual pasa. 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 es no si este flujo de trabajo es buena (supongo que no es fundamentalmente erróneo). 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 para gestionar ramas en Mercurial ...
A partir de un repositorio con una sola rama que contiene el código de la corriente 1.x serie de lanzamientos:
$ hg init
$ echo "hello world" > file1.txt
$ hg ci -A -m "Initial commit of 1.x code"
empezar a trabajar en 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, hacer un trabajo en serie versión 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, la versión 2.0 está lista, yippee! Hacer por defecto rama 1.x a y 2.x a por defecto:
$ 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 crear una nueva rama 3.x y trabajar en ella, también trabajar en predeterminado . Una vez más, después de algún tiempo 3.0 está listo y es hora de volver a gestionar nombres de la rama:
$ 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 repo ahora puede tener este aspecto ('o' son las cabezas):
o Branch default (3.x)
|
| o Branch 2.x
\|
| o Branch 1.x
\|
|
.
El punto principal No estoy seguro si es reutilizando nombres de rama y haciendo malabares con el nombre de rama por defecto es una buena práctica.
Mucho texto para esa pregunta, lo siento, pero quería dejar en claro lo que estoy haciendo.
[Mercurial wiki] (http://www.mercurial-scm.org/wiki/StandardBranching) proporciona una buena introducción sobre este tema. – xyres