Sugiera un mejor flujo de trabajo en Mercurial

Question

Soy nuevo en Mercurial y de lo que estoy empezando a darme cuenta es de que mi flujo de trabajo básico puede no ser la forma más eficiente de trabajar porque realizo confirmaciones con tanta frecuencia y por mejoras de funciones que son tan pequeño que cuando necesito encontrar un paso anterior para volver, es extremadamente difícil.

Esto es lo que hago después de configurar un proyecto en Mercurial y de haber completado mi primer compromiso.

1. hacer algunos cambios en un archivo y lo consigue a un estado en el que una pequeña mejora está trabajando
2. hg commit -m "improvement A works"
3. hacer algunos cambios en el mismo archivo y ponerlo a un estado en que la próxima mejora menor es trabajando.
4. hg commit -m "improvement B works"
5. Compruebe si todas las mejoras menores se suman a una única característica secundaria que funciona correctamente.
6. hg commit -m "feature A works"

Si encuentro un error que se cometió en la "mejora A", abro la historia (con el plugin visual Netbeans Mercurial) y copiar y pegar una parte del código de nuevo en mi versión actual y comenzar de nuevo desde allí.

Esto no parece ser un buen sistema. Agradecería cualquier sugerencia.

Answer 1

Estoy de acuerdo con Jon en que las sucursales son la solución, pero crearía sucursales para las funciones en lugar de las mejoras individuales que conforman una función. El patrón de flujo de trabajo sería entonces la siguiente:

1. Crear rama para la función de A.
2. trabajo completo para la mejora A y confirmación.
3. Trabajo completo para la mejora B y confirmar.
4. Cuando la característica parece estar funcionando, combine la característica Una rama de nuevo en el tronco.

Si encuentra un error en una mejora de una característica A, en lugar de empezar de nuevo, se cambia a la función de una rama y haga lo siguiente: mejora

1. Fix A y comprometerse.
2. Fusionar la función Una rama de nuevo en el maletero.

Answer 2

Puede aislar los cambios de las mejoras en las sucursales manteniendo un tronco estable.
Eche un vistazo a Branch wiki page.

patrón

flujo de trabajo sería:

1. Crear rama de mejora Un
2. trabajo completo para la mejora Un y el registro
3. cambios de prueba y se funden de nuevo al tronco si tiene éxito
4. Crear rama de mejora B
5. Complete el trabajo para la mejora B y checkin
6. Pruebe los cambios y vuelva a fusionar en el tronco si exitoso

Si encuentra un error, puede abandonar la rama (o corregir el error en la rama antes de volver a fusionarse en el tronco).

Answer 3

No estoy de acuerdo con el enfoque de ramas. Si no se necesita desarrollo paralelo, ¿por qué agregar la complejidad de las ramas? No hay nada de malo con las pequeñas confirmaciones de 'punto de control'. Las etiquetas se pueden usar para señalar compromisos importantes, que pueden ser más claros.