Bazaar: Burbuja de fusión en Mainline después de Pull - Merge - Commit

Question

Soy nuevo en Bazaar, llegando a él desde un fondo de subversión y git. Pensé que tenía una comprensión de algunos conceptos básicos, pero ya he alcanzado un obstáculo en mi primer comodidad importante.

El proyecto está alojado en LaunchPad. Creé una sucursal local ("trabajando") con bzr branch. Hice cambios, agregué nuevos archivos, renombró otros. Mientras tanto, otra persona en el equipo cometió y empujó sus cambios. En este punto, la historia del comet se parecía a esto:

3. Team Member A
2. Me (trivial commit of .bzrignore)
1. Original commit

Esta mañana yo bzr commit Mis cambios localmente. El número de confirmación se informó como 3, que supuse (erróneamente) se reconciliaría cuando se sincronizara con el servidor. Cuando hice un bzr pull Recibí este mensaje:

Using saved parent location: bzr+ssh://bazaar.launchpad.net/...
bzr: ERROR: These branches have diverged. Use the missing command to see how.
Use the merge command to reconcile them.

Hice bzr merge. No se descubrieron conflictos, pero se dejaron tres archivos como se modificaron en mi rama local. Inspeccioné y cometí a aquellos con un comentario, que se me informó como Commit 4. Luego hice un bzr push, que no informaron errores.

Ahora la historia del comet (bzr log --include-merges) Se ve como esto:

4.    My merge commit
2.1.1 Team Member A
3.    My commit this morning
2.    My .bzrignore commit
1.    Original commit

Aquí hay un alto deseo de mantener la línea del tronco serializada y evitar estas burbujas de fusión. (Molnemente, LaunchPad no muestra la confirmación 2.1.1, haciendo que parezca que lo sobrescribí). ¿Cuál es el mejor flujo de trabajo en esta situación para evitar estas burbujas? ¿Debería haber tirado primero? No tengo que tener que fusionar el código de otras personas en mis cambios locales no comprometidos.

Además, aunque Rebase se usa comúnmente en GIT, parece que generalmente no se aprueba en el mundo del bazar. Si podemos evitar usar el complemento BZR-ReBase, sería genial.

Answer 1

Una forma de tener un historial de línea principal más limpia sería hacer su trabajo en una rama de características separadas, mientras mantiene un espejo de la rama principal. Supongo que las ramas con árboles de trabajo aquí, pero podrías usar ramas sin árboles y un pago para ahorrar espacio en disco.

// setup the mirror branch
cd <mirror directory>
bzr pull <mainline>

// setup a feature branch
cd <feature directory>
bzr branch <mirror directory> .

// work on your feature branch
bzr commit -m "Did some work"
...
bzr commit -m "Did some more work"

// ready to commit your feature
cd <mirror directory>
bzr pull
bzr merge <feature directory>

// your integration testing is done
bzr commit -m "My shiny feature"
bzr push