Cerrando manualmente la request de extracción de bitbucket

Mi pregunta

Hago cosas como esas:

git clone git checkout -b new_feature < work and commit > git rebase master < work and commit > < finish working > git rebase master git push origin new_feature < I create pull request via bitbucket's web interface > 

Alguien que está revisando los cambios está haciendo:

 git pull git checkout master git merge --squash new_feature git push origin master 

Esperaba que esto cerrara la request de extracción como aceptada pero no fue así, ¿qué me estoy perdiendo?

Alguna información de background

Leí mucha documentation de bitbucket "trabajando con requestes de extracción" pero esto todavía no está claro para mí.

Puedo ver que todas mis confirmaciones de la twig new_feature se han aplicado a la twig master (a través de git merge --squash ) y puedo ver qué files han cambiado, pero ahora cuando presiono "merge" en la interfaz de request de extracción de bitbucket tengo otro commit en master que es merge y esto no cambia ningún file (todos los cambios ya fueron aplicados por git merge --squash anterior git merge --squash ) pero simplemente trae todos esos commits history al master que no es lo que yo quería.

Vía: https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests

Manualmente tirando requestes a su sistema local

A veces es una buena idea usar un flujo de trabajo donde pruebe un set de cambios en su sistema local antes de aceptar una request de extracción. Puedes hacer esto con cualquier request de extracción. El flujo de trabajo típico es este: recibe una request de extracción en Bitbucket. Actualice su repository local con el set de cambios entrante. Investigar y / o probar el set de cambios. Si el set de cambios es bueno, lo fusiona en su repository local. Es posible que tenga que resolver algunos conflictos. Luego, empuja el repository local de return a Bitbucket. De vuelta en Bitbucket, la request de extracción se marca como aceptada en la pestaña Solicitudes de extracción. Si no le gusta la request de cambio, descarta los cambios localmente y rechaza la request de extracción en Bitbucket. Ideas?

Tu no te estas perdiendo nada. Bitbucket no cierra automáticamente su request de extracción cuando se ha fusionado.

Debe cerrar manualmente la request de extracción seleccionando la opción "Rechazar".

enter image description here

Según tengo entendido, hay dos forms de cerrar una request de extracción Bitbucket como "Fusionada".

  1. Haga clic en el button 'Fusionar'. Bitbucket fusionará su twig de características en la twig de destino (con la opción –no-ff).
  2. Use los commands de la console git (u otra interfaz) para fusionar su twig de características en su sucursal de destino, luego presione ambas hacia el origen.

La primera opción es definitivamente la más sencilla y directa, pero no funciona bien con ciertos flujos de trabajo de desarrollo.

La key para que la segunda opción funcione es que su twig de características debe estar en su sucursal de destino. Bitbucket comtesting periódicamente las requestes de extracción que se han fusionado manualmente y, cuando las encuentra, las marca automáticamente como Fusionadas. Nota: Atlassian no anuncia este comportamiento. No pude encontrar ninguna documentation oficial que respalde este reclamo, pero al less otra persona lo ha visto funcionar .

Según el flujo de trabajo que describió, supongo que la persona que revisó y promocionó sus cambios tiene un historial de git que se ve así:

 * ddddddd (origin/master, master) new feature, squashed | * ccccccc (origin/new_feature, new_feature) new feature part C | * bbbbbbb new feature part B | * aaaaaaa new feature part A |/ o 

En este caso, la forma más sencilla de hacer que Bitbucket cierre automáticamente la request de extracción sería:

 git branch --force new_feature ddddddd git push --force origin new_feature 

Esto también funciona para las twigs de características que se han networkingistribuido.

¡ADVERTENCIA! Mantenga estos hechos en mente:

  • No todos los flujos de trabajo permiten empujes de fuerza de este tipo.
  • Bitbucket actualiza automáticamente las confirmaciones mostradas por una request de extracción cada vez que cambia su twig de características. Dependiendo del order en el que presiones tus twigs, esto puede dar como resultado una list de compromiso vacía. (Más sobre esto a continuación).
  • Cuando se cierra una request de extracción, se congela el historial de compromisos y la información de diferencias.

Cuando empuja su bifurcación de destino al origen antes de empujar su twig de características, Bitbucket busca primero cualquier confirmación en la twig de funciones recién empujada que no está en la bifurcación de destino. Como la nueva twig de características es un antecesor de la twig de destino, el resultado es un set vacío. Por lo tanto, Bitbucket elimina todos los commits de la pestaña commits de la request de extracción, que ahora dice "No hay cambios". Luego, dado que la twig de la function se encuentra en el historial de la sucursal de destino, Bitbucket cierra la request de extracción, congelando la pestaña de commits vacía de la siguiente manera:

No hay cambios.

Curiosamente, la diferencia permanece intacta en este caso.

Si ninguna de las opciones de fusión anteriores funciona para usted, sus únicas opciones restantes son:

  • Rechazar la request de extracción.
  • Considere cambiar su flujo de trabajo a algo que Bitbucket soporta más fácilmente.
  • Flota una request de function con Bitbucket / Atlassian.

Ver también documentation para git-branch y git-push .

BitBucket Server 4.5.1 modificó la forma en que las fusiones remotas se clasifican en la request de extracción (es decir, declinada o fusionada).

La respuesta de @BenAmos anterior funciona bien, pero si presiona la combinación de fusión a la twig de destino ANTES de presionar forzar en la twig de características, BitBucket cerrará automáticamente la request de extracción y la clasificará como 'rechazada'.

Sin embargo, si en lugar de forzar el empuje hacia la twig de características ANTES de presionar la combinación de la fusión con la twig de destino, BitBucket cerrará automáticamente la request de extracción y la clasificará como 'fusionada'.

De Atlassian: "Ahora se rechazará una request de extracción después de un push si: no hay commits en la twig from-branch que no estén también en la twig to-branch Y to-branch no se haya actualizado en el mismo push"

Referencia: https://jira.atlassian.com/browse/BSERV-4219?src=confmacro&_ga=1.138319284.547646488.1457297841

Supongo que Bitbucket no reconoce su PR como fusionada, porque git merge --squash produce un commit completamente nuevo . En nuestra empresa también probamos git merge --squash feature branches cuando los fusionamos en la twig principal, pero lo abandonamos porque las requestes de extracción fusionadas de esta manera seguían rondando, y luego necesitábamos "Rechazarlas" o eliminar la function remota relacionada. twigs

Lo que estamos haciendo actualmente es aplastar todas las asignaciones de twigs de entidades en una y forzarla a una twig de características remota. Después de eso, la persona responsable de fusionarse en master solo tiene que hacer clic en "Merge" en la página de request de extracción de bitbucket y eso es todo, el PR está marcado como "Merged" y todos los cambios introducidos en la twig de características se agrupan en un commit orderado .