git-commit – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

git-commit – Änderungen am Repository aufzeichnen

ZUSAMMENFASSUNG

git verpflichten [-a | --interactive | --patch] [-s] [-v] [-u ] [--amend]
[--dry-run] [(-c | -C | --fixup | --squash) ]
[-F | -M ] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author= ]
[--date= ] [--cleanup= ] [--[kein Status]
[-i | -o] [-S[ ]] [--] [ ...]

BESCHREIBUNG

Speichert den aktuellen Inhalt des Index in einem neuen Commit zusammen mit einer Protokollnachricht von
Benutzer, der die Änderungen beschreibt.

Der hinzuzufügende Inhalt kann auf verschiedene Arten angegeben werden:

1. durch die Verwendung git hinzufügen um inkrementell Änderungen zum Index hinzuzufügen, bevor Sie die verwenden verpflichten
Befehl (Hinweis: Auch geänderte Dateien müssen „hinzugefügt“ werden);

2. durch die Verwendung git rm um Dateien aus dem Arbeitsbaum und dem Index zu entfernen, noch einmal vorher
Verwendung der verpflichten Befehl;

3. durch Auflisten von Dateien als Argumente für die verpflichten Befehl, in diesem Fall wird das Commit ausgeführt
Ignorieren Sie im Index bereitgestellte Änderungen und zeichnen Sie stattdessen den aktuellen Inhalt auf
aufgelistete Dateien (die Git bereits bekannt sein müssen);

4. indem Sie den Schalter -a mit dem verwenden verpflichten Befehl zum automatischen „Hinzufügen“ von Änderungen von allen
Bekannte Dateien (also alle Dateien, die bereits im Index aufgeführt sind) werden automatisch aufgerufen
„rm“-Dateien im Index, die aus dem Arbeitsbaum entfernt wurden, und führen Sie sie dann aus
das eigentliche Commit;

5. durch Verwendung der Schalter --interactive oder --patch mit dem verpflichten Befehl, einen zu entscheiden
durch eins, welche Dateien oder Hunks Teil des Commits sein sollen, bevor das finalisiert wird
Betrieb. Siehe den Abschnitt „Interaktiver Modus“ von git-add(1) um zu lernen, wie man bedient
diese Modi.

Die Option --dry-run kann verwendet werden, um eine Zusammenfassung dessen zu erhalten, was in einem der enthaltenen Elemente enthalten ist
oben für das nächste Commit, indem Sie denselben Parametersatz (Optionen und Pfade) angeben.

Wenn Sie einen Commit durchführen und unmittelbar danach einen Fehler feststellen, können Sie ihn beheben
es mit git zurückstellen.

OPTIONAL

-a, --alle
Weisen Sie den Befehl an, Dateien, die geändert und gelöscht wurden, automatisch bereitzustellen, aber
Neue Dateien, von denen Sie Git nichts mitgeteilt haben, sind nicht betroffen.

-p, --patch
Verwenden Sie die interaktive Patch-Auswahloberfläche, um auszuwählen, welche Änderungen übernommen werden sollen. Sehen
git-add(1) für Details.

-C , --reuse-message=
Nehmen Sie ein vorhandenes Commit-Objekt und verwenden Sie die Protokollnachricht und die Urheberschaft erneut
Informationen (einschließlich des Zeitstempels) beim Erstellen des Commits.

-C , --reedit-message=
Like -C, aber mit -c Der Editor wird aufgerufen, sodass der Benutzer den weiter bearbeiten kann
Commit-Nachricht.

--fixup=
Erstellen Sie eine Commit-Nachricht zur Verwendung mit rebase --autosquash. Die Commit-Nachricht wird
sei die Betreffzeile des angegebenen Commits mit dem Präfix „fixup!“. Sehen Git-
zurückweisen(1) für Details.

--squash=
Erstellen Sie eine Commit-Nachricht zur Verwendung mit rebase --autosquash. Die Commit-Nachricht
Die Betreffzeile wird aus dem angegebenen Commit mit dem Präfix „squash!“ übernommen. Kann sein
Wird mit zusätzlichen Commit-Nachrichtenoptionen (-m/-c/-C/-F) verwendet. Sehen Git-Rebase(1) für
Details.

--reset-author
Bei Verwendung mit den Optionen -C/-c/--amend oder beim Festschreiben nach einem Konflikt
Cherry-Pick, erklärt, dass die Urheberschaft des resultierenden Commits nun dem gehört
Committer. Dadurch wird auch der Zeitstempel des Autors erneuert.

--kurz
Geben Sie bei einem Probelauf die Ausgabe im Kurzformat an. Sehen Git-Status(1) für
Einzelheiten. Impliziert --dry-run.

--Zweig
Zeigen Sie die Filial- und Tracking-Informationen auch im Kurzformat an.

--Porzellan
Geben Sie bei einem Probelauf die Ausgabe in einem für Porzellan geeigneten Format an. Sehen Git-Status(1)
für Details. Impliziert --dry-run.

--lang
Geben Sie bei einem Probelauf die Ausgabe im Langformat an. Impliziert --dry-run.

-z, --null
Wenn Sie eine Kurz- oder Porzellanstatusausgabe anzeigen, schließen Sie die Einträge in der Statusausgabe ab
mit NUL, statt LF. Wenn kein Format angegeben ist, wird das Ausgabeformat --porcelain impliziert.

-F , --file=
Nehmen Sie die Commit-Nachricht aus der angegebenen Datei. Verwenden - um die Nachricht von zu lesen
Standardeingabe.

--author=
Überschreiben Sie den Commit-Autor. Geben Sie einen expliziten Autor an, indem Sie den Standard-AU-Thor verwenden
<[E-Mail geschützt] > formatieren. Ansonsten wird als Muster angenommen und verwendet
um nach einem vorhandenen Commit dieses Autors zu suchen (z. B. rev-list --all -i
--author= ); Der Commit-Autor wird dann vom ersten gefundenen Commit kopiert.

--date=
Überschreiben Sie das im Commit verwendete Autorendatum.

-m , --message=
Nutzen Sie das Gegebene als Commit-Nachricht. Wenn mehrere -m-Optionen angegeben sind, sind deren
Werte werden als separate Absätze verkettet.

-T , --template=
Starten Sie beim Bearbeiten der Commit-Nachricht den Editor mit dem Inhalt der angegebenen Datei.
Für diese Option wird häufig die Konfigurationsvariable commit.template verwendet
implizit zum Befehl. Dieser Mechanismus kann von Projekten genutzt werden, die eine Anleitung geben möchten
Geben Sie den Teilnehmern einige Hinweise, was in welcher Reihenfolge in die Nachricht geschrieben werden soll. Wenn die
Wenn der Benutzer den Editor verlässt, ohne die Nachricht zu bearbeiten, wird der Commit abgebrochen. Das hat nein
Wirkung, wenn eine Nachricht auf andere Weise übermittelt wird, z. B. mit den Optionen -m oder -F.

-s, --signoff
Fügen Sie am Ende der Commit-Protokollnachricht die Zeile „Signed-off-by“ des Committers hinzu. Der
Die Bedeutung einer Freigabe hängt vom Projekt ab, in der Regel wird jedoch der Committer zertifiziert
hat das Recht, dieses Werk unter derselben Lizenz einzureichen und stimmt einem Entwickler zu
Ursprungszeugnis (siehe http://developercertificate.org/ für weitere Informationen).

-n, --no-verify
Diese Option umgeht die Hooks pre-commit und commit-msg. Siehe auch Githooks(5).

--allow-empty
Normalerweise ist die Aufzeichnung eines Commits, der genau denselben Baum hat wie sein einziger übergeordneter Commit, ein
Fehler, und der Befehl verhindert, dass Sie einen solchen Commit durchführen. Diese Option wird umgangen
die Sicherheit und ist hauptsächlich für die Verwendung durch fremde SCM-Schnittstellenskripte vorgesehen.

--allow-empty-message
Wie --allow-empty ist dieser Befehl hauptsächlich für die Verwendung durch fremde SCM-Schnittstellenskripte vorgesehen.
Es ermöglicht Ihnen, ein Commit mit einer leeren Commit-Nachricht zu erstellen, ohne Installationsarbeiten durchzuführen
Befehle wie Git-Commit-Baum(1).

--cleanup=
Diese Option bestimmt, wie die bereitgestellte Commit-Nachricht zuvor bereinigt werden soll
begehen. Der kann „strip“, „whitespace“, „verbatim“, „scisser“ oder „default“ sein.

abstreifen
Entfernen Sie führende und nachgestellte Leerzeilen, nachgestellte Leerzeichen, Kommentare usw
Reduziert aufeinanderfolgende leere Zeilen.

Leerzeichen
Das Gleiche wie der Strip, außer dass #commentary nicht entfernt wird.

wörtlich
Ändern Sie die Nachricht überhaupt nicht.

Schere
Dasselbe wie Leerzeichen, außer dass alles ab (und einschließlich) der Zeile „#“
------------------------ >8 ---------- " wird abgeschnitten, wenn die Nachricht
bearbeitet werden soll. „#“ kann mit core.commentChar angepasst werden.

Standard
Identisch mit Strip, wenn die Nachricht bearbeitet werden soll. Ansonsten Leerzeichen.

Die Standardeinstellung kann durch geändert werden commit.cleanup Konfigurationsvariable (siehe Git-
Config(1)).

-e, --edit
Die Nachricht wird mit -F aus der Datei, mit -m aus der Befehlszeile und mit dem Commit-Objekt übernommen
-C wird normalerweise unverändert als Commit-Log-Nachricht verwendet. Mit dieser Option kommen Sie weiter
Bearbeiten Sie die Nachricht aus diesen Quellen.

--keine Bearbeitung
Verwenden Sie die ausgewählte Commit-Nachricht, ohne einen Editor zu starten. Zum Beispiel Git Commit
--amend --no-edit ändert einen Commit, ohne seine Commit-Nachricht zu ändern.

--ändern
Ersetzen Sie die Spitze des aktuellen Zweigs, indem Sie einen neuen Commit erstellen. Der aufgezeichnete Baum ist
wie üblich vorbereitet (einschließlich der Wirkung der Optionen -i und -o und explizit).
pathspec) und die Nachricht vom ursprünglichen Commit wird als Ausgangspunkt verwendet,
anstelle einer leeren Nachricht, wenn in der Befehlszeile keine andere Nachricht angegeben wird
über Optionen wie -m, -F, -c usw. Der neue Commit hat die gleichen Eltern und den gleichen Autor wie
die aktuelle (die Option --reset-author kann dies widerrufen).

Es ist ein grobes Äquivalent für:

$ git reset --soft HEAD^
$ ... etwas anderes tun, um den richtigen Baum zu finden ...
$ git commit -c ORIG_HEAD

kann aber zum Ändern eines Merge-Commits verwendet werden.

Sie sollten die Auswirkungen des Umschreibens des Verlaufs verstehen, wenn Sie einen Commit ändern
wurde bereits veröffentlicht. (Siehe den Abschnitt „WIEDERHERSTELLUNG VON DER UPSTREAM-REBASE“ in Git-
zurückweisen(1).)

--no-post-rewrite
Umgehen Sie den Post-Rewrite-Hook.

-Ich füge bei
Bevor Sie die bisher bereitgestellten Inhalte festschreiben, stellen Sie die Inhalte der Pfade bereit
wird auch in der Befehlszeile angegeben. Dies ist normalerweise nicht das, was Sie wollen, es sei denn, Sie sind es
Abschluss einer konfliktreichen Zusammenführung.

-o, --nur
Führen Sie einen Commit durch, indem Sie die aktualisierten Arbeitsbauminhalte der angegebenen Pfade übernehmen
über die Befehlszeile, wobei alle Inhalte ignoriert werden, die für andere Pfade bereitgestellt wurden.
Dies ist der Standardbetriebsmodus von git verpflichten wenn irgendwelche Pfade auf der angegeben sind
Befehlszeile, in diesem Fall kann diese Option weggelassen werden. Wenn diese Option angegeben ist
Zusammen mit --ändern, dann müssen keine Pfade angegeben werden, die zur Änderung genutzt werden können
das letzte Commit ohne Commit von Änderungen, die bereits bereitgestellt wurden.

-u[ ], --untracked-files[= ]
Nicht verfolgte Dateien anzeigen.

Der Modusparameter ist optional (standardmäßig alle) und wird verwendet, um die Handhabung festzulegen
von nicht verfolgten Dateien; Wenn -u nicht verwendet wird, ist die Standardeinstellung normal, also untracked anzeigen
Dateien und Verzeichnisse.

Die möglichen Optionen sind:

· nicht - Keine nicht verfolgten Dateien anzeigen

· normal - Zeigt nicht verfolgte Dateien und Verzeichnisse an

· alle - Zeigt auch einzelne Dateien in nicht verfolgten Verzeichnissen an.

Der Standardwert kann mithilfe der Konfiguration status.showUntrackedFiles geändert werden
Variable dokumentiert in git-config(1).

-v, --verbose
Zeigt den einheitlichen Unterschied zwischen dem HEAD-Commit und dem, was unten festgeschrieben werden würde
die Commit-Nachrichtenvorlage, um dem Benutzer zu helfen, den Commit zu beschreiben, indem er daran erinnert, was
Änderungen, die das Commit hat. Beachten Sie, dass dieser Diff-Ausgabe die Zeilen nicht vorangestellt sind
mit #. Dieser Unterschied wird nicht Teil der Commit-Nachricht sein.

Wenn es zweimal angegeben wird, wird zusätzlich der einheitliche Unterschied zwischen dem angezeigt, was festgeschrieben werden würde
und die Arbeitsbaumdateien, also die nicht bereitgestellten Änderungen an verfolgten Dateien.

-q, --leise
Commit-Zusammenfassungsnachricht unterdrücken.

--Probelauf
Erstellen Sie kein Commit, sondern zeigen Sie eine Liste der Pfade an, die festgeschrieben werden sollen, Pfade mit
lokale Änderungen, die nicht festgeschrieben werden, und Pfade, die nicht verfolgt werden.

--Status
Fügen Sie die Ausgabe von ein Git-Status(1) in der Commit-Nachrichtenvorlage bei Verwendung von
Editor zur Vorbereitung der Commit-Nachricht. Standardmäßig ist „Ein“ aktiviert, kann aber zum Überschreiben verwendet werden
Konfigurationsvariable commit.status.

--kein Status
Beziehen Sie nicht die Ausgabe von ein Git-Status(1) in der Commit-Nachrichtenvorlage bei Verwendung
einen Editor zum Vorbereiten der Standard-Commit-Nachricht.

-S[ ], --gpg-Zeichen[= ]
GPG-Zeichen-Commits. Das Argument keyid ist optional und wird standardmäßig auf den Committer gesetzt
Identität; falls angegeben, muss es ohne Leerzeichen an die Option angehängt werden.

--kein-gpg-zeichen
Countermand-commit.gpgSign-Konfigurationsvariable, die so eingestellt ist, dass sie jedes einzelne erzwingt
verpflichten sich zu unterschreiben.

--
Interpretieren Sie keine weiteren Argumente als Optionen.

...
Wenn Dateien in der Befehlszeile angegeben werden, schreibt der Befehl den Inhalt der Datei fest
benannte Dateien, ohne die bereits bereitgestellten Änderungen aufzuzeichnen. Der Inhalt dieser Dateien
werden zusätzlich zu dem, was bereits bereitgestellt wurde, auch für den nächsten Commit bereitgestellt.

DATUM FORMATEN

Die Umgebungsvariablen GIT_AUTHOR_DATE, GIT_COMMITTER_DATE und die Option --date
unterstützt die folgenden Datumsformate:

Git-internes Format
es ist , wo ist die Zahl der
Sekunden seit der UNIX-Epoche. ist ein positiver oder negativer Offset
von UTC. Zum Beispiel ist MEZ (das ist 2 Stunden vor UTC) +0200.

RFC 2822
Das Standard-E-Mail-Format wie in RFC 2822 beschrieben, zum Beispiel Do, 07 Apr 2005
22:13:13 +0200.

ISO 8601
Uhrzeit und Datum gemäß ISO 8601-Standard, zum Beispiel 2005-04-07T22:13:13. Die
Parser akzeptiert auch ein Leerzeichen anstelle des T-Zeichens.

Note
Außerdem wird der Datumsteil in den folgenden Formaten akzeptiert: JJJJ.MM.TT,
MM/TT/JJJJ und TT.MM.JJJJ.

Beispiele:

Wenn Sie Ihre eigene Arbeit aufzeichnen, werden die Inhalte der geänderten Dateien in Ihrem Arbeitsbaum angezeigt
vorübergehend in einem Staging-Bereich namens „Index“ gespeichert git hinzufügen. Eine Datei kann sein
wurde, nur im Index, aber nicht im Arbeitsbaum, auf den Index des letzten Commits zurückgesetzt
mit git reset HEAD -- , was effektiv umgekehrt wird git hinzufügen und verhindert die Änderungen
zu dieser Datei von der Teilnahme am nächsten Commit. Nach dem Aufbau des Staates zu sein
Inkrementell mit diesen Befehlen festgeschrieben, git commit (ohne Pfadnamenparameter)
dient der Aufzeichnung des bisher Inszenierten. Dies ist die einfachste Form des Befehls.
Ein Beispiel:

$ bearbeiten hallo.c
$ git rm goodbye.c
$ git hello.c hinzufügen
$ git commit

Anstatt Dateien nach jeder einzelnen Änderung bereitzustellen, können Sie Git Commit anweisen, dies zu bemerken
die Änderungen an den Dateien, deren Inhalt in Ihrem Arbeitsbaum verfolgt wird, und zwar
entsprechende git add und git rm für Sie. Das heißt, dieses Beispiel macht dasselbe wie das
früheres Beispiel, wenn es keine weitere Änderung in Ihrem Arbeitsbaum gibt:

$ bearbeiten hallo.c
$ rm auf Wiedersehen.c
$ git commit -a

Der Befehl git commit -a schaut sich zunächst Ihren Arbeitsbaum an und stellt fest, dass Sie Änderungen vorgenommen haben
hello.c und goodbye.c entfernt und führt die erforderlichen git add- und git rm-Vorgänge für Sie aus.

Nachdem Sie Änderungen an vielen Dateien bereitgestellt haben, können Sie die Reihenfolge ändern, in der die Änderungen aufgezeichnet werden.
indem Sie dem Git-Commit Pfadnamen geben. Wenn Pfadnamen angegeben werden, führt der Befehl einen Commit durch
das nur die an den benannten Pfaden vorgenommenen Änderungen aufzeichnet:

$ bearbeiten hallo.c hallo.h
$ git add hello.c hallo.h
$ Makefile bearbeiten
$ git commit Makefile

Dadurch wird ein Commit durchgeführt, der die Änderung im Makefile aufzeichnet. Die geplanten Änderungen
hello.c und hello.h sind im resultierenden Commit nicht enthalten. Ihre Änderungen sind jedoch
nicht verloren – sie werden immer noch inszeniert und lediglich zurückgehalten. Nach der obigen Sequenz, wenn Sie
machen:

$ git commit

Dieser zweite Commit würde die Änderungen an hello.c und hello.h wie erwartet aufzeichnen.

Nach einer Zusammenführung (initiiert von git fusionieren or git ziehen) stoppt aufgrund von Konflikten sauber
Zusammengeführte Pfade sind bereits bereitgestellt, um für Sie festgeschrieben zu werden, und Pfade mit Konflikten bereits
im nicht zusammengeführten Zustand belassen. Sie müssten zunächst prüfen, mit welchen Pfaden ein Konflikt besteht git
Status und nachdem Sie sie manuell in Ihrem Arbeitsbaum korrigiert haben, würden Sie das Ergebnis als bereitstellen
üblich mit git hinzufügen:

$ Git-Status | grep nicht zusammengeführt
nicht zusammengeführt: hallo.c
$ bearbeiten hallo.c
$ git hello.c hinzufügen

Nachdem Konflikte gelöst und das Ergebnis bereitgestellt wurden, hörte git ls-files -u mit der Erwähnung auf
Der konfliktreiche Weg. Wenn Sie fertig sind, führen Sie git commit aus, um die Zusammenführung endgültig aufzuzeichnen:

$ git commit

Wie beim Aufzeichnen Ihrer eigenen Änderungen können Sie die Option -a verwenden, um die Eingabe zu sparen. Eins
Der Unterschied besteht darin, dass Sie während einer Zusammenführungsauflösung kein Git-Commit mit Pfadnamen zu verwenden können
Ändern Sie die Reihenfolge, in der die Änderungen festgeschrieben werden, da die Zusammenführung als aufgezeichnet werden sollte
Einzel-Commit. Tatsächlich verweigert der Befehl die Ausführung, wenn Pfadnamen angegeben werden (siehe jedoch -i
Möglichkeit).

DISKUSSION

Obwohl dies nicht erforderlich ist, empfiehlt es sich, die Commit-Nachricht mit einem einzigen Kurztext zu beginnen
(weniger als 50 Zeichen) Zeile, die die Änderung zusammenfasst, gefolgt von einer Leerzeile und dann a
ausführlichere Beschreibung. Der Text bis zur ersten Leerzeile in einer Commit-Nachricht lautet
wird als Commit-Titel behandelt und dieser Titel wird in Git verwendet. Zum Beispiel, Git-
Format-Patch(1) wandelt einen Commit in eine E-Mail um und verwendet den Titel in der Betreffzeile und
der Rest des Commits im Körper.

Git ist bis zu einem gewissen Grad zeichenkodierungsunabhängig.

· Der Inhalt der Blob-Objekte sind nicht interpretierte Bytefolgen. Es gibt kein
Kodierung der Übersetzung auf der Kernebene.

· Pfadnamen sind in UTF-8-Normalisierungsform C kodiert. Dies gilt für Baumobjekte,
die Indexdatei, Referenznamen sowie Pfadnamen in Befehlszeilenargumenten,
Umgebungsvariablen und Konfigurationsdateien (.git/config (siehe git-config(1)), ignorieren(5)
gittributes(5) und gitmodule(5)).

Beachten Sie, dass Git auf der Kernebene Pfadnamen einfach als Sequenzen von Nicht-NUL behandelt
Bytes gibt es keine Konvertierungen der Pfadnamencodierung (außer auf Mac und Windows).
Daher funktioniert die Verwendung von Nicht-ASCII-Pfadnamen meistens sogar auf Plattformen und Dateien
Systeme, die ältere erweiterte ASCII-Codierungen verwenden. Repositorys, die am . erstellt wurden
solche Systeme funktionieren auf UTF-8-basierten Systemen (zB Linux, Mac, Windows) nicht richtig
und umgekehrt. Darüber hinaus gehen viele Git-basierte Tools einfach davon aus, dass Pfadnamen
UTF-8 und zeigt andere Codierungen nicht richtig an.

· Commit-Protokollnachrichten werden normalerweise in UTF-8 kodiert, aber auch andere erweiterte ASCII-Kodierungen
werden ebenfalls unterstützt. Dazu gehören ISO-8859-x, CP125x und viele andere, aber nicht
UTF-16/32, EBCDIC und CJK Multi-Byte-Kodierungen (GBK, Shift-JIS, Big5, EUC-x, CP9xx
etc.).

Obwohl wir empfehlen, dass die Commit-Log-Meldungen in UTF-8 kodiert sind, sind sowohl der Kern als auch der
Git Porcelain wurde entwickelt, um UTF-8 für Projekte nicht zu erzwingen. Wenn alle Teilnehmer von a
bestimmte Projekte finden es bequemer, Legacy-Kodierungen zu verwenden, Git verbietet es nicht
es. Es gibt jedoch ein paar Dinge zu beachten.

1. git verpflichten und git Commit-Baum gibt eine Warnung aus, wenn die ihm übergebene Commit-Log-Meldung
sieht nicht wie eine gültige UTF-8-Zeichenfolge aus, es sei denn, Sie sagen ausdrücklich, dass Ihr Projekt a . verwendet
Legacy-Codierung. Der Weg, dies zu sagen, ist i18n.commitencoding in .git/config
Datei, wie folgt:

[i18n]
Commitencoding = ISO-8859-1

Commit-Objekte, die mit der obigen Einstellung erstellt wurden, zeichnen den Wert von i18n.commitencoding auf
in seinem Codierungsheader. Dies ist, um anderen Leuten zu helfen, die sie später ansehen. Mangel an
Dieser Header impliziert, dass die Commit-Log-Meldung in UTF-8 kodiert ist.

2. git Log, git erklären, git Schuld und Freunde schauen sich den Codierungsheader eines Commits an
-Objekt und versuchen Sie, die Protokollnachricht in UTF-8 umzucodieren, sofern nicht anders angegeben. Du
kann die gewünschte Ausgabecodierung mit i18n.logoutputencoding in .git/config festlegen
Datei, wie folgt:

[i18n]
Protokollausgabecodierung = ISO-8859-1

Wenn Sie diese Konfigurationsvariable nicht haben, ist der Wert von i18n.commitencoding
stattdessen verwendet.

Beachten Sie, dass wir uns bewusst dafür entschieden haben, die Commit-Log-Meldung nicht neu zu codieren, wenn ein Commit
gemacht, um UTF-8 auf der Ebene des Commit-Objekts zu erzwingen, da eine Umcodierung in UTF-8 nicht möglich ist
zwangsläufig ein reversibler Vorgang.

UND CONFIGURATION VARIABLEN

Der zum Bearbeiten der Commit-Log-Nachricht verwendete Editor wird aus GIT_EDITOR ausgewählt
Umgebungsvariable, die core.editor-Konfigurationsvariable, die VISUAL-Umgebung
Variable oder die Umgebungsvariable EDITOR (in dieser Reihenfolge). Sehen git-var(1) für Details.

HAKEN

Mit diesem Befehl können Commit-msg-, Prepare-Commit-msg-, Pre-Commit- und Post-Commit-Hooks ausgeführt werden.
See Githooks(5) für weitere Informationen.

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