Josh Bühler
Wie kann ich alle von mir vorgenommenen lokalen Commits anzeigen, die noch nicht in das Remote-Repository übertragen wurden? Ab und zu, git status wird ausdrucken, dass mein Zweig X Commits vor sich hat origin/masteraber nicht immer.
Ist das ein Fehler bei meiner Git-Installation oder übersehe ich etwas?
Peter B
Dies ergibt ein Protokoll aller Commits zwischen Origin/Master und HEAD:
git log origin/master..HEAD
Wenn sich HEAD im Master-Zweig befindet, wird ein Protokoll der nicht gepushten Commits angezeigt.
Um den Unterschied anzuzeigen, gehen Sie wie folgt vor:
git diff origin/master..HEAD
Das hat es für mich getan – aus irgendeinem Grund hat git log origin.. allein einen Fehler ausgegeben. Offenbar hatte ich auch ein Problem mit der Konfiguration meiner lokalen Zweigstelle – nachdem ich die hier gefundenen Änderungen vorgenommen hatte: wincent.com/blog/… …das Problem wurde gelöst und ich konnte git status erneut verwenden, um zu sehen, was ich wollte.
– Josh Bühler
6. Januar 2010 um 22:57
Von unschätzbarem Wert: So sehr, dass ich es getan habe git config --global alias.ahead "log origin/master..HEAD --oneline" damit ich schnell herausfinden kann, wo ich bin. Noch mehr Süßigkeiten: for i in *; do echo $i && git ahead 2>/dev/null; done
– Jamie
28. Februar 2012 um 14:50 Uhr
git log --stat origin/master..HEAD für ein bisschen mehr Großartigkeit
– Cory Danielson
25. März 2013 um 17:51
Dies ist nicht die beste Lösung. Ursprung/Master ist möglicherweise nicht immer der Upstream-Zweig. Eine bessere Lösung besteht darin, @{u} anstelle von „origin/master“ zu verwenden, um den Upstream-Zweig anzugeben. Da HEAD standardmäßig impliziert ist, kann man dies auch weglassen. Siehe die Antwort von @Ben Ling. Ausgehende Änderungen: git log @{u}.. Eingehende Änderungen: git log ..@{u}
– Debajit
12. Juni 2013 um 22:59
@Nocturne Ich möchte nur darauf hinweisen, dass, als diese Antwort veröffentlicht wurde, die @{u} Die Syntax war noch nicht verfügbar, sie wurde erst verfügbar unter 12. Februar 2010. Auch, @{u} funktioniert nicht, wenn der lokale Zweig nicht mit einem Upstream konfiguriert ist. Endlich, @{u} bietet derzeit keine Unterstützung für die Tab-Vervollständigung, <remote>/<branch> Die Tab-Vervollständigung ist nach wie vor eine der schnellsten Möglichkeiten, diese Informationen zu erhalten, und sie funktioniert unabhängig davon, ob ein Upstream konfiguriert ist oder nicht.
– Benutzer456814
1. Juli 2014 um 0:46
cxreg
So sehen Sie alle Commits für alle Zweige, die noch nicht gepusht wurden:
git log --branches --not --remotes
So sehen Sie den neuesten Commit für jeden Zweig sowie die Zweignamen:
git log --branches --not --remotes --simplify-by-decoration --decorate --oneline
Das ist fantastisch. In einem ähnlichen Szenario hatte ich zwei lokale Niederlassungen mit zwei vorgelagerten Niederlassungen, und eine lokale Hand wurde mit der anderen zusammengelegt. Ich wollte wissen, welche Commits sicher rebasiert werden können, aber das ist normal git log master..HEAD würde nicht funktionieren, da es mehrere Upstreams gab. Dieser Beitrag hat mich dazu geführt git log MyBranch --not --remotes um alle Commits anzuzeigen, die nicht an einen Upstream in einem einzelnen Zweig gepusht wurden.
– Pavon
12. Juli 2014 um 2:10
Ich verstehe, dass Ihr zweiter Befehl auch die Commits auflistet, die noch nicht gepusht wurden, nur dass nur einer pro Zweig angezeigt wird.
– Stephane
30. März 2016 um 6:19 Uhr
--decorate zeigt auch die Zweige. --graph macht es noch deutlicher.
– Strahl
20. Dezember 2016 um 11:19 Uhr
Beachten Sie, dass diese Befehle nur Commits auflisten, die nicht übertragen wurden beliebig Zweig. Beispiel: Angenommen, Sie haben einen Zweig mit branch feat-NewThing entwickelt. Sie nehmen Änderungen lokal an feat-NewThing vor. (Das Protokoll weist Änderungen auf.) Anschließend verschieben Sie feat-newThing in den Remote-Zweig. (Protokoll ist leer). Sie führen lokales feat-newThing zusammen, um es lokal zu entwickeln. Unter der Annahme eines schnellen Vorlaufs weist das Protokoll immer noch keine Änderungen auf.
– Patrick W
17. Januar 2017 um 0:02
Das ist die eigentliche Lösung. Der einzige, der im Allgemeinen funktioniert, ohne dass ein Zweig angegeben werden muss oder ein Upstream definiert werden muss.
– Das ist mein Design
5. September 2017 um 10:02 Uhr
Ben Lings
Zeigen Sie alle Commits an, die Sie lokal, aber nicht im Upstream haben, mit:
git log @{u}..
@{u} oder @{upstream} bedeutet den Upstream-Zweig des aktuellen Zweigs (siehe git rev-parse --help oder git help revisions für Details).
Unter Windows musste ich das letzte Argument in Anführungszeichen setzen, etwa: git log „@{u}..“
– Jon Schneider
15. November 2016 um 13:48 Uhr
git log @{u}.. -p Eine der nützlichsten Optionen ist -Pdas die in jeder Bestätigung eingeführten Unterschiede zeigt.
– mQuiroz
20. September 2018 um 18:50 Uhr
Möglicherweise besser git log @{push}.., siehe eine andere Antwort.
– Dr. Hans-Peter Störr
26. November 2019 um 12:13 Uhr
Ich fand, dass dies die beste Antwort ist. Ich habe auch herausgefunden, dass ich es ohne einen Spickzettel auf keinen Fall im Gedächtnis behalten kann. Warum haben die Git-Entwickler nicht etwas Offensichtliches gewählt und im Einklang mit dem Git-Status, da wir das wissen wollen? Status einer Situation. git status -v hätte so viel mehr Sinn gemacht.
– Fabien Haddadi
12. Mai 2021 um 15:49 Uhr
Christian Vielma
git cherry -v
Genommen von: Git: Alle nicht gepushten Commits oder Commits anzeigen, die sich nicht in einem anderen Zweig befinden.
Greg Hewgill
git log origin/master..
Dies setzt das voraus origin ist der Name Ihrer Upstream-Fernbedienung und master ist der Name Ihres Upstream-Zweigs. Lassen Sie danach den Revisionsnamen weg .. impliziert HEADdas die neuen Commits auflistet, die nicht gepusht wurden. [git log]
Immer wenn ich eine Antwort mit sehe git log und „2-Punkte-nicht-3“, es erinnert mich immer an stackoverflow.com/questions/53569/… 😉
– VonC
6. Januar 2010 um 22:56
Nur um es der Antwort hinzuzufügen: Wenn kein Upstream-Setup vorhanden ist, führt dieser Befehl dazu, dass kein Upstream eingerichtet wurde. Laufen git branch --set-upstream master origin/<branch> zum Einrichten im Upstream, wenn Sie diesen Befehl verwenden möchten, um bereitgestellte Commits anzuzeigen.
– asyncwait
7. August 2013 um 13:27
Dies wird mit dem Standardzweig im Ursprung verglichen, nicht mit dem aktuellen Remotezweig.
– greuze
18. Juni 2014 um 7:20 Uhr
Fatal: Mehrdeutiges Argument „Origin..“: Unbekannte Revision oder Pfad nicht im Arbeitsbaum.
– sign
22. November 2020 um 23:43 Uhr
Nein, es zeigt alle aktuellen Commits an, die sich unterscheiden, beantwortet aber nicht die ursprüngliche Frage.
– Fabien Haddadi
12. Mai 2021 um 15:46 Uhr
In allen anderen Antworten geht es um „Upstream“ (den Zweig, aus dem Sie ziehen).
Aber a Lokale Niederlassung dürfen drücken zu einem anders Zweig als der, aus dem es zieht.
A master wird möglicherweise nicht an den Remote-Tracking-Zweig weitergeleitet.origin/master“.
Der stromaufwärts Zweig für master mag sein origin/masteraber es könnte an den Remote-Tracking-Zweig weitergeleitet werden origin/xxx oder auch anotherUpstreamRepo/yyy.
Diese werden von festgelegt branch.*.pushremote für den aktuellen Zweig zusammen mit dem global remote.pushDefault Wert.
Es ist Das Remote-Tracking-Zweig, der bei der Suche nach nicht gepushten Commits zählt: derjenige, der die verfolgt branch at the remote bei dem die Lokale Niederlassung würde dazu gedrängt werden.
Der branch at the remote kann wieder sein, origin/xxx oder auch anotherUpstreamRepo/yyy.
<branch>@{push}Sehen Commit 29bc885, Commit 3dbe9db, begehen Sie adfe5d0, Commit 48c5847, Commit a1ad0eb, e291c75 begehen, Commit 979cb24, 1ca41a1 begehen, Commit 3a429d0, Commit a9f9f8c, Commit 8770e6f, Commit da66b27, Commit f052154, Commit 9e3751d, Commit ee2499f [all from 21 May 2015]Und Commit e41bf35 [01 May 2015] von Jeff King (peff).
(Zusammengeführt von Junio C Hamano — gitster — In c4a8354 begehen05.06.2015)
Commit adfe5d0 erklärt:
sha1_name: implementieren@{push}Kurzschrift
In einem dreieckigen Workflow kann jeder Zweig zwei unterschiedliche Interessenpunkte haben: den
@{upstream}von dem Sie normalerweise ziehen, und das Ziel, zu dem Sie normalerweise pushen. Für Letzteres gibt es keine Abkürzung, aber es ist nützlich, sie zu haben.Zum Beispiel, Vielleicht möchten Sie wissen, welche Commits Sie noch nicht gepusht haben:
git log @{push}..Oder stellen Sie sich als komplizierteres Beispiel vor, dass Sie normalerweise Änderungen vornehmen
origin/master(die Sie als Ihre festgelegt haben@{upstream}) und Änderungen an Ihren Fork übertragen (z. B. asmyfork/topic).
Sie können von mehreren Maschinen aus auf Ihren Fork pushen, wenn dies erforderlich ist Integrieren Sie die Änderungen vom Push-Ziel und nicht vom Upstream.
Mit diesem Patch können Sie einfach Folgendes tun:git rebase @{push}anstatt den vollständigen Namen einzugeben.
Commit 29bc885 fügt hinzu:
for-each-ref: akzeptieren “%(push)” Format
So wie wir es getan haben“
%(upstream)„zu melden“@{upstream}„Für jede Referenz fügt dieser Patch hinzu:“%(push)” passen “@{push}“.
Es unterstützt die gleichen Tracking-Formatmodifikatoren wie Upstream (weil Möglicherweise möchten Sie beispielsweise wissen, welche Zweige Commits zum Pushen haben).
Wenn Sie sehen möchten, wie viele Commits Ihre lokalen Niederlassungen haben vor/hinten im Vergleich zu der Branche, zu der Sie pushen:
git for-each-ref --format="%(refname:short) %(push:track)" refs/heads
Immer wenn ich eine Antwort mit sehe git log und „2-Punkte-nicht-3“, es erinnert mich immer an stackoverflow.com/questions/53569/… 😉
– VonC
6. Januar 2010 um 22:56
Nur um es der Antwort hinzuzufügen: Wenn kein Upstream-Setup vorhanden ist, führt dieser Befehl dazu, dass kein Upstream eingerichtet wurde. Laufen git branch --set-upstream master origin/<branch> zum Einrichten im Upstream, wenn Sie diesen Befehl verwenden möchten, um bereitgestellte Commits anzuzeigen.
– asyncwait
7. August 2013 um 13:27
Dies wird mit dem Standardzweig im Ursprung verglichen, nicht mit dem aktuellen Remotezweig.
– greuze
18. Juni 2014 um 7:20 Uhr
Fatal: Mehrdeutiges Argument „Origin..“: Unbekannte Revision oder Pfad nicht im Arbeitsbaum.
– sign
22. November 2020 um 23:43 Uhr
Nein, es zeigt alle aktuellen Commits an, die sich unterscheiden, beantwortet aber nicht die ursprüngliche Frage.
– Fabien Haddadi
12. Mai 2021 um 15:46 Uhr
Sunil Garg
Ich habe zuvor einen Commit durchführen lassen, der weder an einen Zweig noch an eine entfernte Stelle oder lokal gepusht wurde. Nur das Commit. Nichts aus anderen Antworten hat bei mir funktioniert, aber mit:
git reflog
Dort habe ich mein Commit gefunden.
Wie in diesem Link angegeben git-scm.com/docs/git-reflogReferenzprotokolle oder „Reflogs“ zeichnen auf, wann die Tipps von Zweigen und anderen Referenzen im lokalen Repository aktualisiert wurden. In meinem Fall habe ich ein Repo geklont, einen neuen Zweig erstellt, den Zweig gelöscht, einen neuen erstellt, einen Commit erstellt und den Commit geändert. Alle diese Schritte wurden als HEAD@{0}: commit (ändern) : .. HEAD@{1}: commit: … HEAD@{2}: ausgecheckt: Verschieben von … nach … HEAD@{ aufgezeichnet. 3}: ausgecheckt: Verschieben von… nach … HEAD@{4}: Klonen: von #Entschuldigung für das Format. SO erlaubt anscheinend keine Mehrzeilen in Kommentaren
– Geschwindigkeit
22. April 2020 um 22:17 Uhr
Dazu gehören auch die Ursprungs-Commits. Die beste Lösung wäre die Verwendung des von @PlagueHammer bereitgestellten Befehls (stackoverflow.com/a/2016954/624048).
– Lincoln
25. Mai 2020 um 12:13 Uhr
Beginnend mit Git 2.5+ (Q2 2015) wäre die eigentliche Antwort
git log @{push}... Sehen Sie sich die neue Verknüpfung an@{push}(unter Bezugnahme auf den Remote-Tracking-Zweig, zu dem Sie pushen) in meiner Antwort unten– VonC
8. Juni 2015 um 22:44
@Torek – noch eine einfache Aufgabe, die Git erschwert. Jedes Mal, wenn eine Git-Frage mit Hunderten oder Tausenden von Upvotes und Millionen von Aufrufen auftaucht, sollte jemand denken: Wow, wir haben diesen Workflow wirklich vermasselt. Leider haben die Git-Entwickler den Feedback-Schritt im Entwicklungslebenszyklus ausgelassen, sodass das Feedback nicht berücksichtigt wird. Stattdessen machen sie immer wieder die gleichen Fehler. Zu dieser Frage:
git status --allhätte 2010 erscheinen sollen; odergit status -vsollte eigentlich die ausführliche Ausgabe liefern, die die zusätzlichen Informationen enthält.– jww
10. Juli 2016 um 19:32 Uhr
Ich bin nicht der Meinung, dass „git status -v“ diese Informationen bereitstellen sollte, da sie den Status des Arbeitsbaums anzeigen sollen, da sie sich nur auf den ausgecheckten Zweig beziehen. Sehen Sie sich jedoch die Antwort unten zu „git branch -v“ an, die meiner Meinung nach die akzeptierte Antwort sein sollte
– JoelFan
31. Januar 2017 um 19:38
Diese spezielle StackOverflow-Frage hat die meisten richtigen Antworten, die alle funktionieren, aber keinen Sinn ergeben.
– Pete Alvin
11. Januar 2018 um 21:20 Uhr
@jww: Ich stimme zu. Nach der Verwendung von Mercurial bin ich wieder zur Verwendung von Git übergegangen. Verglichen mit der Benutzerfreundlichkeit und Eleganz von Mercurial ist Git ein verfälschtes Durcheinander
– Paul
24. November 2020 um 14:11 Uhr