Einrichtung und Konfiguration
Projekte holen und erstellen
Grundlegende Snapshots
Branching und Merging
Projekte teilen und aktualisieren
Inspektion und Vergleich
Patching
Debugging
Externe Systeme
Server-Administration
Anleitungen
- gitattributes
- Konventionen der Kommandozeile
- Tägliches Git
- Häufig gestellte Fragen (FAQ)
- Glossar
- Hooks
- gitignore
- gitmodules
- Revisionen
- Submodule
- Tutorial
- Workflows
- Alle Anleitungen...
Administration
Plumbing-Befehle
-
2.52.0
2025-11-17
-
2.51.2
2025-10-27
- 2.51.1 keine Änderungen
-
2.51.0
2025-08-18
- 2.50.1 keine Änderungen
-
2.50.0
2025-06-16
- 2.49.1 keine Änderungen
-
2.49.0
2025-03-14
- 2.48.1 → 2.48.2 keine Änderungen
-
2.48.0
2025-01-10
- 2.45.1 → 2.47.3 keine Änderungen
-
2.45.0
2024-04-29
- 2.43.3 → 2.44.4 keine Änderungen
-
2.43.2
2024-02-13
- 2.43.1 keine Änderungen
-
2.43.0
2023-11-20
- 2.42.1 → 2.42.4 keine Änderungen
-
2.42.0
2023-08-21
- 2.41.1 → 2.41.3 keine Änderungen
-
2.41.0
2023-06-01
- 2.40.1 → 2.40.4 keine Änderungen
-
2.40.0
2023-03-12
- 2.39.1 → 2.39.5 keine Änderungen
-
2.39.0
2022-12-12
- 2.38.1 → 2.38.5 keine Änderungen
-
2.38.0
2022-10-02
- 2.37.1 → 2.37.7 keine Änderungen
-
2.37.0
2022-06-27
- 2.36.1 → 2.36.6 keine Änderungen
-
2.36.0
2022-04-18
- 2.35.1 → 2.35.8 keine Änderungen
-
2.35.0
2022-01-24
- 2.33.3 → 2.34.8 keine Änderungen
-
2.33.2
2022-03-23
-
2.33.1
2021-10-12
-
2.33.0
2021-08-16
- 2.32.1 → 2.32.7 keine Änderungen
-
2.32.0
2021-06-06
- 2.31.1 → 2.31.8 keine Änderungen
-
2.31.0
2021-03-15
- 2.30.1 → 2.30.9 keine Änderungen
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 keine Änderungen
-
2.29.0
2020-10-19
- 2.27.1 → 2.28.1 keine Änderungen
-
2.27.0
2020-06-01
- 2.25.1 → 2.26.3 keine Änderungen
-
2.25.0
2020-01-13
- 2.18.1 → 2.24.4 keine Änderungen
-
2.18.0
2018-06-21
- 2.13.7 → 2.17.6 keine Änderungen
-
2.12.5
2017-09-22
- 2.1.4 → 2.11.4 keine Änderungen
-
2.0.5
2014-12-17
SYNOPSIS
git shortlog [<options>] [<revision-range>] [[--] <path>…] git log --pretty=short | git shortlog [<options>]
BESCHREIBUNG
Fasst die Ausgabe von git log in einem Format zusammen, das für die Aufnahme in Release-Ankündigungen geeignet ist. Jeder Commit wird nach Autor und Titel gruppiert.
Zusätzlich wird "[PATCH]" aus der Commit-Beschreibung entfernt.
Wenn keine Revisionen auf der Kommandozeile übergeben werden und entweder die Standardeingabe kein Terminal ist oder es keinen aktuellen Branch gibt, gibt git shortlog eine Zusammenfassung des von der Standardeingabe gelesenen Logs aus, ohne Bezug auf das aktuelle Repository.
OPTIONEN
- -n
- --numbered
-
Sortiert die Ausgabe nach der Anzahl der Commits pro Autor anstelle der alphabetischen Reihenfolge der Autoren.
- -s
- --summary
-
Unterdrückt die Commit-Beschreibung und liefert nur eine Zusammenfassung der Commit-Anzahl.
- -e
-
Zeigt die E-Mail-Adresse jedes Autors an.
- --format[=<format>]
-
Anstelle des Commit-Betreffs wird eine andere Information zur Beschreibung jedes Commits verwendet. <format> kann eine beliebige Zeichenkette sein, die von der
--formatOption von git log akzeptiert wird, z. B. * [%h] %s. (Siehe den Abschnitt "PRETTY FORMATS" in git-log[1].)Jeder hübsch formatierte Commit wird neu umbrochen, bevor er angezeigt wird.
- --date=<format>
-
Zeigt Daten formatiert gemäß dem angegebenen Datumsstring an. (Siehe die
--dateOption im Abschnitt "Commit Formatting" von git-log[1]). Nützlich mit--group=format:<format>. - --group=<type>
-
Gruppiert Commits basierend auf <type>. Wenn keine
--groupOption angegeben ist, ist der Standardwertauthor. <type> ist einer von-
author, Commits werden nach Autor gruppiert -
committer, Commits werden nach Committer gruppiert (dasselbe wie-c) -
trailer:<field>, das <field> wird als ein Groß-/Kleinschreibungs-unabhängiger Commit-Nachrichten-Trailer interpretiert (siehe git-interpret-trailers[1]). Wenn Ihr Projekt beispielsweiseReviewed-byTrailer verwendet, möchten Sie vielleicht sehen, wer mitgitshortlog-ns--group=trailer:reviewed-byüberprüft hat. -
format:<format>, eine beliebige Zeichenkette, die von der--formatOption von git log akzeptiert wird. (Siehe den Abschnitt "PRETTY FORMATS" in git-log[1].)Beachten Sie, dass Commits, die den Trailer nicht enthalten, nicht gezählt werden. Ebenso können Commits mit mehreren Trailern (z. B. mehrere Sign-offs) mehr als einmal gezählt werden (aber nur einmal pro eindeutigem Trailernamen in diesem Commit).
Shortlog versucht, jeden Trailernamen als eine
name<email> Identität zu parsen. Wenn dies erfolgreich ist, wird die Mailmap angewendet und die E-Mail weggelassen, es sei denn, die Option--emailwird angegeben. Wenn der Wert nicht als Identität geparst werden kann, wird er wörtlich und vollständig übernommen.
Wenn
--groupmehrmals angegeben wird, werden Commits unter jedem Wert gezählt (aber wieder nur einmal pro eindeutigem Wert in diesem Commit). Zum Beispiel zähltgitshortlog--group=author--group=trailer:co-authored-bysowohl Autoren als auch Co-Autoren. -
- -c
- --committer
-
Dies ist ein Alias für
--group=committer. - -w[<width>[,<indent1>[,<indent2>]]]
-
Zeilenumbruch der Ausgabe, indem jede Zeile bei
widthumgebrochen wird. Die erste Zeile jeder Eingabe wird umindent1Leerzeichen eingerückt, und die zweite und nachfolgende Zeilen werden umindent2Leerzeichen eingerückt.width,indent1undindent2sind standardmäßig 76, 6 und 9.Wenn die Breite
0(Null) ist, werden die Zeilen der Ausgabe eingerückt, ohne sie umzubrechen. - <revision-range>
-
Zeigt nur Commits im angegebenen Revisionsbereich an. Wenn keine <revision-range> angegeben ist, wird standardmäßig
HEADverwendet (d.h. die gesamte Historie, die zum aktuellen Commit führt).origin..HEADgibt alle Commits an, die vom aktuellen Commit (d.h.HEAD) erreichbar sind, aber nicht vonorigin. Eine vollständige Liste der Schreibweisen für <revision-range> finden Sie im Abschnitt "Specifying Ranges" von gitrevisions[7]. - [--] <path>…
-
Berücksichtigt nur Commits, die ausreichen, um zu erklären, wie die Dateien, die den angegebenen Pfaden entsprechen, entstanden sind.
Pfade müssen möglicherweise mit
--vorangestellt werden, um sie von Optionen oder dem Revisionsbereich zu trennen, wenn Verwirrung entsteht.
Commit-Limitierung
Zusätzlich zur Angabe eines Commit-Bereichs, der mithilfe der speziellen Notationen, die in der Beschreibung erläutert werden, aufgelistet werden soll, können weitere Commit-Limitierungen angewendet werden.
Die Verwendung von mehr Optionen beschränkt in der Regel die Ausgabe weiter (z. B. beschränkt --since=<date1> auf neuere Commits als <date1>, und die Verwendung mit --grep=<pattern> schränkt weiter auf Commits ein, deren Log-Nachricht eine Zeile enthält, die <pattern> entspricht), sofern nicht anders angegeben.
Beachten Sie, dass diese Optionen vor Commit-Sortier- und Formatierungsoptionen wie --reverse angewendet werden.
-<number>-n<number>--max-count=<number>-
Begrenzt die Ausgabe auf <number> Commits.
--skip=<number>-
Überspringt <number> Commits, bevor die Commit-Ausgabe angezeigt wird.
--since=<date>--after=<date>-
Zeigt Commits neuer als <date> an.
--since-as-filter=<date>-
Zeigt alle Commits neuer als <date> an. Dabei werden alle Commits im Bereich durchlaufen, anstatt beim ersten Commit anzuhalten, der älter als <date> ist.
--until=<date>--before=<date>-
Zeigt Commits älter als <date> an.
--author=<pattern>--committer=<pattern>-
Beschränkt die Ausgabe von Commits auf solche, deren Autor-/Committer-Headerzeilen dem regulären Ausdruck <pattern> entsprechen. Bei mehr als einem
--author=<pattern> werden Commits ausgewählt, deren Autor eines der <pattern> erfüllt (ähnlich für mehrere--committer=<pattern>). --grep-reflog=<pattern>-
Beschränkt die Ausgabe von Commits auf solche mit Reflog-Einträgen, die dem regulären Ausdruck <pattern> entsprechen. Bei mehr als einem
--grep-reflogwerden Commits ausgewählt, deren Reflog-Nachricht einem der angegebenen Muster entspricht. Es ist ein Fehler, diese Option zu verwenden, es sei denn,--walk-reflogswird verwendet. --grep=<pattern>-
Beschränkt die Ausgabe von Commits auf solche mit einer Log-Nachricht, die dem regulären Ausdruck <pattern> entspricht. Bei mehr als einem
--grep=<pattern> werden Commits ausgewählt, deren Nachricht einem der <pattern> entspricht (aber siehe--all-match).Wenn
--notesaktiv ist, wird die Nachricht aus den Notizen so abgeglichen, als wäre sie Teil der Log-Nachricht. --all-match-
Beschränkt die Ausgabe von Commits auf solche, die allen angegebenen
--grep-Mustern entsprechen, anstatt solchen, die mindestens einem entsprechen. --invert-grep-
Beschränkt die Ausgabe von Commits auf solche mit einer Log-Nachricht, die nicht dem mit
--grep=<pattern> angegebenen <pattern> entsprechen. -i--regexp-ignore-case-
Gleicht die regulären Ausdrucksmuster für die Beschränkung ohne Berücksichtigung der Groß- und Kleinschreibung ab.
--basic-regexp-
Betrachtet die Muster für die Beschränkung als grundlegende reguläre Ausdrücke; dies ist der Standard.
-E--extended-regexp-
Betrachtet die Muster für die Beschränkung als erweiterte reguläre Ausdrücke anstelle der standardmäßigen grundlegenden regulären Ausdrücke.
-F--fixed-strings-
Betrachtet die Muster für die Beschränkung als feste Zeichenketten (interpretiert Muster nicht als regulären Ausdruck).
-P--perl-regexp-
Betrachtet die Muster für die Beschränkung als Perl-kompatible reguläre Ausdrücke.
Die Unterstützung für diese Arten von regulären Ausdrücken ist eine optionale Abhängigkeit zur Kompilierzeit. Wenn Git nicht mit Unterstützung dafür kompiliert wurde, führt die Bereitstellung dieser Option zum Abbruch.
--remove-empty-
Stoppt, wenn ein bestimmter Pfad aus dem Baum verschwindet.
--merges-
Gibt nur Merge-Commits aus. Dies ist exakt dasselbe wie
--min-parents=2. --no-merges-
Gibt keine Commits mit mehr als einem Elternteil aus. Dies ist exakt dasselbe wie
--max-parents=1. --min-parents=<number>--max-parents=<number>--no-min-parents--no-max-parents-
Zeigt nur Commits an, die mindestens (oder höchstens) so viele Eltern-Commits haben. Insbesondere ist
--max-parents=1dasselbe wie--no-merges,--min-parents=2ist dasselbe wie--merges.--max-parents=0gibt alle Wurzel-Commits und--min-parents=3alle Octopus-Merges aus.--no-min-parentsund--no-max-parentssetzen diese Limits wieder auf keine Begrenzung zurück. Äquivalente Formen sind--min-parents=0(jeder Commit hat 0 oder mehr Eltern) und--max-parents=-1(negative Zahlen bedeuten keine Obergrenze). --first-parent-
Bei der Suche nach einzubeziehenden Commits wird nur dem ersten Eltern-Commit gefolgt, wenn ein Merge-Commit angetroffen wird. Diese Option kann eine bessere Übersicht beim Betrachten der Entwicklung eines bestimmten Topic-Branches geben, da Merges in einen Topic-Branch tendenziell nur dazu dienen, von Zeit zu Zeit mit dem aktualisierten Upstream synchron zu werden. Diese Option erlaubt es Ihnen, die einzelnen Commits zu ignorieren, die durch einen solchen Merge in Ihre Historie gebracht wurden.
--exclude-first-parent-only-
Bei der Suche nach auszuschließenden Commits (mit einem ^) wird nur dem ersten Eltern-Commit gefolgt, wenn ein Merge-Commit angetroffen wird. Dies kann verwendet werden, um die Menge der Änderungen in einem Topic-Branch ab dem Punkt zu finden, an dem er sich vom Remote-Branch abzweigte, vorausgesetzt, beliebige Merges können gültige Topic-Branch-Änderungen sein.
--not-
Kehrt die Bedeutung des Präfixes ^ (oder des Fehlens davon) für alle folgenden Revisionsspezifizierer um, bis zum nächsten
--not. Wenn es auf der Kommandozeile vor --stdin verwendet wird, werden die über stdin übergebenen Revisionen nicht davon beeinflusst. Umgekehrt werden, wenn es über die Standardeingabe übergeben wird, die auf der Kommandozeile übergebenen Revisionen nicht davon beeinflusst. --all-
Verhält sich so, als ob alle Refs in
refs/zusammen mitHEADauf der Kommandozeile als <commit> aufgelistet wären. --branches[=<pattern>]-
Verhält sich so, als ob alle Refs in
refs/headsauf der Kommandozeile als <commit> aufgelistet wären. Wenn <pattern> angegeben ist, werden die Branches auf diejenigen beschränkt, die dem angegebenen Shell-Glob-Muster entsprechen. Wenn <pattern> keine ?, * oder [ enthält, wird am Ende /* angenommen. --tags[=<pattern>]-
Verhält sich so, als ob alle Refs in
refs/tagsauf der Kommandozeile als <commit> aufgelistet wären. Wenn <pattern> angegeben ist, werden die Tags auf diejenigen beschränkt, die dem angegebenen Shell-Glob-Muster entsprechen. Wenn das Muster keine ?, * oder [ enthält, wird am Ende /* angenommen. --remotes[=<pattern>]-
Verhält sich so, als ob alle Refs in
refs/remotesauf der Kommandozeile als <commit> aufgelistet wären. Wenn <pattern> angegeben ist, werden die Remote-Tracking-Branches auf diejenigen beschränkt, die dem angegebenen Shell-Glob-Muster entsprechen. Wenn das Muster keine ?, * oder [ enthält, wird am Ende /* angenommen. --glob=<glob-pattern>-
Verhält sich so, als ob alle Refs, die dem Shell-Glob-Muster <glob-pattern> entsprechen, auf der Kommandozeile als <commit> aufgelistet wären. Wenn das Präfix refs/ fehlt, wird es automatisch hinzugefügt. Wenn das Muster keine ?, * oder [ enthält, wird am Ende /* angenommen.
--exclude=<glob-pattern>-
Schließt Refs aus, die dem Muster <glob-pattern> entsprechen und die der nächste
--all,--branches,--tags,--remotesoder--globsonst berücksichtigen würde. Wiederholungen dieser Option häufen Ausschlussmuster an bis zum nächsten--all,--branches,--tags,--remotesoder--globOption (andere Optionen oder Argumente löschen keine angesammelten Muster).Die angegebenen Muster dürfen nicht mit
refs/heads,refs/tagsoderrefs/remotesbeginnen, wenn sie auf--branches,--tagsbzw.--remotesangewendet werden, und sie müssen mitrefs/beginnen, wenn sie auf--globoder--allangewendet werden. Wenn ein nachgestelltes /* beabsichtigt ist, muss es explizit angegeben werden. -
Schließt Refs aus, die von
git-fetch,git-receive-packodergit-upload-packverborgen würden, indem die entsprechenden Konfigurationenfetch.hideRefs,receive.hideRefsoderuploadpack.hideRefszusammen mittransfer.hideRefskonsultiert werden (siehe git-config[1]). Diese Option beeinflusst die nächste Pseudo-Ref-Option--alloder--globund wird nach deren Verarbeitung gelöscht. --reflog-
Verhält sich so, als ob alle von Reflogs referenzierten Objekte auf der Kommandozeile als <commit> aufgelistet wären.
--alternate-refs-
Verhält sich so, als ob alle Objekte, die als Ref-Spitzen von alternativen Repositories referenziert werden, auf der Kommandozeile aufgelistet wären. Ein alternatives Repository ist jedes Repository, dessen Objektverzeichnis in
objects/info/alternatesangegeben ist. Die Menge der eingeschlossenen Objekte kann durchcore.alternateRefsCommandusw. modifiziert werden. Siehe git-config[1]. --single-worktree-
Standardmäßig werden alle Arbeitsbäume von den folgenden Optionen untersucht, wenn mehr als einer vorhanden ist (siehe git-worktree[1]):
--all,--reflogund--indexed-objects. Diese Option zwingt sie, nur den aktuellen Arbeitsbaum zu untersuchen. --ignore-missing-
Beim Ansehen eines ungültigen Objektnamens in der Eingabe, verhalten Sie sich so, als wäre die fehlerhafte Eingabe nicht gegeben worden.
--bisect-
Verhält sich so, als ob die fehlerhafte Bisection-Ref
refs/bisect/badaufgelistet worden wäre und als ob darauf--notund die guten Bisection-Refsrefs/bisect/good-*auf der Kommandozeile gefolgt wären. --stdin-
Zusätzlich zum Empfangen von Argumenten von der Kommandozeile werden diese auch von der Standardeingabe gelesen. Dies akzeptiert Commits und Pseudo-Optionen wie
--allund--glob=. Wenn ein Trennzeichen--gesehen wird, wird die folgende Eingabe als Pfade behandelt und zur Begrenzung des Ergebnisses verwendet. Flags wie--not, die über die Standardeingabe gelesen werden, werden nur für die auf die gleiche Weise übergebenen Argumente berücksichtigt und beeinflussen keine nachfolgenden Kommandozeilenargumente. --cherry-mark-
Ähnlich wie
--cherry-pick(siehe unten), aber gleichwertige Commits werden mit=markiert anstatt weggelassen zu werden, und ungleichwertige mit+. --cherry-pick-
Lässt jeden Commit aus, der dieselbe Änderung wie ein anderer Commit auf der "anderen Seite" einführt, wenn die Menge der Commits durch symmetrische Differenz begrenzt wird.
Wenn Sie beispielsweise zwei Branches,
AundB, haben, ist eine übliche Methode, alle Commits auf nur einer Seite davon aufzulisten,--left-right(siehe das Beispiel unten in der Beschreibung der--left-rightOption). Allerdings werden die Commits angezeigt, die von dem anderen Branch cherry-picked wurden (z. B. "3rd on b" könnte von Branch A cherry-picked worden sein). Mit dieser Option werden solche Commit-Paare von der Ausgabe ausgeschlossen. --left-only--right-only-
Listet nur Commits auf der jeweiligen Seite einer symmetrischen Differenz auf, d. h. nur diejenigen, die von
--left-rightals < bzw. > markiert würden.Zum Beispiel lässt
--cherry-pick--right-onlyA...Bjene Commits ausBaus, die inAenthalten sind oder Patch-Äquivalente zu einem Commit inAhaben. Mit anderen Worten, dies listet die+Commits ausgitcherryABauf. Genauer gesagt,--cherry-pick--right-only--no-mergesliefert die exakte Liste. --cherry-
Ein Synonym für
--right-only--cherry-mark--no-merges; nützlich, um die Ausgabe auf die Commits auf unserer Seite zu beschränken und diejenigen zu markieren, die auf der anderen Seite einer verzweigten Historie angewendet wurden, mitgitlog--cherryupstream...mybranch, ähnlich wie beigitcherryupstreammybranch. -g--walk-reflogs-
Anstatt die Commit-Abstammungskette zu durchlaufen, werden die Reflog-Einträge von den neuesten zu den älteren durchlaufen. Wenn diese Option verwendet wird, können keine Commits zum Ausschluss angegeben werden (d.h. die Notationen
^<commit>, <commit1>..<commit2> und <commit1>...<commit2> können nicht verwendet werden).Mit einem
--pretty-Format außeronelineundreference(aus offensichtlichen Gründen) führt dies dazu, dass die Ausgabe zwei zusätzliche Zeilen mit Informationen aus dem Reflog enthält. Der Reflog-Deskriptor in der Ausgabe kann alsref@{<Nth>}(wobei <Nth> der reverse-chronologische Index im Reflog ist) oder alsref@{<timestamp>}(mit dem <timestamp> für diesen Eintrag) angezeigt werden, abhängig von einigen Regeln.-
Wenn der Startpunkt als
ref@{<Nth>}angegeben ist, wird das Indexformat angezeigt. -
Wenn der Startpunkt als
ref@{now}angegeben war, wird das Zeitstempelformat angezeigt. -
Wenn keiner von beiden verwendet wurde, aber
--dateauf der Kommandozeile angegeben wurde, wird der Zeitstempel im angeforderten Format von--dateangezeigt. -
Andernfalls wird das Indexformat angezeigt.
Unter
--pretty=onelinewird die Commit-Nachricht mit diesen Informationen auf derselben Zeile vorangestellt. Diese Option kann nicht mit--reversekombiniert werden. Siehe auch git-reflog[1].Unter
--pretty=referencewerden diese Informationen überhaupt nicht angezeigt. -
--merge-
Zeigt Commits an, die sich mit widersprüchlichen Pfaden im Bereich
HEAD...<other> befassen, wobei <other> die erste existierende Pseudoref inMERGE_HEAD,CHERRY_PICK_HEAD,REVERT_HEADoderREBASE_HEADist. Funktioniert nur, wenn der Index ungelöste Einträge aufweist. Diese Option kann verwendet werden, um relevante Commits anzuzeigen, wenn Konflikte aus einem 3-Wege-Merge gelöst werden. --boundary-
Gibt ausgeschlossene Grenzmeldungen aus. Grenzmeldungen werden mit
-vorangestellt.
Verlauf vereinfachung
Manchmal interessieren Sie sich nur für Teile des Verlaufs, zum Beispiel die Commits, die einen bestimmten <path> ändern. Aber es gibt zwei Teile der Verlauf vereinfachung, ein Teil ist die Auswahl der Commits und der andere ist die Art und Weise, wie dies geschieht, da es verschiedene Strategien zur Vereinfachung des Verlaufs gibt.
Die folgenden Optionen wählen die anzuzeigenden Commits aus
Beachten Sie, dass zusätzliche Commits angezeigt werden können, um einen aussagekräftigen Verlauf zu erhalten.
Die folgenden Optionen beeinflussen die Art und Weise, wie die Vereinfachung durchgeführt wird
Standardmodus-
Vereinfacht die Historie zur einfachsten Historie, die den Endzustand des Baums erklärt. Am einfachsten, weil sie einige Nebenäste beschneidet, wenn das Endergebnis dasselbe ist (d. h. Zweige mit demselben Inhalt zusammenführt).
--show-pulls-
Schließt alle Commits vom Standardmodus ein, aber auch alle Merge-Commits, die NICHT TREESAME zum ersten Elternteil sind, aber TREESAME zu einem späteren Elternteil sind. Dieser Modus ist hilfreich, um die Merge-Commits anzuzeigen, die eine Änderung "erstmals" in einen Branch "eingeführt" haben.
--full-history-
Dasselbe wie der Standardmodus, schneidet jedoch keine Historie ab.
--dense-
Nur die ausgewählten Commits werden angezeigt, plus einige, um eine aussagekräftige Historie zu haben.
--sparse-
Alle Commits in der vereinfachten Historie werden angezeigt.
--simplify-merges-
Zusätzliche Option zu
--full-history, um einige unnötige Merges aus der resultierenden Historie zu entfernen, da keine ausgewählten Commits zu diesem Merge beitragen. --ancestry-path[=<commit>]-
Wenn ein Bereich von Commits zum Anzeigen angegeben wird (z. B. <commit1>
..<commit2> oder <commit2>^<commit1>) und ein Commit <commit> in diesem Bereich, werden nur Commits in diesem Bereich angezeigt, die Vorfahren von <commit>, Nachkommen von <commit> oder <commit> selbst sind. Wenn kein Commit angegeben ist, wird <commit1> (der ausgeschlossene Teil des Bereichs) als <commit> verwendet. Kann mehrmals übergeben werden; in diesem Fall wird ein Commit einbezogen, wenn er einer der angegebenen Commits ist oder wenn er ein Vorfahre oder Nachkomme davon ist.
Eine detailliertere Erklärung folgt.
Angenommen, Sie haben foo als <paths> angegeben. Wir nennen Commits, die foo modifizieren, !TREESAME und die übrigen TREESAME. (In einem für foo gefilterten Diff sehen sie unterschiedlich und gleich aus, bzw.)
Im Folgenden werden wir immer denselben Beispielverlauf verwenden, um die Unterschiede zwischen den Vereinfachungseinstellungen zu veranschaulichen. Wir gehen davon aus, dass Sie für eine Datei foo in diesem Commit-Graphen filtern.
.-A---M---N---O---P---Q / / / / / / I B C D E Y \ / / / / / `-------------' X
Die horizontale Historienlinie A---Q wird als erster Elternteil jedes Merges betrachtet. Die Commits sind:
-
Iist der initiale Commit, in demfoomit dem Inhaltasdfexistiert und eine Dateiquuxmit dem Inhaltquuxexistiert. Initiale Commits werden mit einem leeren Baum verglichen, daher istI!TREESAME. -
In
Aenthältfoonurfoo. -
Benthält dieselbe Änderung wieA. Sein MergeMist trivial und daher TREESAME zu allen Elternteilen. -
Cändertfoonicht, aber sein MergeNändert es zufoobar, daher ist es nicht TREESAME zu irgendeinem Elternteil. -
Dsetztfooaufbaz. Sein MergeOkombiniert die Zeichenketten vonNundDzufoobarbaz; d. h. er ist nicht TREESAME zu irgendeinem Elternteil. -
Eändertquuxzuxyzzyund sein MergePkombiniert die Zeichenketten zuquuxxyzzy.Pist TREESAME zuO, aber nicht zuE. -
Xist ein unabhängiger Root-Commit, der eine neue Dateisidehinzugefügt hat, undYhat sie modifiziert.Yist TREESAME zuX. Sein MergeQfügtsidezuPhinzu, undQist TREESAME zuP, aber nicht zuY.
rev-list durchläuft die Historie rückwärts und schließt Commits ein oder schließt sie aus, je nachdem, ob --full-history und/oder Elternteil-Rewriting (über --parents oder --children) verwendet werden. Die folgenden Einstellungen sind verfügbar.
- Standardmodus
-
Commits werden einbezogen, wenn sie NICHT TREESAME zu irgendeinem Elternteil sind (obwohl dies geändert werden kann, siehe
--sparseunten). Wenn der Commit ein Merge war und er TREESAME zu einem Elternteil war, folgen Sie nur diesem Elternteil. (Auch wenn es mehrere TREESAME-Elternteile gibt, folgen Sie nur einem davon.) Andernfalls folgen Sie allen Elternteilen.Dies führt zu
.-A---N---O / / / I---------D
Beachten Sie, wie die Regel, nur dem TREESAME-Elternteil zu folgen, falls einer verfügbar ist,
Bvollständig aus der Betrachtung entfernt hat.Cwurde überNberücksichtigt, ist aber TREESAME. Root-Commits werden mit einem leeren Baum verglichen, daher istI!TREESAME.Eltern-/Kind-Beziehungen sind nur mit
--parentssichtbar, aber das beeinflusst nicht die im Standardmodus ausgewählten Commits, daher haben wir die Elternlinien gezeigt. --full-historyohne Elternteil-Rewriting-
Dieser Modus unterscheidet sich vom Standard in einem Punkt: Folgen Sie immer allen Elternteilen eines Merges, auch wenn er TREESAME zu einem davon ist. Selbst wenn mehr als eine Seite des Merges Commits enthält, die einbezogen werden, bedeutet dies nicht, dass der Merge selbst einbezogen wird! Im Beispiel erhalten wir
I A B N D O P Q
Mwurde ausgeschlossen, weil er TREESAME zu beiden Elternteilen ist.E,CundBwurden alle durchlaufen, aber nurBwar !TREESAME, daher erscheinen die anderen nicht.Beachten Sie, dass es ohne Elternteil-Rewriting nicht wirklich möglich ist, über die Eltern-/Kind-Beziehungen zwischen den Commits zu sprechen, daher zeigen wir sie getrennt.
--full-historymit Elternteil-Rewriting-
Gewöhnliche Commits werden nur dann einbezogen, wenn sie !TREESAME sind (obwohl dies geändert werden kann, siehe
--sparseunten).Merges werden immer einbezogen. Ihre Elternliste wird jedoch neu geschrieben: Entlang jedes Elternteils werden Commits, die selbst nicht einbezogen werden, entfernt. Dies führt zu
.-A---M---N---O---P---Q / / / / / I B / D / \ / / / / `-------------'
Vergleichen Sie mit
--full-historyohne Rewriting oben. Beachten Sie, dassEentfernt wurde, weil es TREESAME ist, aber die Elternliste von P wurde so neu geschrieben, dass sieEs ElternteilIenthält. Dasselbe geschah fürCundNsowie fürX,YundQ.
Zusätzlich zu den obigen Einstellungen können Sie ändern, ob TREESAME die Einbeziehung beeinflusst.
--dense-
Durchlaufene Commits werden einbezogen, wenn sie NICHT TREESAME zu irgendeinem Elternteil sind.
--sparse-
Alle durchlaufenen Commits werden einbezogen.
Beachten Sie, dass dies ohne
--full-historyimmer noch Merges vereinfacht: Wenn einer der Elternteile TREESAME ist, folgen wir nur diesem, sodass die anderen Seiten des Merges niemals durchlaufen werden. --simplify-merges-
Bauen Sie zuerst einen Historien-Graphen auf, auf die gleiche Weise, wie
--full-historymit Elternteil-Rewriting es tut (siehe oben).Vereinfachen Sie dann jeden Commit
Czu seinem ErsatzC'in der endgültigen Historie gemäß den folgenden Regeln:-
Setzen Sie
C'aufC. -
Ersetzen Sie jeden Elternteil
PvonC'durch seine VereinfachungP'. Dabei werden Elternteile, die Vorfahren anderer Elternteile sind oder die Root-Commits sind, die TREESAME zu einem leeren Baum sind, verworfen und Duplikate entfernt, aber darauf geachtet, nie alle Elternteile zu verwerfen, zu denen wir TREESAME sind. -
Wenn nach diesem Elternteil-Rewriting
C'ein Root- oder Merge-Commit ist (null oder mehr als 1 Elternteil hat), ein Rand-Commit ist oder !TREESAME ist, bleibt er bestehen. Andernfalls wird er durch seinen einzigen Elternteil ersetzt.
Die Auswirkung hiervon wird am besten durch den Vergleich mit
--full-historymit Elternteil-Rewriting gezeigt. Das Beispiel wird zu.-A---M---N---O / / / I B D \ / / `---------'
Beachten Sie die wesentlichen Unterschiede bei
N,PundQim Vergleich zu--full-history.-
Ns Elternliste enthieltI, das entfernt wurde, da es ein Vorfahre des anderen ElternteilsMist. Dennoch bliebNbestehen, da es !TREESAME ist. -
Ps Elternliste hatte ebenfallsI, das entfernt wurde.Pwurde dann vollständig entfernt, da es einen Elternteil hatte und TREESAME war. -
Qs Elternliste hatteYvereinfacht zuX.Xwurde dann entfernt, da es ein TREESAME-Root war.Qwurde dann vollständig entfernt, da es einen Elternteil hatte und TREESAME war.
-
Es gibt einen weiteren verfügbaren Vereinfachungsmodus.
--ancestry-path[=<commit>]-
Beschränkt die angezeigten Commits auf solche, die Vorfahren von <commit> sind, oder die Nachkommen von <commit> sind, oder <commit> selbst sind.
Betrachten wir als Beispiel für die Anwendung die folgende Commit-Historie.
D---E-------F / \ \ B---C---G---H---I---J / \ A-------K---------------L--M
Ein normales D..M berechnet die Menge der Commits, die Vorfahren von
Msind, schließt aber die aus, die Vorfahren vonDsind. Dies ist nützlich, um zu sehen, was mit der Historie geschehen ist, die zuMführt, seitDexistiert, im Sinne von "was hatM, das inDnicht existierte?". Das Ergebnis in diesem Beispiel wären alle Commits, außerAundB(und natürlichDselbst).Wenn wir herausfinden wollen, welche Commits in
Mmit dem vonDeingeführten Fehler kontaminiert sind und behoben werden müssen, möchten wir vielleicht nur die Teilmenge vonD..Mbetrachten, die tatsächlich Nachkommen vonDsind, d.h.CundKausschließen. Genau das leistet die Option--ancestry-path. Angenommen auf den BereichD..M, führt dies zuE-------F \ \ G---H---I---J \ L--M
Wir können auch
--ancestry-path=Danstelle von--ancestry-pathverwenden, was im Kontext des BereichsD..Mdasselbe bedeutet, aber nur expliziter ist.Wenn wir stattdessen an einem bestimmten Thema innerhalb dieses Bereichs und allen davon betroffenen Commits interessiert sind, möchten wir vielleicht nur die Teilmenge von
D..Mbetrachten, die dieses Thema in ihrem Vorfahrenpfad enthalten. So würde zum Beispiel die Verwendung von--ancestry-path=HD..MzuE \ C---G---H---I---J \ L--M
während
--ancestry-path=KD..MzuK---------------L--M
Bevor wir eine weitere Option, --show-pulls, besprechen, müssen wir ein neues Beispiel-Historie erstellen.
Ein häufiges Problem, mit dem Benutzer konfrontiert sind, wenn sie sich eine vereinfachte Historie ansehen, ist, dass ein Commit, von dem sie wissen, dass er eine Datei irgendwie geändert hat, in der vereinfachten Historie dieser Datei nicht erscheint. Lassen Sie uns ein neues Beispiel demonstrieren und zeigen, wie Optionen wie --full-history und --simplify-merges in diesem Fall funktionieren.
.-A---M-----C--N---O---P / / \ \ \/ / / I B \ R-'`-Z' / \ / \/ / \ / /\ / `---X--' `---Y--'
Für dieses Beispiel nehmen wir an, I hat file.txt erstellt, das auf verschiedene Weise von A, B und X modifiziert wurde. Die Single-Parent-Commits C, Z und Y ändern file.txt nicht. Der Merge-Commit M wurde durch Auflösung eines Merge-Konflikts erstellt, um beide Änderungen von A und B zu integrieren, und ist daher zu keinem von beiden TREESAME. Der Merge-Commit R hingegen wurde durch Ignorieren des Inhalts von file.txt bei M erstellt und nur den Inhalt von file.txt bei X übernommen. Daher ist R TREESAME zu X, aber nicht zu M. Schließlich ist die natürliche Merge-Auflösung zur Erstellung von N, die Übernahme des Inhalts von file.txt bei R, sodass N TREESAME zu R, aber nicht zu C ist. Die Merge-Commits O und P sind TREESAME zu ihren ersten Elternteilen, aber nicht zu ihren zweiten Elternteilen, Z bzw. Y.
Bei Verwendung des Standardmodus haben sowohl N als auch R einen TREESAME-Elternteil, daher werden diese Kanten durchlaufen und die anderen ignoriert. Der resultierende Historien-Graph ist
I---X
Bei Verwendung von --full-history durchläuft Git jede Kante. Dies wird die Commits A und B sowie den Merge M aufdecken, wird aber auch die Merge-Commits O und P enthüllen. Mit Elternteil-Rewriting ist der resultierende Graph
.-A---M--------N---O---P / / \ \ \/ / / I B \ R-'`--' / \ / \/ / \ / /\ / `---X--' `------'
Hier tragen die Merge-Commits O und P zusätzlichen Lärm, da sie tatsächlich keine Änderung an file.txt vorgenommen haben. Sie haben nur ein Thema gemerged, das auf einer älteren Version von file.txt basierte. Dies ist ein häufiges Problem in Repositories, die einen Workflow verwenden, bei dem viele Mitwirkende parallel arbeiten und ihre Topic-Branches entlang eines einzelnen Stammes zusammenführen: Viele nicht zusammenhängende Merges erscheinen in den Ergebnissen von --full-history.
Bei Verwendung der Option --simplify-merges verschwinden die Commits O und P aus den Ergebnissen. Dies liegt daran, dass die neu geschriebenen zweiten Elternteile von O und P von ihren ersten Elternteilen erreichbar sind. Diese Kanten werden entfernt und dann sehen die Commits wie Single-Parent-Commits aus, die TREESAME zu ihrem Elternteil sind. Dies geschieht auch mit dem Commit N, was zu einer Historienansicht wie folgt führt:
.-A---M--. / / \ I B R \ / / \ / / `---X--'
In dieser Ansicht sehen wir alle wichtigen Single-Parent-Änderungen von A, B und X. Wir sehen auch den sorgfältig aufgelösten Merge M und den nicht so sorgfältig aufgelösten Merge R. Dies ist normalerweise ausreichend, um zu bestimmen, warum die Commits A und B in der Standardansicht aus der Historie "verschwunden" sind. Es gibt jedoch einige Probleme mit diesem Ansatz.
Das erste Problem ist die Leistung. Im Gegensatz zu jeder früheren Option erfordert die Option --simplify-merges das Durchlaufen der gesamten Commit-Historie, bevor ein einzelnes Ergebnis zurückgegeben wird. Dies kann die Option für sehr große Repositories schwierig zu verwenden machen.
Das zweite Problem ist die Prüfung. Wenn viele Mitwirkende am selben Repository arbeiten, ist es wichtig, welche Merge-Commits eine Änderung in einen wichtigen Branch eingeführt haben. Der problematische Merge R oben ist wahrscheinlich nicht der Merge-Commit, der verwendet wurde, um in einen wichtigen Branch zu mergen. Stattdessen wurde der Merge N verwendet, um R und X in den wichtigen Branch zu mergen. Dieser Commit kann Informationen darüber enthalten, warum die Änderung X die Änderungen von A und B in seiner Commit-Nachricht überschrieben hat.
--show-pulls-
Zusätzlich zu den im Standardverlauf angezeigten Commits werden alle Merge-Commits angezeigt, die nicht TREESAME zu ihrem ersten Elternteil sind, aber TREESAME zu einem späteren Elternteil sind.
Wenn ein Merge-Commit von
--show-pullseinbezogen wird, wird der Merge so behandelt, als ob er die Änderung von einem anderen Branch "gezogen" hätte. Wenn--show-pullsauf dieses Beispiel angewendet wird (und keine anderen Optionen), ist der resultierende GraphI---X---R---N
Hier werden die Merge-Commits
RundNeinbezogen, da sie die CommitsXbzw.Rin den Basis-Branch "gezogen" haben. Diese Merges sind der Grund dafür, dass die CommitsAundBnicht im Standardverlauf erscheinen.Wenn
--show-pullsmit--simplify-mergeskombiniert wird, enthält der Graph alle notwendigen Informationen..-A---M--. N / / \ / I B R \ / / \ / / `---X--'
Beachten Sie, dass, da
MvonRerreichbar ist, die Kante vonNnachMvereinfacht wurde.Nerscheint jedoch immer noch in der Historie als wichtiger Commit, da er die ÄnderungRin den Haupt-Branch "gezogen" hat.
Die Option --simplify-by-decoration ermöglicht es Ihnen, nur die Gesamtübersicht über die Topologie der Historie anzuzeigen, indem Commits weggelassen werden, die nicht von Tags referenziert werden. Commits werden als !TREESAME markiert (mit anderen Worten, nach den oben beschriebenen Historienvereinfachungsregeln beibehalten), wenn (1) sie von Tags referenziert werden oder (2) sie den Inhalt der auf der Befehlszeile angegebenen Pfade ändern. Alle anderen Commits werden als TREESAME markiert (können also vereinfacht wegfallen).
AUTOREN ABILDEN
Siehe gitmailmap[5].
Beachten Sie, dass, wenn git shortlog außerhalb eines Repositorys ausgeführt wird (um Log-Inhalte von der Standardeingabe zu verarbeiten), es im aktuellen Verzeichnis nach einer Datei .mailmap sucht.
GIT
Teil der git[1] Suite