Encuentra la diferencia de una "request de extracción" de Bitbucket / Stash

(Stash = Bitbucket alojado localmente).

Tengo el típico flujo de trabajo de git: crear una twig, trabajar en ella, empujarla a Stash periódicamente, volver a establecer la base de master periódica, fusionar a la master través de Stash.

El resultado es una request de extracción en Stash que contiene solo los commits correctos.

  • ¿Hay alguna forma de encontrar estos commits usando git en la command-line? git log contiene, pero git reflog <my-feature-branch> muestra solo algunos de ellos.
  • Habiendo encontrado estos compromisos, ¿cómo puedo producir una diferencia de mi RP? El último compromiso es obvio, pero no puedo encontrar el punto inicial correcto.

Actualización : a partir de los comentarios, dice que está haciendo análisis después de que la twig se haya fusionado y después de algunas rebases. Normalmente no asumiría que importa, porque:

1) O tiene my_feature_branch sentado en la confirmación antes de la fusión, o no. Mencionó que puede ver las confirmaciones con el git log , así que supongo que encontrar la sugerencia de twig no es un problema.

2) Reubicar cosas en el maestro generalmente no cambiará nada con respecto al significado de master..my_feature_branch o master...my_feature_branch (en sus respectivos contexts).

Pero dado que asumo que usted no es el tipo de persona que lee la primera frase de una respuesta y luego escribe un comentario defensivo sin haber probado el consejo que la respuesta le dio, eso sugiere que puede haber hecho una rebase que cambiaría la relación entre las twigs, en cuyo caso la naturaleza de esa rebase debe explicarse en la pregunta.

Dices que entiendes que Git no sabe nada de requestes de extracción, pero descartas comparaciones basadas en cosas que Git conoce y continúas preguntando si hay una forma de que Git te informe sobre la request de extracción … No, no hay 't. Lo que desea es el historial de la confirmación a la que apunta my_feature_branch cuando se creó el PR, less cualquier historial del ocmmit al que el master apuntó al mismo time. Es posible que haya realizado operaciones que lo complican o que solo piense que tiene.

Si la confirmación que el master apuntó en ese momento, es alcanzable (por los pointers padres) desde el master ahora; y si tiene alguna reference hacia (o la ID SHA de) la confirmación my_feature_branch señalado en ese momento, entonces la notación que ya recomendé funcionará.

Incluso si my_feature_branch se my_feature_branch , siempre y cuando su nueva base aún esté en el historial de master y la rebase no haya omitido ni editado confirmaciones, la misma notación funcionaría aún con la confirmación reescrita correspondiente a la antigua sugerencia my_feature_branch .

Si ha reescrito my_feature_branch de alguna otra manera (y no ha realizado un seguimiento del commit original), entonces su mejor opción sería encontrar el commit tip en el reflog y luego usar git log y git diff (como se describe a continuación) ) utilizando el SHA de ese compromiso en lugar del nombre de la reference de la sucursal.


Tenga en count que una request de extracción no es un concepto de "git básico"; es peculiar del service en el que se realiza el repository. Lo que realmente está examinando es una sucursal para la que ha emitido una request de extracción.

No entiendo tu primera pregunta. Como ha identificado correctamente, git log muestra el historial de la sucursal. El reflog es otra cosa (una historia local de donde el árbitro ha señalado en este clon particular) y no es lo que quieres. Supongo que el problema con el git log es cómo hacer que solo muestre las confirmaciones que aún no están en el maestro. Puedes hacer esto por

 git log master..my_feature_branch 

(Nota: dos puntos en este caso.) Entonces, si tiene

 x --- x --- x --- x <--(master) \ A --- B --- C <--(my_feature_branch) 

esta salida de logging mostrará A , B y C

En cuanto a cómo hacer la diferencia, es similar pero un poco diferente:

 git diff master...my_feature_branch 

(Nota: 3 puntos esta vez)

Esto encuentra automáticamente la "base de combinación" para master y my_feature_branch y diffs my_feature_branch contra la base.