Optionen kommen zuerst, dann die Argumente. Ein Unterbefehl kann gestrichelte Optionen (die eigene Argumente haben können, z. B. "--max-parents 2") und Argumente nehmen. Sie SOLLTEN gestrichelte Optionen zuerst und dann Argumente angeben. Einige Befehle können gestrichelte Optionen akzeptieren, nachdem Sie bereits Nicht-Options-Argumente angegeben haben (was den Befehl mehrdeutig machen kann), aber Sie sollten sich nicht darauf verlassen (da wir schließlich einen Weg finden könnten, diese Mehrdeutigkeiten zu beheben, indem wir die Regel "Optionen dann Argumente" durchsetzen).

Revisionen kommen zuerst, dann Pfade. Z. B. in git diff v1.0 v2.0 arch/x86 include/asm-x86 sind v1.0 und v2.0 Revisionen und arch/x86 und include/asm-x86 sind Pfade.

Wenn ein Argument missverstanden werden kann, entweder als Revision oder als Pfad, können sie durch die Platzierung von -- dazwischen eindeutig gemacht werden. Z. B. git diff -- HEAD bedeutet "Ich habe eine Datei namens HEAD in meinem Arbeitsverzeichnis. Bitte zeigen Sie die Unterschiede zwischen der Version, die ich im Index vorbereitet habe, und dem, was ich in meinem Arbeitsverzeichnis für diese Datei habe", nicht "zeigen Sie den Unterschied zwischen dem HEAD-Commit und dem Arbeitsverzeichnis als Ganzes". Sie können git diff HEAD -- sagen, um letzteres anzufordern.

Ohne die eindeutig machende -- trifft Git eine vernünftige Vermutung, gibt aber eine Fehlermeldung aus und bittet Sie, sie eindeutig zu machen, wenn sie mehrdeutig ist. Z. B. wenn Sie eine Datei namens HEAD in Ihrem Arbeitsverzeichnis haben, ist git diff HEAD mehrdeutig und Sie müssen entweder git diff HEAD -- oder git diff -- HEAD sagen, um sie eindeutig zu machen.

Da -- Revisionen und Pfade in einigen Befehlen eindeutig macht, kann es für diese Befehle nicht verwendet werden, um Optionen und Revisionen zu trennen. Sie können --end-of-options dafür verwenden (es funktioniert auch für Befehle, die nicht zwischen Revisionen und Pfaden unterscheiden, in diesem Fall ist es einfach ein Alias für --).

Viele Befehle erlauben Wildcards in Pfaden, aber Sie müssen sie davor schützen, von der Shell "globbed" zu werden. Diese beiden bedeuten unterschiedliche Dinge

$ git restore *.c
$ git restore \*.c

So wie das Dateisystem . (Punkt) das aktuelle Verzeichnis bezeichnet, ist die Verwendung eines . als Repository-Name in Git (ein Punkt-Repository) ein relativer Pfad und bedeutet Ihr aktuelles Repository.

Kurze Optionen auf getrennte Wörter aufteilen (bevorzugen Sie git foo -a -b gegenüber git foo -ab, letzteres funktioniert möglicherweise nicht einmal).

Wenn eine Kommandozeilenoption ein Argument nimmt, verwenden Sie die "gesteckte" Form. Das heißt, schreiben Sie git foo -oArg anstelle von git foo -o Arg für kurze Optionen und git foo --long-opt=Arg anstelle von git foo --long-opt Arg für lange Optionen. Eine Option, die ein optionales Optionsargument nimmt, muss in der "gesteckten" Form geschrieben werden.

Trotz des obigen Vorschlags, wenn Arg ein Pfad relativ zum Home-Verzeichnis eines Benutzers ist, z. B. ~/directory/file oder ~u/d/f, möchten Sie vielleicht die getrennte Form verwenden, z. B. git foo --file ~/mine, nicht git foo --file=~/mine. Die Shell erweitert ~/ in der ersteren zu Ihrem Home-Verzeichnis, aber die meisten Shells behalten die Tilde in letzterem. Einige unserer Befehle wissen, wie sie den Optionswert mit Tilde erweitern können, auch wenn er in der gesteckten Form gegeben wird, aber nicht alle von ihnen tun das.

Wenn Sie einem Befehl einen Revisionsparameter übergeben, stellen Sie sicher, dass der Parameter nicht mit einem Dateinamen im Arbeitsverzeichnis verwechselt werden kann. Z. B. schreiben Sie nicht git log -1 HEAD, sondern git log -1 HEAD --; erstere funktioniert nicht, wenn Sie zufällig eine Datei namens HEAD im Arbeitsverzeichnis haben.

Viele Befehle erlauben eine lange Option --option, die nur bis zu ihrem eindeutigen Präfix abgekürzt werden kann (z. B. wenn es keine andere Option gibt, deren Name mit opt beginnt, können Sie möglicherweise --opt schreiben, um das Flag --option aufzurufen), aber Sie sollten sie in Ihren Skripten vollständig ausschreiben; spätere Versionen von Git können eine neue Option einführen, deren Name dasselbe Präfix teilt, z. B. --optimize, um ein kurzes Präfix, das einst eindeutig war, nicht mehr eindeutig zu machen.

Die Option --cached wird verwendet, um einen Befehl, der normalerweise auf Dateien im Arbeitsverzeichnis arbeitet, anzuweisen, **nur** mit dem Index zu arbeiten. Zum Beispiel sucht git grep, wenn es ohne Commit verwendet wird, um aus welchem Commit gesucht werden soll, normalerweise in Dateien im Arbeitsverzeichnis. Mit der Option --cached sucht es jedoch im Index nach Zeichenketten.

Die Option --index wird verwendet, um einen Befehl, der normalerweise auf Dateien im Arbeitsverzeichnis arbeitet, anzuweisen, **auch** den Index zu beeinflussen. Zum Beispiel führt git stash apply normalerweise Änderungen zusammen, die in einem Stash-Eintrag aufgezeichnet sind, in das Arbeitsverzeichnis. Mit der Option --index führt es jedoch auch Änderungen in den Index zusammen.

--staged ist genau wie --cached, was verwendet wird, um einen Befehl anzuweisen, nur mit dem Index und nicht mit dem Arbeitsverzeichnis zu arbeiten.

--worktree ist das Gegenteil, um einen Befehl anzuweisen, nur mit dem Arbeitsverzeichnis und nicht mit dem Index zu arbeiten.

Die beiden Optionen können zusammen angegeben werden, um einen Befehl anzuweisen, sowohl mit dem Index als auch mit dem Arbeitsverzeichnis zu arbeiten.