Fügt automatisch geänderte und gelöschte Dateien zum Staging-Bereich hinzu, neue Dateien, die Git noch nicht bekannt sind, sind davon nicht betroffen.

Verwendet die interaktive Patch-Auswahlschnittstelle, um auszuwählen, welche Änderungen committet werden sollen. Siehe git-add[1] für Details.

Generiert Diffs mit <n> Zeilen Kontext. Standard ist diff.context oder 3, wenn die Konfigurationsoption nicht gesetzt ist.

Zeigt den Kontext zwischen Diff-Hunks bis zur angegebenen Anzahl von <n> Zeilen an und fasst so nahe beieinander liegende Hunks zusammen. Standard ist diff.interHunkContext oder 0, wenn die Konfigurationsoption nicht gesetzt ist.

Nimmt ein vorhandenes <commit> Objekt und verwendet die Log-Nachricht und die Autoreninformationen (einschließlich des Zeitstempels) bei der Erstellung des Commits wieder.

Ähnlich wie -C, aber mit -c wird der Editor aufgerufen, damit der Benutzer die Commit-Nachricht weiter bearbeiten kann.

Erstellt einen neuen Commit, der <commit> "fixup"-t, wenn er mit git rebase --autosquash angewendet wird. Ein einfacher --fixup=<commit> erstellt einen "fixup!"-Commit, der den Inhalt von <commit> ändert, aber dessen Log-Nachricht unverändert lässt. --fixup=amend:<commit> ist ähnlich, erstellt aber einen "amend!"-Commit, der auch die Log-Nachricht von <commit> durch die Log-Nachricht des "amend!"-Commits ersetzt. --fixup=reword:<commit> erstellt einen "amend!"-Commit, der die Log-Nachricht von <commit> durch seine eigene Log-Nachricht ersetzt, aber keine Änderungen am Inhalt von <commit> vornimmt.

Erstellt eine Commit-Nachricht zur Verwendung mit git rebase --autosquash. Der Titel der Commit-Nachricht wird aus dem angegebenen Commit mit dem Präfix "squash! " übernommen. Kann mit zusätzlichen Commit-Nachrichten-Optionen (-m/-c/-C/-F) verwendet werden. Siehe git-rebase[1] für Details.

Wenn mit den Optionen -C/-c/--amend verwendet oder nach einem widersprüchlichen Cherry-Pick committet wird, wird erklärt, dass die Autorenschaft des resultierenden Commits nun dem Committer gehört. Dies erneuert auch den Autorenschafts-Zeitstempel.

Bei einem Dry-Run wird die Ausgabe im Kurzformat ausgegeben. Siehe git-status[1] für Details. Impliziert --dry-run.

Zeigt den Branch und die Tracking-Informationen auch im Kurzformat an.

Bei einem Dry-Run wird die Ausgabe in einem für Maschinen lesbaren Format ausgegeben. Siehe git-status[1] für Details. Impliziert --dry-run.

Bei einem Dry-Run wird die Ausgabe im Langformat ausgegeben. Impliziert --dry-run.

Beim Anzeigen der Ausgabe von short oder porcelain wird der Dateiname wörtlich ausgegeben und die Einträge mit NUL statt LF beendet. Wenn kein Format angegeben ist, wird das Ausgabeformat --porcelain impliziert. Ohne die Option -z werden Dateinamen mit "ungewöhnlichen" Zeichen wie in der Konfigurationsvariable core.quotePath erklärt (siehe git-config[1]) zitiert.

Nimmt die Commit-Nachricht aus <datei>. Verwenden Sie -, um die Nachricht von der Standardeingabe zu lesen.

Überschreibt den Commit-Autor. Geben Sie einen expliziten Autor im Standardformat A U Thor <autor@example.com> an. Andernfalls wird angenommen, dass <autor> ein Muster ist und zum Suchen nach einem bestehenden Commit dieses Autors verwendet wird (d.h. git rev-list --all -i --author=<autor>); der Commit-Autor wird dann vom ersten gefundenen solchen Commit kopiert.

Überschreibt das Datum des Autors, das im Commit verwendet wird.

Verwendet <nachricht> als Commit-Nachricht. Wenn mehrere Optionen -m angegeben werden, werden ihre Werte als separate Absätze verkettet.

Beim Bearbeiten der Commit-Nachricht wird der Editor mit dem Inhalt aus <datei> gestartet. Die Konfigurationsvariable commit.template wird oft verwendet, um diese Option implizit an den Befehl zu übergeben. Dieser Mechanismus kann von Projekten verwendet werden, die Teilnehmer mit Hinweisen leiten möchten, was in der Nachricht in welcher Reihenfolge geschrieben werden soll. Wenn der Benutzer den Editor beendet, ohne die Nachricht zu bearbeiten, wird der Commit abgebrochen. Dies hat keine Auswirkung, wenn die Nachricht auf andere Weise angegeben wird, z.B. mit den Optionen -m oder -F.

Fügt einen Signed-off-by-Trailer vom Committer am Ende der Commit-Log-Nachricht hinzu. Die Bedeutung eines Sign-offs hängt vom Projekt ab, an das Sie committen. Es kann beispielsweise bestätigen, dass der Committer die Rechte hat, die Arbeit unter der Lizenz des Projekts einzureichen, oder einer bestimmten Beitragsstellervereinbarung zustimmt, wie z. B. einem Developer Certificate of Origin. (Siehe https://developercertificate.org für das von den Linux-Kernel- und Git-Projekten verwendete.) Konsultieren Sie die Dokumentation oder die Führung des Projekts, zu dem Sie beitragen, um zu verstehen, wie die Sign-offs in diesem Projekt verwendet werden.

Gibt ein (<token>, <wert>)-Paar an, das als Trailer angewendet werden soll. (z.B. git commit --trailer "Signed-off-by:C O Mitter \ <committer@example.com>" --trailer "Helped-by:C O Mitter \ <committer@example.com>" fügt den Signed-off-by-Trailer und den Helped-by-Trailer zur Commit-Nachricht hinzu.) Die Konfigurationsvariablen trailer.* (siehe git-interpret-trailers[1]) können verwendet werden, um zu definieren, ob ein duplizierter Trailer weggelassen wird, wo in der Reihe der Trailer jeder Trailer erscheinen würde und andere Details.

Umgeht die pre-commit und commit-msg Hooks. Siehe auch githooks[5].

Normalerweise ist das Aufzeichnen eines Commits, der denselben Baum wie sein einziger Eltern-Commit hat, ein Fehler, und der Befehl verhindert, dass Sie einen solchen Commit machen. Diese Option umgeht die Sicherheitsvorkehrung und ist hauptsächlich für die Verwendung durch Skripte von Fremd-SCM-Schnittstellen bestimmt.

Erstellt einen Commit mit einer leeren Commit-Nachricht, ohne dabei niedrigstufige Befehle wie git-commit-tree[1] zu verwenden. Wie --allow-empty ist dieser Befehl hauptsächlich für die Verwendung durch Skripte von Fremd-SCM-Schnittstellen bestimmt.

Bestimmt, wie die übermittelte Commit-Nachricht vor dem Committen bereinigt werden soll. Der <modus> kann strip, whitespace, verbatim, scissors oder default sein.

Lässt den Benutzer die Nachricht, die aus <datei> mit -F <datei>, von der Befehlszeile mit -m <nachricht> und aus <commit> mit -C <commit> übernommen wurde, weiter bearbeiten.

Verwendet 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.

Ersetzt die Spitze des aktuellen Branches durch einen neuen Commit. Der aufgezeichnete Baum wird wie üblich vorbereitet (einschließlich der Auswirkungen der Optionen -i und -o sowie expliziter Pfadangaben) und die Nachricht des ursprünglichen Commits wird als Ausgangspunkt verwendet, anstatt einer leeren Nachricht, wenn keine andere Nachricht über Befehlszeilenoptionen wie -m, -F, -c usw. angegeben wird. Der neue Commit hat dieselben Eltern und denselben Autor wie der aktuelle (die Option --reset-author kann dies überschreiben).

	$ git reset --soft HEAD^
	$ ... do something else to come up with the right tree ...
	$ git commit -c ORIG_HEAD

Umgeht den post-rewrite Hook.

Bevor ein Commit aus den bisher vorbereiteten Inhalten erstellt wird, werden auch die Inhalte der auf der Befehlszeile angegebenen Pfade vorbereitet. Dies ist normalerweise nicht das, was Sie wollen, es sei denn, Sie beenden einen konfliktträchtigen Merge.

Erstellt einen Commit, indem die aktualisierten Arbeitsverzeichnis-Inhalte der auf der Befehlszeile angegebenen Pfade übernommen werden, wobei alle für andere Pfade vorbereiteten Inhalte ignoriert werden. Dies ist der Standardmodus von git commit, wenn Pfade auf der Befehlszeile angegeben werden, in diesem Fall kann diese Option weggelassen werden. Wenn diese Option zusammen mit --amend angegeben wird, müssen keine Pfade angegeben werden, was verwendet werden kann, um den letzten Commit zu ändern, ohne bereits vorbereitete Änderungen zu committen. Wenn zusammen mit --allow-empty verwendet, werden auch keine Pfade benötigt und ein leerer Commit wird erstellt.

Gibt die Pfadangaben in <datei> anstelle von Befehlszeilenargumenten weiter. Wenn <datei> genau - ist, wird die Standardeingabe verwendet. Pfadangaben werden durch LF oder CR/LF getrennt. Pfadangaben können wie für die Konfigurationsvariable core.quotePath beschrieben (siehe git-config[1]) zitiert werden. Siehe auch --pathspec-file-nul und global --literal-pathspecs.

Nur relevant mit --pathspec-from-file. Pfadangaben werden durch ein NUL-Zeichen getrennt und alle anderen Zeichen werden wörtlich genommen (einschließlich Zeilenumbrüchen und Anführungszeichen).

Zeigt nicht verfolgte Dateien an.

Zeigt am Ende der Commit-Nachrichtenvorlage eine einheitliche Differenz zwischen dem HEAD-Commit und dem, was committet werden würde, an, um dem Benutzer zu helfen, den Commit zu beschreiben, indem er ihn an die vorgenommenen Änderungen erinnert. Beachten Sie, dass diese Diff-Ausgabe nicht mit #-Zeilenpräfixen versehen ist. Diese Diff ist nicht Teil der Commit-Nachricht. Siehe die Konfigurationsvariable commit.verbose in git-config[1].

Unterdrückt die Commit-Zusammenfassungsnachricht.

Erstellt keinen Commit, sondern zeigt eine Liste der zu committenden Pfade, Pfade mit lokalen Änderungen, die nicht committet werden, und nicht verfolgte Pfade an.

Schließt die Ausgabe von git-status[1] in die Commit-Nachrichtenvorlage ein, wenn ein Editor zur Vorbereitung der Commit-Nachricht verwendet wird. Standardmäßig aktiviert, kann aber die Konfigurationsvariable commit.status überschreiben.

Schließt die Ausgabe von git-status[1] nicht in die Commit-Nachrichtenvorlage ein, wenn ein Editor zur Vorbereitung der Standard-Commit-Nachricht verwendet wird.

GPG-signiert Commits. Die Angabe von <key-id> ist optional und wird standardmäßig auf die Identität des Committenten gesetzt; wenn sie angegeben wird, muss sie ohne Leerzeichen an die Option angehängt werden. --no-gpg-sign ist nützlich, um sowohl die Konfigurationsvariable commit.gpgSign als auch frühere --gpg-sign-Angaben zu überschreiben.

Interpretiere keine weiteren Argumente mehr als Optionen.

Wenn <pfadangabe> auf der Befehlszeile angegeben wird, werden die Inhalte der Dateien, die mit der Pfadangabe übereinstimmen, committet, ohne die Änderungen aufzuzeichnen, die bereits zum Index hinzugefügt wurden. Die Inhalte dieser Dateien werden auch für den nächsten Commit über das hinaus, was zuvor vorbereitet wurde, vorbereitet.

Es ist <unix-timestamp> <time-zone-offset>, wobei <unix-timestamp> die Anzahl der Sekunden seit der UNIX-Epoche ist. <time-zone-offset> ist ein positiver oder negativer Offset von UTC. Zum Beispiel ist CET (das 1 Stunde vor UTC liegt) +0100.

Das Standard-Datumsformat wie in RFC 2822 beschrieben, zum Beispiel Thu, 07 Apr 2005 22:13:13 +0200.

Zeit und Datum gemäß dem ISO 8601-Standard, zum Beispiel 2005-04-07T22:13:13. Der Parser akzeptiert auch ein Leerzeichen anstelle des T-Zeichens. Bruchteile von Sekunden werden ignoriert, zum Beispiel wird 2005-04-07T22:13:13.019 als 2005-04-07T22:13:13 behandelt.

Diese Einstellung überschreibt den Standardwert der Option --cleanup in git commit. Das Ändern des Standardwerts kann nützlich sein, wenn Sie Zeilen, die mit dem Kommentarzeichen (core.commentChar, Standard #) beginnen, immer in Ihrer Log-Nachricht behalten möchten. In diesem Fall würden Sie git config commit.cleanup whitespace ausführen (beachten Sie, dass Sie die Hilfzeilen, die mit dem Kommentarzeichen beginnen, in der Commit-Log-Vorlage selbst entfernen müssen, wenn Sie dies tun).

Ein boolescher Wert, der angibt, ob alle Commits GPG-signiert werden sollen. Die Verwendung dieser Option bei Operationen wie Rebase kann dazu führen, dass eine große Anzahl von Commits signiert wird. Es kann praktisch sein, einen Agenten zu verwenden, um die Eingabe Ihrer GPG-Passphrase mehrmals zu vermeiden.

Ein boolescher Wert, um die Einbeziehung von Statusinformationen in die Commit-Nachrichten-Vorlage bei der Verwendung eines Editors zur Vorbereitung der Commit-Nachricht zu aktivieren/deaktivieren. Standardmäßig ist dieser Wert auf true gesetzt.

Gibt den Pfadnamen einer Datei an, die als Vorlage für neue Commit-Nachrichten verwendet werden soll.

Ein boolescher Wert oder eine Ganzzahl, um den Grad der Ausführlichkeit bei git commit anzugeben.

Diese Datei enthält die Commit-Nachricht eines gerade stattfindenden Commits. Wenn git commit aufgrund eines Fehlers abbricht, bevor ein Commit erstellt wurde, ist jede vom Benutzer bereitgestellte Commit-Nachricht (z. B. in einer Editiersitzung) in dieser Datei verfügbar, wird aber bei der nächsten Ausführung von git commit überschrieben.