Cómo enumerar las confirmaciones de Git sin empujar (local pero no en el origen)

11 minutos de lectura

Avatar de usuario de Josh Buhler
Josh Bühler

¿Cómo puedo ver las confirmaciones locales que he realizado y que aún no se han enviado al repositorio remoto? Ocasionalmente, git status imprimirá que mi sucursal es X se compromete antes de origin/masterpero no siempre.

¿Se trata de un error con mi instalación de Git o me estoy perdiendo algo?

  • A partir de Git 2.5+ (Q2 2015), la respuesta real sería git log @{push}... Mira ese nuevo atajo @{push} (haciendo referencia a la rama de seguimiento remoto a la que está presionando) en mi respuesta a continuación

    – VoC

    8 jun 2015 a las 22:44


  • @Torek: otra tarea simple que Git dificulta. Cada vez que aparece una pregunta de Git con cientos o miles de votos a favor y millones de visitas, entonces alguien debería pensar: Wow, realmente estropeamos ese flujo de trabajo. Por desgracia, los desarrolladores de Git han omitido el paso de retroalimentación en el ciclo de vida del desarrollo, por lo que la retroalimentación no se incorpora. En cambio, siguen cometiendo los mismos errores una y otra vez. Para esta pregunta, git status --all debería haber aparecido en 2010; o git status -v en realidad debería proporcionar la salida detallada que incluye la información adicional.

    – jww

    10/07/2016 a las 19:32


  • No estoy de acuerdo con que “git status -v” deba proporcionar esta información porque está destinado a brindar el estado sobre el árbol de trabajo, ya que se relaciona solo con la rama desprotegida. Sin embargo, vea la respuesta a continuación sobre “git branch -v”, que creo que debería ser la respuesta aceptada

    – JoelFan

    31 de enero de 2017 a las 19:38

  • Esta pregunta de StackOverflow en particular tiene la mayor cantidad de respuestas correctas que funcionan pero que no tienen ningún sentido.

    –Pete Alvin

    11/01/2018 a las 21:20

  • @jww: Estoy de acuerdo. Volví a usar git después de usar mercurial. Comparado con la facilidad de uso y la elegancia de mercurial, git es un desastre adulterado.

    – Pablo

    24 de noviembre de 2020 a las 14:11

Avatar de usuario de Peter B
pedro b

Esto da un registro de todas las confirmaciones entre origin/master y HEAD:

git log origin/master..HEAD

Cuando HEAD está en la rama maestra, esto proporciona un registro de confirmaciones no enviadas.


Del mismo modo, para ver la diferencia:

git diff origin/master..HEAD

  • Esto lo hizo por mí, por alguna razón, el origen del registro de git … por sí mismo estaba arrojando un error. Parece que también tuve un problema con la forma en que se configuró mi sucursal local, una vez que hice los cambios que encontré aquí: wincent.com/blog/… … el problema se resolvió y pude usar git status nuevamente para ver lo que quería.

    – Josh Bühler

    6 de enero de 2010 a las 22:57

  • Invaluable: tanto que hice git config --global alias.ahead "log origin/master..HEAD --oneline" para saber rápidamente dónde estoy. Aún más dulces: for i in *; do echo $i && git ahead 2>/dev/null; done

    – Jaime

    28 de febrero de 2012 a las 2:50

  • git log --stat origin/master..HEAD por un poco de genialidad extra

    – Cory Danielson

    25 de marzo de 2013 a las 17:51

  • Esta no es la mejor solución. El origen/maestro no siempre puede ser la rama ascendente. Una mejor solución es usar @{u} en lugar de “origen/maestro” para indicar la rama ascendente. Dado que HEAD está implícito de forma predeterminada, también se puede omitir. Vea la respuesta de @Ben Ling. Cambios salientes: git log @{u}.. Cambios entrantes: git log ..@{u}

    – Debajito

    12 de junio de 2013 a las 22:59


  • @Nocturne Solo quiero señalar que cuando se publicó esta respuesta, el @{u} la sintaxis aún no estaba disponible, solo estuvo disponible en 12 de febrero de 2010. También, @{u} no funcionará si la sucursal local no está configurada con un upstream. Finalmente, @{u} actualmente no tiene soporte para completar pestañas, <remote>/<branch> completar con tabulación sigue siendo una de las formas más rápidas de obtener esta información, y funcionará tanto si se configura un upstream como si no.

    usuario456814

    1 de julio de 2014 a las 0:46


avatar de usuario de cxreg
cxreg

Para ver todas las confirmaciones en todas las ramas que aún no se han enviado:

git log --branches --not --remotes

Para ver la confirmación más reciente en cada rama, así como los nombres de las ramas:

git log --branches --not --remotes --simplify-by-decoration --decorate --oneline

  • esto es genial En un escenario relacionado, tenía dos sucursales locales con dos sucursales aguas arriba, y una mano local se fusionó con la otra. Quería saber qué confirmaciones eran seguras para reorganizar, pero lo normal git log master..HEAD no funcionaría ya que había múltiples upstreams. Esta publicación me llevó a git log MyBranch --not --remotes para mostrar todas las confirmaciones que no se han enviado a ninguna parte superior en una sola rama.

    – pavon

    12 de julio de 2014 a las 2:10

  • Entiendo que su segundo comando también enumera las confirmaciones que aún no se han enviado, solo muestra una por rama.

    – Stéphane

    30 de marzo de 2016 a las 6:19

  • --decorate muestra las ramas también. --graph lo hace aún más evidente.

    – rayo

    20 de diciembre de 2016 a las 11:19

  • Tenga en cuenta que estos comandos enumeran solo confirmaciones que no se han insertado cualquier rama. Ejemplo: supongamos que tiene una rama desarrollada con rama feat-NewThing. Realiza cambios localmente en feat-NewThing. (El registro tiene cambios). Luego empuja feat-newThing a su rama remota. (El registro está vacío). Fusionas local feat-newThing para desarrollar localmente. Asumiendo un avance rápido, el registro aún no tiene cambios.

    – Patricio W.

    17 de enero de 2017 a las 0:02

  • Esta es la solución real. El único que funciona generalmente sin la necesidad de especificar una rama o la necesidad de tener un upstream definido.

    – este es mi diseño

    5 de septiembre de 2017 a las 10:02

Avatar de usuario de Ben Lings
ben lings

Muestre todas las confirmaciones que tiene localmente pero no en sentido ascendente con:

git log @{u}..

@{u} o @{upstream} significa la rama aguas arriba de la rama actual (ver git rev-parse --help o git help revisions para detalles).

  • En Windows, necesitaba encerrar el argumento final entre comillas, como: git log “@{u}..”

    – Jon Schneider

    15 de noviembre de 2016 a las 13:48


  • git log @{u}.. -p Una de las opciones más útiles es -pagque muestra las diferencias introducidas en cada confirmación.

    – mQuiroz

    20/09/2018 a las 18:50

  • Posiblemente mejor git log @{push}.. , vea otra respuesta.

    – Dr. Hans-Peter Störr

    26 de noviembre de 2019 a las 12:13

  • Encontré que esta es la mejor respuesta. También descubrí que no hay forma de que lo recuerde sin una hoja de trucos. ¿Por qué los desarrolladores de git no eligieron algo obvio y en línea con el estado de git, ya que queremos saber el estado de una situación git status -v habría tenido mucho más sentido.

    – Fabien Haddadi

    12 mayo 2021 a las 15:49


Avatar de usuario de Christian Vielma
Cristian Vielma

git cherry -v 

Tomado de: Git: vea todas las confirmaciones no enviadas o confirmaciones que no están en otra rama.

Avatar de usuario de Greg Hewgill
greg hewgill

git log origin/master..

Esto supone que origin es el nombre de su control remoto ascendente y master es el nombre de su rama ascendente. Dejando fuera cualquier nombre de revisión después .. implica HEADque enumera las nuevas confirmaciones que no se han enviado. [git log]

  • Cada vez que veo una respuesta con git log y “2-dots-not-3”, siempre me recuerda a stackoverflow.com/questions/53569/… 😉

    – VoC

    6 de enero de 2010 a las 22:56

  • Solo para agregarlo a la respuesta: si no hay una configuración ascendente, este comando da como resultado que no se haya configurado una configuración ascendente. Correr git branch --set-upstream master origin/<branch> para configurar upstream si está inclinado a usar este comando para ver las confirmaciones que están preparadas.

    – espera asincrónica

    7 de agosto de 2013 a las 13:27

  • Esto se comparará con la sucursal predeterminada en el origen, no con la sucursal remota actual.

    – greuze

    18 de junio de 2014 a las 7:20

  • fatal: argumento ambiguo ‘origen…’: revisión desconocida o ruta que no está en el árbol de trabajo.

    – insignar

    22 de noviembre de 2020 a las 23:43

  • No, muestra todas las confirmaciones más recientes que difieren, pero no responde a la pregunta original.

    – Fabien Haddadi

    12 mayo 2021 a las 15:46

Todas las demás respuestas hablan de “aguas arriba” (la rama de la que extraes).
pero un sucursal local poder empujar a un diferente rama que la que arranca.

A master podría no enviar a la rama de seguimiento remoto “origin/master“.
El río arriba sucursal para master puede ser origin/masterpero podría empujar a la rama de seguimiento remoto origin/xxx o incluso anotherUpstreamRepo/yyy.
Esos son establecidos por branch.*.pushremote para la rama actual junto con la global remote.pushDefault valor.

Es eso rama de seguimiento remoto que cuenta cuando se buscan confirmaciones no insertadas: la que rastrea el branch at the remote donde el sucursal local sería empujado a.
El branch at the remote puede ser, de nuevo, origin/xxx o incluso anotherUpstreamRepo/yyy.

Git 2.5+ (Q2 2015) presenta un nuevo atajo para eso: <branch>@{push}

Ver cometer 29bc885, confirmar 3dbe9db, cometer adfe5d0, cometer 48c5847, cometer a1ad0eb, cometer e291c75, cometer 979cb24, cometer 1ca41a1, cometer 3a429d0, cometer a9f9f8c, cometer 8770e6f, cometer da66b27, cometer f052154, cometer 9e3751d, cometer ee2499f [all from 21 May 2015]y cometer e41bf35 [01 May 2015] por jeff rey (peff).
(Combinado por Junio ​​C Hamano — gitster en cometer c4a835405 de junio de 2015)

Confirmar adfe5d0 explica:

sha1_name: implementar @{push} taquigrafía

En un flujo de trabajo triangular, cada rama puede tener dos puntos distintos de interés: el @{upstream} desde el que normalmente tira y el destino al que normalmente empuja. No hay una abreviatura para esto último, pero es útil tenerlo.

Por ejemplo, es posible que desee saber qué compromisos aún no ha enviado:

git log @{push}..

O como un ejemplo más complicado, imagine que normalmente extrae cambios de origin/master (que usted establece como su @{upstream}) y enviar cambios a su bifurcación (por ejemplo, como myfork/topic).
Puede empujar su horquilla desde varias máquinas, lo que requiere que integrar los cambios desde el destino de inserción, en lugar de aguas arriba.
Con este parche, solo puedes hacer:

git rebase @{push}

en lugar de escribir el nombre completo.

Confirmar 29bc885 agrega:

for-each-ref: aceptar “%(push)” formato

Así como tenemos “%(upstream)“para denunciar”@{upstream}” para cada ref, este parche agrega “%(push)“hacer coincidir”@{push}“.
Admite los mismos modificadores de formato de seguimiento que upstream (porque es posible que desee saber, por ejemplo, qué sucursales tienen confirmaciones para enviar).

Si desea ver cuántos compromisos tienen sus sucursales locales delante/detrás en comparación con la rama a la que está empujando:

git for-each-ref --format="%(refname:short) %(push:track)" refs/heads

  • Cada vez que veo una respuesta con git log y “2-dots-not-3”, siempre me recuerda a stackoverflow.com/questions/53569/… 😉

    – VoC

    6 de enero de 2010 a las 22:56

  • Solo para agregarlo a la respuesta: si no hay una configuración ascendente, este comando da como resultado que no se haya configurado una configuración ascendente. Correr git branch --set-upstream master origin/<branch> para configurar upstream si está inclinado a usar este comando para ver las confirmaciones que están preparadas.

    – espera asincrónica

    7 de agosto de 2013 a las 13:27

  • Esto se comparará con la sucursal predeterminada en el origen, no con la sucursal remota actual.

    – greuze

    18 de junio de 2014 a las 7:20

  • fatal: argumento ambiguo ‘origen…’: revisión desconocida o ruta que no está en el árbol de trabajo.

    – insignar

    22 de noviembre de 2020 a las 23:43

  • No, muestra todas las confirmaciones más recientes que difieren, pero no responde a la pregunta original.

    – Fabien Haddadi

    12 mayo 2021 a las 15:46

Avatar de usuario de Sunil Garg
Sunil Garg

Tuve una confirmación realizada previamente, no enviada a ninguna rama, ni remota ni local. Solo el compromiso. Nada de otras respuestas funcionó para mí, pero con:

git reflog

Allí encontré mi compromiso.

  • Como se indica en este enlace git-scm.com/docs/git-reflog, Los registros de referencia, o “reflogs”, registran cuándo se actualizaron las puntas de las sucursales y otras referencias en el repositorio local. En mi caso, cloné un repositorio, creé una nueva rama, eliminé la rama, creé una nueva, creé una confirmación y cambié la confirmación. Todos estos pasos fueron registrados como HEAD@{0}: commit (enmendar) : .. HEAD@{1}: commit: … HEAD@{2}: checkout: pasando de… a … HEAD@{ 3}: checkout: pasando de… a… HEAD@{4}: clon: from #lo siento por el formato SO aparentemente no permite líneas múltiples en los comentarios

    – velocidad

    22 de abril de 2020 a las 22:17


  • esto también incluye las confirmaciones de origen, la mejor solución sería usar el comando proporcionado por @PlagueHammer (stackoverflow.com/a/2016954/624048)

    –Lincoln

    25 de mayo de 2020 a las 12:13


¿Ha sido útil esta solución?