English ▾ Themen ▾ Neueste Version ▾ git-cherry zuletzt aktualisiert in 2.0.5

NAME

git-cherry - Commits finden, die noch nicht auf den Upstream angewendet wurden

SYNOPSIS

git cherry [-v] [<upstream> [<head> [<limit>]]]

BESCHREIBUNG

Bestimmt, ob Commits im Bereich <head>..<upstream> vorhanden sind, die äquivalent zu denen im Bereich <limit>..<span class="hover-term" data-term="head"><head></span> sind.

Der Äquivalenztest basiert auf dem Diff, nachdem Leerzeichen und Zeilennummern entfernt wurden. git-cherry erkennt daher, wann Commits durch git-cherry-pick[1], git-am[1] oder git-rebase[1] "kopiert" wurden.

Gibt die SHA1-Hashes jedes Commits im Bereich <limit>..<span class="hover-term" data-term="head"><head></span> aus, mit einem Präfix - für Commits, die ein Äquivalent in <upstream> haben, und + für Commits, die keines haben.

OPTIONEN

-v

Zeigt die Commit-Betreffzeilen neben den SHA1-Hashes an.

<upstream>

Upstream-Branch, in dem nach äquivalenten Commits gesucht werden soll. Standardmäßig der Upstream-Branch von HEAD.

<head>

Arbeits-Branch; Standardmäßig HEAD.

<limit>

Berichtet keine Commits bis einschließlich (und einschließlich) limit.

BEISPIELE

Patch-Workflows

git-cherry wird häufig in patch-basierten Workflows (siehe gitworkflows[7]) verwendet, um festzustellen, ob eine Reihe von Patches vom Upstream-Maintainer angewendet wurde. In einem solchen Workflow könnten Sie einen Topic-Branch wie folgt erstellen und senden:

$ git checkout -b topic origin/master
# work and create some commits
$ git format-patch origin/master
$ git send-email ... 00*

Später können Sie prüfen, ob Ihre Änderungen angewendet wurden, indem Sie (immer noch auf topic) Folgendes ausführen:

$ git fetch  # update your notion of origin/master
$ git cherry -v

Konkretes Beispiel

In einer Situation, in der topic aus drei Commits bestand und der Maintainer zwei davon angewendet hat, könnte die Situation wie folgt aussehen:

$ git log --graph --oneline --decorate --boundary origin/master...topic
* 7654321 (origin/master) upstream tip commit
[... snip some other commits ...]
* cccc111 cherry-pick of C
* aaaa111 cherry-pick of A
[... snip a lot more that has happened ...]
| * cccc000 (topic) commit C
| * bbbb000 commit B
| * aaaa000 commit A
|/
o 1234567 branch point

In solchen Fällen zeigt git-cherry eine prägnante Zusammenfassung dessen, was noch angewendet werden muss:

$ git cherry origin/master topic
- cccc000... commit C
+ bbbb000... commit B
- aaaa000... commit A

Hier sehen wir, dass die Commits A und C (markiert mit -) aus Ihrem topic-Branch gelöscht werden können, wenn Sie ihn auf origin/master neu basisen, während der Commit B (markiert mit +) beibehalten werden muss, damit er zur Anwendung auf origin/master gesendet wird.

Verwendung eines Limits

Das optionale <limit> ist nützlich in Fällen, in denen Ihr Thema auf anderer Arbeit basiert, die nicht im Upstream enthalten ist. Aufbauend auf dem vorherigen Beispiel könnte dies so aussehen:

$ git log --graph --oneline --decorate --boundary origin/master...topic
* 7654321 (origin/master) upstream tip commit
[... snip some other commits ...]
* cccc111 cherry-pick of C
* aaaa111 cherry-pick of A
[... snip a lot more that has happened ...]
| * cccc000 (topic) commit C
| * bbbb000 commit B
| * aaaa000 commit A
| * 0000fff (base) unpublished stuff F
[... snip ...]
| * 0000aaa unpublished stuff A
|/
o 1234567 merge-base between upstream and topic

Durch die Angabe von base als Limit können Sie vermeiden, Commits zwischen base und topic aufzulisten.

$ git cherry origin/master topic base
- cccc000... commit C
+ bbbb000... commit B
- aaaa000... commit A

SIEHE AUCH

git-patch-id[1]

GIT

Teil der git[1] Suite