Evite empujar el historial local no deseado al repositorio principal en Bazaar o Mercurial

Question

Soy nuevo en DVCS, así que probablemente esté malinterpretando algunos conceptos y terminología, pero esta es la idea de lo que estoy tratando de lograr, y estoy tratando de averiguar si Bazaar o Mercurial lo admiten de manera clara:

Existe un repositorio principal con un código bien probado. Digamos que clono (o extraigo o ramifico o cualquiera que sea la terminología) de eso en un repositorio local, luego todos los días mientras trabajo en el código, realizo cambios localmente, a veces varias veces al día.

Después de que haya terminado con todos mis cambios y pruebas, quiero obtener solo la última versión comprometida (localmente) de cada archivo puesto en el repositorio principal, sin las docenas de versiones intermedias que cometí localmente durante depuración y pruebas unitarias.

Por lo que he estado leyendo, al parecer, toda la historia de esas versiones a medio hacer se reflejaría en el repositorio principal si presiono para ello. Algunos artículos de Internet parecen sugerir que la rebase podría abordar ese problema si se maneja correctamente, pero no está tan claro si/cómo se puede hacer, ya que parece que la rebase es más para evitar un historial bifurcado de bifurcación/fusión que para evitar el compromiso de un gran conjunto de versiones intermedias.

Answer 1

Algunas opciones de bazar.

1. Si quiere deshacerse de las docenas de confirmaciones locales, en realidad está desperdiciando la historia. Una forma de hacerlo es con el comando bzr uncommit. p.ej.

   bzr uncommit -rbranch:https://url_to_mainrepo 
   

   (Deseche rivisions hasta llegar a la revisión de la cesión temporal principal. No se preocupe, le mostrará lo que se hará y confirmar con usted antes de hacerlo)

   A continuación, puede hacer un nuevo compromiso con todos los demás colapsó en uno.

2. Normalmente, Bazaar oculta las revisiones fusionadas. Una forma de que acumule sus pequeños compromisos en una revisión fusionada es mantener una sucursal/salida local del repositorio principal. Luego, cuando esté listo, bzr merge en sus cambios en su copia de repo principal local y luego confirme una revisión fusionada.

   De esta manera aún conservas toda tu historia, pero todas las pequeñas revisiones se envuelven ordenadamente en una revisión de fusión. Entonces puede ver ese historial cuando lo desee.

Aquí es ejemplos de cómo no ver la revisión fusionada:

$ bzr log 
------------------------------------------------------------ 
revno: 2 [merge] 
message: 
    summary of the things I did 
------------------------------------------------------------ 
revno: 1 
message: 
    some change on the mainline 
------------------------------------------------------------ 
Use --include-merged or -n0 to see merged revisions. 

Aquí hay ejemplos de cómo ver la revisión fusionada:

$ bzr log -n0 
------------------------------------------------------------ 
revno: 2 [merge] 
message: 
    summary of the things I did 
    ------------------------------------------------------------ 
    revno: 1.1.2 
    message: 
     my first step 
    ------------------------------------------------------------ 
    revno: 1.1.1 
    message: 
     my second step 
------------------------------------------------------------ 
revno: 1 
message: 
    some change on the mainline 

Answer 2

Las palabras clave que usted está buscando son colapso o veces (Mercurial) o calabaza (GIT). Me temo que no sé cuál es el término habitual para esto en Bazar.

En Mercurial puede usar el histedit extension (una extensión incluida desde Mercurial 2.3) para doblar una serie de conjuntos de cambios en un solo conjunto de cambios. Proporciona un superconjunto de la funcionalidad en el tercero collapse extension.

La rebase extension (otra extensión estándar) tiene la misma funcionalidad que la bandera --collapse. Tiene toda la razón en que el rebase normalmente se realiza para evitar fusiones innecesarias, pero de alguna manera también se debe usar para collapsing (and editing) changesets in Git. El histedit extension para Mercurial se basa en el comando interactivo de rebase en Git.

Answer 3

En Bazar, esto es manejado por tener un "clon" separado (es decir, bzr branch URL) del repositorio principal localmente y luego crea ramas de características locales a partir de las cuales realiza su trabajo con múltiples confirmaciones. Cuando esté listo para mover ese trabajo al repositorio principal, bzr merge la rama de funciones en la rama principal. Eso te deja con un árbol de trabajo modificado en la rama principal que luego comprometes y empujas hacia tu repositorio principal oficial. Esta confirmación incluye el historial de revisión de la rama de características, pero normalmente está oculta en bzr log u otras vistas del historial de historial.