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/master
pero no siempre.
¿Se trata de un error con mi instalación de Git o me estoy perdiendo algo?
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
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ó agit 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
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
Cristian Vielma
git cherry -v
Tomado de: Git: vea todas las confirmaciones no enviadas o confirmaciones que no están en otra rama.
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 HEAD
que 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/master
pero 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, comomyfork/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
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
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; ogit 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