EnglischFranzösischSpanisch

Ad


OnWorks-Favicon

git-blame – Online in der Cloud

Führen Sie git-blame beim kostenlosen Hosting-Anbieter OnWorks über Ubuntu Online, Fedora Online, den Windows-Online-Emulator oder den MAC OS-Online-Emulator aus

Dies ist der Befehl git-blame, der beim kostenlosen Hosting-Anbieter OnWorks mit einer unserer zahlreichen kostenlosen Online-Workstations wie Ubuntu Online, Fedora Online, dem Windows-Online-Emulator oder dem MAC OS-Online-Emulator ausgeführt werden kann

PROGRAMM:

NAME/FUNKTION


git-blame – Zeigt an, welche Revision und welcher Autor jede Zeile einer Datei zuletzt geändert hat

ZUSAMMENFASSUNG


git Schuld [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--inkremental]
[-L ] [-S ] [-M] [-C] [-C] [-C] [--since= ]
[--abbrev= ] [ | --Inhalt | --umkehren ] [--]

BESCHREIBUNG


Versieht jede Zeile in der angegebenen Datei mit Informationen aus der letzten Revision
habe die Zeile geändert. Beginnen Sie optional mit der Kommentierung ab der angegebenen Revision.

Wenn -L einmal oder mehrmals angegeben wird, beschränkt es die Annotation auf die angeforderten Zeilen.

Der Ursprung der Zeilen wird bei der Umbenennung ganzer Dateien automatisch verfolgt (derzeit dort).
gibt es keine Möglichkeit, die Umbenennungsfolge auszuschalten). Um Zeilen zu folgen, die von einer Datei nach verschoben wurden
eine andere, oder um Zeilen zu folgen, die aus einer anderen Datei usw. kopiert und eingefügt wurden, finden Sie unter
-C- und -M-Optionen.

Der Bericht gibt keine Auskunft über gelöschte oder ersetzte Zeilen; Du
Sie müssen ein Werkzeug verwenden, z git diff oder die „Spitzhacke“-Schnittstelle, die im kurz erwähnt wird
folgenden Absatz.

Neben der Unterstützung von Dateianmerkungen unterstützt Git auch die Suche im Entwicklungsverlauf
für den Fall, dass bei einer Änderung ein Codeausschnitt aufgetreten ist. Dadurch ist es möglich, bei Eingabe eines Codes nachzuverfolgen
Snippet wurde einer Datei hinzugefügt, zwischen Dateien verschoben oder kopiert und schließlich gelöscht oder
ersetzt. Es funktioniert durch die Suche nach einer Textzeichenfolge im Diff. Ein kleines Beispiel dafür
Spitzhacke-Schnittstelle, die nach „blame_usage“ sucht:

$ git log --pretty=oneline -S'blame_usage'
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output

OPTIONAL


-b
Leeres SHA-1 für Boundary-Commits anzeigen. Dies kann auch über die . gesteuert werden
Konfigurationsoption "blank.blankboundary".

--Wurzel
Behandeln Sie Root-Commits nicht als Grenzen. Dies kann auch über die
Konfigurationsoption "blow.showRoot".

--Statistiken anzeigen
Fügen Sie zusätzliche Statistiken am Ende der Schuldzuweisungsausgabe hinzu.

-L , , -L:
Kommentieren Sie nur den angegebenen Zeilenbereich. Kann mehrfach angegeben werden. Überlappend
Bereiche sind erlaubt.

und sind optional. „-L “ oder „-L “ erstreckt sich von zu
Ende der Datei. „-L, ” erstreckt sich vom Dateianfang bis .

und kann eine dieser Formen annehmen:

· Nummer

Wenn oder eine Zahl ist, gibt sie eine absolute Zeilennummer an (Zeilenanzahl
ab 1).

· /regex/

Dieses Formular verwendet die erste Zeile, die der angegebenen POSIX-Regex entspricht. Wenn ist ein
regex, es wird ab dem Ende des vorherigen -L-Bereichs gesucht, falls vorhanden, andernfalls
ab Dateianfang. Wenn „^/regex/“ ist, wird vom Anfang an gesucht
Datei. Wenn eine Regex ist, wird ab der Zeile gesucht, die durch angegeben wird .

· +Offset oder -Offset

Dies gilt nur für und gibt eine Anzahl von Zeilen vor oder nach an
die von gegebene Zeile .

Wenn ": ” wird anstelle von angegeben und , es ist ein regulärer Ausdruck
das bezeichnet den Bereich ab der ersten funcname-Zeile, die übereinstimmt , bis zum
nächste Funkname-Zeile. “: ” sucht am Ende des vorherigen -L-Bereichs, wenn
any, andernfalls ab Dateianfang. „^: “ sucht vom Anfang der Datei.

-l
Lange Drehzahl anzeigen (Standard: aus).

-t
Rohen Zeitstempel anzeigen (Standard: aus).

-S
Verwenden Sie Revisionen aus der Revs-Datei, anstatt sie aufzurufen git-rev-Liste(1).

--umkehren
Gehen Sie die Geschichte vorwärts statt rückwärts. Anstatt die Revision anzuzeigen, in der a
Zeile erschienen ist, zeigt dies die letzte Revision an, in der eine Zeile existiert hat. Dafür braucht man
eine Reihe von Überarbeitungen wie START..END, wobei der Pfad der Schuld in START existiert.

-p, --porzellan
Zeigen Sie in einem Format an, das für den maschinellen Verbrauch ausgelegt ist.

--line-porzellan
Zeigen Sie das Porzellanformat an, geben Sie jedoch Commit-Informationen für jede Zeile aus, nicht nur für die
wenn ein Commit zum ersten Mal referenziert wird. Impliziert --Porzellan.

--inkrementell
Zeigen Sie das Ergebnis inkrementell in einem Format an, das für den Maschinenverbrauch ausgelegt ist.

--encoding=
Gibt die Codierung an, die verwendet wird, um Autorennamen und Commit-Zusammenfassungen auszugeben. Einstellen auf
keine macht die Ausgabe von unkonvertierten Daten verantwortlich. Weitere Informationen finden Sie in der Diskussion
über die Kodierung im Git-Log(1) Handbuchseite.

--Inhalt
Wann nicht angegeben ist, kommentiert der Befehl die Änderungen rückwärts von
die Arbeitsbaumkopie. Dieses Flag bewirkt, dass der Befehl so tut, als ob der Arbeitsbaum kopiert wäre
hat den Inhalt der benannten Datei (angeben - um den Befehl aus der Datei zu lesen
Standardeingabe).

--Datum
Gibt das Format an, das für die Ausgabe von Datumsangaben verwendet wird. Wenn --date nicht angegeben wird, wird der Wert des
Die Konfigurationsvariable "tabla.date" wird verwendet. Wenn die Konfigurationsvariable "tabla.date" ebenfalls nicht gesetzt ist,
das iso-format wird verwendet. Informationen zu unterstützten Werten finden Sie in der Diskussion zur Option --date
at Git-Log(1).

-M| |
Erkennen Sie verschobene oder kopierte Zeilen in einer Datei. Wenn ein Commit einen Block von verschiebt oder kopiert
Zeilen (zB hat die Originaldatei A und dann B, und der Commit ändert es in B und
dann A), die traditionelle Schuld Algorithmus bemerkt nur die Hälfte der Bewegung und
gibt normalerweise die Schuld für die Zeilen, die nach oben verschoben wurden (zB B), dem Elternteil und weist die Schuld zu
zu den Zeilen, die nach unten verschoben wurden (zB A) zum Kind-Commit. Mit dieser Option können beide
Gruppen von Linien werden dem Elternteil angelastet, indem zusätzliche Inspektionsdurchgänge durchgeführt werden.

ist optional, aber es ist die untere Grenze für die Anzahl der alphanumerischen Zeichen
die Git als Verschieben/Kopieren innerhalb einer Datei erkennen muss, damit diese Zeilen zugeordnet werden können
mit dem Eltern-Commit. Der Standardwert ist 20.

-C| |
Erkennt zusätzlich zu -M Zeilen, die aus anderen Dateien verschoben oder kopiert wurden, die in geändert wurden
das gleiche Commit. Dies ist nützlich, wenn Sie Ihr Programm reorganisieren und Code verschieben
über Dateien hinweg. Wenn diese Option zweimal angegeben wird, sucht der Befehl zusätzlich nach
Kopien von anderen Dateien in dem Commit, der die Datei erstellt. Wenn diese Option gegeben ist
dreimal sucht der Befehl in jedem Commit zusätzlich nach Kopien aus anderen Dateien.

ist optional, aber es ist die untere Grenze für die Anzahl der alphanumerischen Zeichen
die Git als Verschieben/Kopieren zwischen Dateien erkennen muss, damit es diese Zeilen zuordnen kann
mit dem Eltern-Commit. Und der Standardwert ist 40. Bei mehr als einem -C
Optionen gegeben, die Argument des letzten -C wird wirksam.

-h
Hilfemeldung anzeigen.

-c
Verwenden Sie den gleichen Ausgabemodus wie git-annotate(1) (Standard: aus).

--score-debug
Fügen Sie Debugging-Informationen zum Verschieben von Zeilen zwischen Dateien hinzu (siehe -C).
und Zeilen, die innerhalb einer Datei verschoben werden (siehe -M). Die erste aufgeführte Zahl ist die Punktzahl. Das ist
die Anzahl der alphanumerischen Zeichen, bei denen erkannt wurde, dass sie zwischen oder innerhalb verschoben wurden
Dateien. Dieser muss über einem bestimmten Schwellenwert liegen git Schuld um diese Zeilen zu betrachten
Code verschoben worden sein.

-f, --show-name
Zeigt den Dateinamen im ursprünglichen Commit an. Standardmäßig wird der Dateiname angezeigt, falls vorhanden
Jede Zeile, die aufgrund der Umbenennungserkennung aus einer Datei mit einem anderen Namen stammt.

-n, --show-nummer
Zeigt die Zeilennummer im ursprünglichen Commit an (Standard: aus).

-s
Unterdrücken Sie den Autorennamen und den Zeitstempel aus der Ausgabe.

-e, --show-email
Zeigt die E-Mail-Adresse des Autors anstelle des Namens des Autors an (Standardeinstellung: Aus). Das kann auch sein
gesteuert über die Konfigurationsoption „blame.showEmail“.

-w
Ignorieren Sie Leerzeichen, wenn Sie die Version des Elternteils und des Kindes vergleichen, um herauszufinden, wo
Die Zeilen kamen von.

--abbrev=
Anstatt die standardmäßigen 7+1 hexadezimalen Ziffern als abgekürzten Objektnamen zu verwenden,
verwenden +1 Ziffern. Beachten Sie, dass eine Spalte als Einfügemarke verwendet wird, um die Grenzfestschreibung zu markieren.

PORZELLAN FORMAT


In diesem Format wird jede Zeile nach einem Header ausgegeben; Der Header hat mindestens das
erste Zeile mit:

· 40-Byte-SHA-1 des Commits, dem die Zeile zugeordnet ist;

· die Zeilennummer der Zeile in der Originaldatei;

· die Zeilennummer der Zeile in der endgültigen Datei;

· in einer Zeile, die eine Gruppe von Zeilen mit einem anderen Commit als dem vorherigen beginnt,
die Anzahl der Zeilen in dieser Gruppe. In den folgenden Zeilen fehlt dieses Feld.

Auf diese Kopfzeile folgen mindestens einmal für jeden Commit die folgenden Informationen:

· der Name des Autors („Autor“), die E-Mail-Adresse („Autor-Mail“), die Uhrzeit („Autor-Zeit“) und die Zeitzone
(„author-tz“); Ähnliches gilt für Committer.

· der Dateiname im Commit, dem die Zeile zugeordnet ist.

· die erste Zeile der Commit-Log-Nachricht („Zusammenfassung“).

Der Inhalt der eigentlichen Zeile wird nach der obigen Kopfzeile mit vorangestelltem TAB ausgegeben. Das
soll das spätere Hinzufügen weiterer Header-Elemente ermöglichen.

Das Porzellanformat unterdrückt im Allgemeinen Commit-Informationen, die bereits gesehen wurden.
Beispielsweise werden zwei Zeilen, die demselben Commit zugeordnet sind, beide angezeigt, aber die
Details zu diesem Commit werden nur einmal angezeigt. Dies ist effizienter, kann jedoch erforderlich sein
mehr Status vom Leser behalten werden. Für die vollständige Ausgabe kann die Option --line-porcelain verwendet werden
Commit-Informationen für jede Zeile, was eine einfachere (aber weniger effiziente) Verwendung ermöglicht, wie zum Beispiel:

# Zählen Sie die Anzahl der Zeilen, die jedem Autor zugeordnet sind
Git Blame --line-porcelain Datei |
sed -n 's/^author //p' |
sortieren | uniq -c | sortieren -rn

SPEZIFIKATION BEREICHE


Im Gegensatz zu git Schuld und git kommentieren in älteren Git-Versionen der Umfang der Annotation
kann sowohl auf Zeilenbereiche als auch auf Revisionsbereiche beschränkt werden. Die Option -L, die begrenzt
Anmerkung zu einem Zeilenbereich, kann mehrfach angegeben werden.

Wenn Sie den Ursprung der Zeilen 40–60 für die Datei foo ermitteln möchten, können Sie Folgendes verwenden
die Option -L etwa so (sie bedeuten dasselbe – beide verlangen 21 Zeilen, beginnend bei Zeile
40):

Git Blame -L 40,60 foo
Git-Schuld -L 40,+21 foo

Sie können den Zeilenbereich auch mit einem regulären Ausdruck angeben:

git Blame -L '/^sub hallo {/,/^}$/' foo

Dadurch wird die Annotation auf den Hauptteil der Hello-Unterroutine beschränkt.

Wenn Sie nicht an Änderungen interessiert sind, die älter als Version v2.6.18 sind, oder an Änderungen, die älter als 3 sind
Wochen können Sie Revisionsbereichsspezifizierer ähnlich wie verwenden git Drehzahlliste:

Git Blame v2.6.18.. -- foo
Git Blame --since=3.weeks -- foo

Wenn Revisionsbereichsspezifizierer verwendet werden, um die Anmerkung einzuschränken, werden Zeilen angezeigt, bei denen dies nicht der Fall ist
seit der Bereichsgrenze geändert (entweder das Commit v2.6.18 oder das letzte Commit).
ist im obigen Beispiel älter als 3 Wochen) werden für diesen Bereichsgrenzen-Commit verantwortlich gemacht.

Eine besonders nützliche Methode besteht darin, festzustellen, ob eine hinzugefügte Datei Zeilen enthält, die durch Kopieren und Einfügen erstellt wurden
aus vorhandenen Dateien. Manchmal deutet dies darauf hin, dass der Entwickler schlampig war und dies auch tat
Den Code nicht richtig umgestalten. Sie können zuerst den Commit finden, der die Datei eingeführt hat
mit:

git log --diff-filter=A --pretty=short --foo

und kommentieren Sie dann die Änderung zwischen dem Commit und seinen Eltern mit commit^! Notation:

Git Blame -C -C -f $commit^! -- foo

INKREMENTAL AUSGABE


Wenn der Befehl mit der Option --incremental aufgerufen wird, gibt er das Ergebnis aus, während es erstellt wird. Der
Die Ausgabe spricht im Allgemeinen zuerst über Zeilen, die von neueren Commits berührt werden (d. h. die
Zeilen werden in der falschen Reihenfolge mit Anmerkungen versehen) und sollen von interaktiven Betrachtern verwendet werden.

Das Ausgabeformat ähnelt dem Porcelain-Format, enthält jedoch nicht das tatsächliche
Zeilen aus der Datei, die mit Anmerkungen versehen wird.

1. Jeder Blame-Eintrag beginnt immer mit einer Zeile aus:

<40-Byte-Hex-Sha1>

Zeilennummern zählen ab 1.

2. Wenn ein Commit zum ersten Mal im Stream angezeigt wird, enthält es verschiedene andere Informationen
darüber wird mit einem Ein-Wort-Tag am Anfang jeder Zeile ausgedruckt, die das beschreibt
zusätzliche Commit-Informationen (Autor, E-Mail, Committer, Datum, Zusammenfassung usw.).

3. Im Gegensatz zum Porcelain-Format werden die Dateinameninformationen immer angegeben und beendet
der Eintritt:

"Dateinamen"

und daher ist das Parsen für einen zeilen- und wortorientierten Parser wirklich recht einfach
(was für die meisten Skriptsprachen ganz natürlich sein sollte).

Note
Für Leute, die Parsing betreiben: Um es robuster zu machen, ignorieren Sie einfach alle Zeilen dazwischen
der erste und der letzte (" „ und „Dateiname“-Zeilen), wo Sie es nicht erkennen
die Tag-Wörter (oder kümmern Sie sich um dieses bestimmte Wort) am Anfang des
„Erweiterte Informationen“-Zeilen. Auf diese Weise können, falls es jemals zusätzliche Informationen gibt (z
B. die Commit-Codierung oder der erweiterte Commit-Kommentar), wird es einem Betrachter, der die Schuld trägt, egal sein.

KORR AUTOREN


Wenn die Datei .mailmap auf der obersten Ebene des Repositorys oder an der angegebenen Stelle vorhanden ist
durch die Konfigurationsoptionen mailmap.file oder mailmap.blob wird es verwendet, um Autor und
Committer-Namen und E-Mail-Adressen zu kanonischen echten Namen und E-Mail-Adressen.

In der einfachen Form besteht jede Zeile in der Datei aus dem kanonischen Realnamen eines
Autor, Leerzeichen und eine im Commit verwendete E-Mail-Adresse (eingeschlossen von < und >) zur Karte
zum Namen. Zum Beispiel:

Eigenname[E-Mail geschützt] >

Die komplexeren Formen sind:

<[E-Mail geschützt] >[E-Mail geschützt] >

was es mailmap ermöglicht, nur den E-Mail-Teil eines Commits zu ersetzen, und:

Eigenname[E-Mail geschützt] >[E-Mail geschützt] >

was es mailmap ermöglicht, sowohl den Namen als auch die E-Mail eines Commits zu ersetzen, das mit dem übereinstimmt
angegebene Commit-E-Mail-Adresse und:

Eigenname[E-Mail geschützt] > Commit-Name[E-Mail geschützt] >

was es mailmap ermöglicht, sowohl den Namen als auch die E-Mail eines Commits zu ersetzen, das mit beiden übereinstimmt
angegebenen Commit-Namen und E-Mail-Adresse.

Beispiel 1: Ihr Verlauf enthält Commits von zwei Autoren, Jane und Joe, deren Namen erscheinen
im Repository in mehreren Formen:

Joe Entwickler[E-Mail geschützt] >
Joe R. Entwickler[E-Mail geschützt] >
Jane Doe[E-Mail geschützt] >
Jane Doe
Jane D.

Angenommen, Joe möchte, dass sein zweiter Vorname verwendet wird, und Jane bevorzugt ihren Familiennamen
vollständig ausgeschrieben. Eine richtige .mailmap-Datei würde so aussehen:

Jane Doe
Joe R. Entwickler[E-Mail geschützt] >

Beachten Sie, dass kein Eintrag erforderlich ist für , weil der richtige Name von
der Autor hat schon recht.

Beispiel 2: Ihr Repository enthält Commits der folgenden Autoren:

nick1[E-Mail geschützt] >
nick2[E-Mail geschützt] >
nick2[E-Mail geschützt] >
Weihnachtsmann[E-Mail geschützt] >
klaus[E-Mail geschützt] >
CTO[E-Mail geschützt] >

Dann möchten Sie vielleicht eine .mailmap-Datei, die wie folgt aussieht:

<[E-Mail geschützt] >[E-Mail geschützt] >
Einige Kerl[E-Mail geschützt] > nick1[E-Mail geschützt] >
Anderer Autor[E-Mail geschützt] > nick2[E-Mail geschützt] >
Anderer Autor[E-Mail geschützt] >[E-Mail geschützt] >
Weihnachtsmann[E-Mail geschützt] >[E-Mail geschützt] >

Haschisch verwenden # für Kommentare, die entweder in einer eigenen Zeile oder nach der E-Mail-Adresse stehen.

Verwenden Sie git-blame online über die Dienste von onworks.net


Kostenlose Server & Workstations

Laden Sie Windows- und Linux-Apps herunter

Linux-Befehle

Ad