$ git add Documentation/\*.txt-
git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] - [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--sparse] - [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize] - [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]] - [--] [<pathspec>…]-
Dieser Befehl aktualisiert den Index mit dem aktuellen Inhalt im Arbeitsbereich, um den Inhalt für den nächsten Commit vorzubereiten. Typischerweise wird der gesamte aktuelle Inhalt in existierenden Pfaden hinzugefügt. Mit einigen Optionen kann der Befehl so verwendet werden, dass nur bestimmte Änderungen hinzugefügt werden, oder bestimmte Pfade entfernt werden, die in der Arbeitskopie nicht mehr existieren.
-Der „Index“ enthält eine Momentaufnahme (snapshot) des Inhalts des Arbeitsbereichs und es ist genau diese Momentaufnahme, die beim nächsten Commit übernommen wird. Nachdem man Änderungen am Arbeitsbereich vorgenommen hat und bevor man den Commit-Befehl ausführt, muss man deshalb den Befehl add verwenden, um alle neuen oder geänderten Dateien zum Index hinzuzufügen.
Diese Anweisung kann vor einem Commit mehrfach ausgeführt werden. Es wird lediglich der Inhalt der angegebenen Datei(en) zum Ausführungszeitpunkt hinzugefügt. Soll eine spätere Änderung einer dieser Dateien in den nächsten Commit aufgenommen werden, so muss git add erneut aufgerufen werden.
Der Befehl git status kann verwendet werden, um zusammenzufassen, welche Dateien geändert und die für den nächsten Commit bereitgestellt wurden.
Der Befehl git add wird standardmäßig keine ignorierten Dateien hinzufügen. Wenn ignorierte Dateien (.gitignore) explizit in der Befehlszeile angegeben wurden, wird git add fehlschlagen und eine Liste aller ignorierten Dateien ausgeben. Ignorierte Dateien die über eine rekursive Verzeichnisnavigation oder durch von git durchgeführtes globbing (Platzhalter-Auflösung z.B. *.jpg) erreicht wurden, werden stillschweigend ignoriert. Der git add Befehl kann das Hinzufügen ignorierter Dateien mit der Option -f (force) erzwingen.
Bitte lesen Sie git-commit[1] für Alternativen zum Hinzufügen von Inhalt zu einem Commit.
-Dateien aus denen Inhalt hinzugefügt wird. Dateien, mit im Namen enthaltenen Wildcards (sog. File-Globs, z.B. *.c), können eingegeben werden, um alle übereinstimmenden Dateien hinzuzufügen. Auch ein vorangestellter Verzeichnisname (z.B. dir, um dir/file1 und dir/file2 hinzuzufügen) kann angegeben werden, um den Index zu aktualisieren, damit er dann dem aktuellen Zustand des Verzeichnisses als Ganzem entspricht (z.B. wird die Angabe von dir nicht nur eine im Arbeitsbereich modifizierte Datei dir/file1, eine zum Arbeitsbereich hinzugefügte Datei dir/file2, sondern auch eine aus dem Arbeitsbereich entfernte Datei dir/file3 aufzeichnen). Es ist zu beachten, dass ältere Versionen von Git bisher die gelöschten Dateien ignoriert haben; benutzen Sie die Option --no-all, wenn Sie geänderte oder neue Dateien hinzufügen, aber gelöschte ignorieren wollen.
Für mehr Detail über die <Pfadspezifikation> Syntax kann der 'pathspec' Eintrag im gitglossary[7] zur Rate gezogen werden.
-Fügt die Datei(en) nicht wirklich hinzu, sondern zeigt nur an, ob sie existieren und/oder ignoriert werden.
-Gib ausführliche Informationen aus.
-Erzwingt das Hinzufügen normalerweise ignorierter Dateien.
-Allow updating index entries outside of the sparse-checkout cone. Normally, git add refuses to update index entries whose paths do not fit within the sparse-checkout cone, since those files might be removed from the working tree without warning. See git-sparse-checkout[1] for more details.
Fügt geänderte Inhalte im Arbeitsbereich interaktiv zum Index hinzu. Optionale Pfad-Argumente können verwendet werden, um die Operation auf einen spezifischen Teil des Arbeitsbereichs einzuschränken. Siehe „Interaktiver Modus“ für weitere Details.
-Wählt interaktiv Blöcke aus Patches zwischen dem Index und dem Arbeitsbereich aus und fügt sie dem Index hinzu. Dadurch hat der Benutzer die Möglichkeit, die Differenz zu überprüfen, bevor er geänderte Inhalte zum Index hinzufügt.
-Dadurch wird praktisch add --interactive ausgeführt, aber das anfängliche Befehlsmenü wird umgangen und direkt zum Unterbefehl patch weitergeleitet. Siehe „Interaktiver Modus“ für weitere Details.
Öffnet Diff gegenüber dem Index in einem Editor und lässt ihn vom Benutzer bearbeiten. Nach dem Schließen des Editors sollten die Headerteile (hunk headers) angepasst werden und der Patch auf den Index angewendet werden.
-Der Zweck dieser Option besteht darin, einzelne Zeilen des Patches für die Anwendung auszuwählen oder sogar den Inhalt der zu inszenierenden (staged) Zeilen zu modifizieren. Das geht schneller und ist flexibler als mit dem interaktiven Hunk-Selector. Es ist jedoch leicht, sich selbst zu verwirren und einen Patch zu erstellen, der sich nicht auf den Index bezieht. Siehe bei PATCHES BEARBEITEN weiter unten.
-Aktualisiert den Index genau dort, wo er bereits einen Eintrag hat, der mit der <Pfadspezifikation> übereinstimmt. Dadurch werden sowohl Indexeinträge entfernt als auch modifiziert, um dem Arbeitsbereich zu entsprechen, aber keine neuen Dateien hinzugefügt.
-Wenn die Option -u verwendet wird und keine <Pfadspezifikation> angegeben wird, werden alle getrackten Dateien im gesamten Arbeitsbereich aktualisiert (frühere Git-Versionen begrenzten die Aktualisierung auf das aktuelle Verzeichnis und seine Unterverzeichnisse).
Aktualisiert den Index nicht nur dort, wo der Arbeitsbereich eine Datei enthält, die mit der <Pfadspezifikation> übereinstimmt, sondern auch dort, wo der Index bereits einen Eintrag enthält. Dadurch werden Indexeinträge hinzugefügt, modifiziert und entfernt, um dem Arbeitsbereich anzupassen.
-Wenn keine <Pfadspezifikation> angegeben wird und wenn die Option -A verwendet wird, werden alle Dateien im gesamten Arbeitsbereich aktualisiert (alte Versionen von Git begrenzten die Aktualisierung auf das aktuelle Verzeichnis und seine Unterverzeichnisse).
Aktualisiert den Index durch Hinzufügen neuer Dateien, die dem Index unbekannt sind und Dateien, die im Arbeitsbereich geändert wurden, aber ignoriert Dateien, die aus dem Arbeitsbereich entfernt wurden. Diese Option ist eine „Nulloperation“, wenn keine <Pfadspezifikation> verwendet wird.
-Diese Option soll in erster Linie Benutzern helfen, die mit älteren Versionen von Git vertraut sind und deren "git add <Pfadspezifikation>…" ein Synonym für "git add --no-all <Pfadspezifikation>…" war, d.h. gelöschte Dateien ignoriert haben.
-Zeichnet nur den Sachverhalt auf, dass der Pfad später hinzugefügt wird. Ein Eintrag für den Pfad wird ohne Inhalt in den Index aufgenommen. Das ist unter anderem sinnvoll, um den nicht gestagten Inhalt solcher Dateien mit git diff anzuzeigen und sie mit git commit -a zu übertragen (committen).
Füge keine Datei(en) hinzu, sondern aktualisiere lediglich deren stat() Information im Index.
-Falls einige Dateien aufgrund von Fehlern bei der Indizierung nicht hinzugefügt werden konnten, bricht der Vorgang nicht ab, sondern fährt mit dem Hinzufügen der anderen fort. Der Befehl wird trotzdem mit einem Status ungleich Null beendet. Die Konfigurationsvariable add.ignoreErrors kann auf "true" gesetzt werden, um dies zum Standardverhalten zu machen.
Diese Option kann nur zusammen mit --dry-run verwendet werden. Mit dieser Option kann der Benutzer prüfen, ob eine der angegebenen Dateien ignoriert werden würden, unabhängig davon, ob sie bereits im Arbeitsbereich vorhanden sind oder nicht.
Standardmäßig warnt git add, wenn ein eingebettetes Repository zum Index hinzugefügt wird, ohne dass git submodule add verwendet wird, um einen Eintrag in .gitmodules zu erstellen. Diese Option unterdrückt die Warnung (z.B. wenn Sie Bearbeitungsschritte an Submodulen manuell durchführen).
Apply the "clean" process freshly to all tracked files to forcibly add them again to the index. This is useful after changing core.autocrlf configuration or the text attribute in order to correct files added with wrong CRLF/LF line endings. This option implies -u. Lone CR characters are untouched, thus while a CRLF cleans to LF, a CRCRLF sequence is only partially cleaned to CRLF.
Überschreibt das Executable-Bit der hinzugefügten Dateien. Das Executable-Bit wird nur im Index geändert, die Dateien auf der Festplatte bleiben unverändert.
-Die Pfadangabe wird in <Datei> statt über Befehlszeilen-Argumente übergeben. Wenn <Datei> genau - ist, wird die Standardeingabe verwendet. Pfadspezifische Elemente werden durch LF oder CR/LF getrennt. Pathspec-Elemente können in Anführungszeichen gesetzt werden, wie für die Konfigurations-Variable core.quotePath beschrieben (siehe git-config[1]). Siehe auch --pathspec-file-nul und global --literal-pathspecs.
Nur sinnvoll mit --pathspec-from-file. Pfadspezifische Elemente werden mit dem Steuerzeichen-Code NULL getrennt und alle anderen Zeichen werden unverändert übernommen (einschließlich der Zeilenumbrüche und Anführungszeichen).
Diese Option kann dazu verwendet werden, Befehlszeilenoptionen von der Liste von Dateien zu trennen. Dies ist sinnvoll, wenn Dateinamen mit Befehlszeilenoptionen verwechselt werden könnten.
-Füge die Inhalte aller *.txt Dateien unter dem Documentation Verzeichnis und seinen Unterverzeichnissen hinzu:
$ git add Documentation/\*.txt-
Anmerkung: das Sternchen * wird in diesem Beispiel vom Befehlsprozessor (shell) nicht automatisch erweitert, wodurch der git add Befehl auch Unterverzeichnisse des Documentation/ Verzeichnisses erfassen kann.
Berücksichtigt das Hinzufügen von Inhalten aus allen git-*.sh-Skripten:
-$ git add git-*.sh-
Weil in diesem Beispiel die Shell über das Sternchen expandiert (d.h. Sie listen die Dateien explizit auf), wird subdir/git-foo.sh nicht berücksichtigt.
Wird Git im interaktiven Modus gestartet, zeigt es zuerst die Ausgabe des status Unterbefehls, und beginnt dann mit der interaktiven Befehlsverarbeitung.
-Diese zeigt eine Liste der möglichen Unterbefehle und fragt "What now> ". Wenn die Frage mit einem einzelnen > endet, kann man im Allgemeinen aus einer der folgenden Optionen wählen und diese mit der Eingabetaste bestätigen:
-*** Befehle *** - 1: status 2: update 3: revert 4: add untracked - 5: patch 6: diff 7: quit 8: help - Was nun> 1-
Man kann auch s oder sta oder status eingeben, solange die Auswahl eindeutig ist.
Die Hauptbefehlsschleife hat 6 Unterbefehle (sowie zusätzlich help und quit).
-Zeigt den Unterschied zwischen HEAD und dem Index (also was committet wird, wenn man git commit ausführt), sowie zwischen dem Index und den Dateien im Arbeitsbereich (also was man vor einem git commit mittels git-add hinzufügen könnte) für jeden Pfad. Eine Beispielausgabe:
staged unstaged path - 1: binary nothing foo.png - 2: +403/-35 +1/-1 add-interactive.c-
It shows that foo.png has differences from HEAD (but that is binary so line count cannot be shown) and there is no difference between indexed copy and the working tree version (if the working tree version were also different, binary would have been shown in place of nothing). The other file, add-interactive.c, has 403 lines added and 35 lines deleted if you commit what is in the index, but working tree file has further modifications (one addition and one deletion).
-Zeigt die Status Information und wartet mit der Meldung "Update>>" auf weitere Eingaben. Wenn die Meldung mit doppelten >> endet, kann man, getrennt durch Leerzeichen oder Beistriche, mehrere Operationen auswählen. Man kann auch ganze Bereiche angeben, z.B. "2-5 7,9" um 2,3,4,5,7,9 aus der Liste auszuwählen. Wird die zweite Nummer eines Bereichs nicht angegeben, reicht dieser bis an das Ende der Liste, z.B. "7-" um 7,8,9 aus der Liste auszuwählen. Durch * werden alle Listeneinträge ausgewählt.
-Alle ausgewählten Listeneinträge werden wie folgt mit einem Stern * markiert:
-staged unstaged path - 1: binary nothing foo.png -* 2: +403/-35 +1/-1 add-interactive.c-
Ein - vor der Option macht die Auswahl wieder rückgängig:
Update>> -2-
Nachdem die Auswahl getroffen wurde, kann durch Eingabe einer Leerzeile der Inhalt der ausgewählten Dateien in den Index aufgenommen werden.
-Diese Option ist sehr ähnlich zu update, nur wird die im Index gespeicherte Änderungsinformation für die ausgewählten Dateien auf die im HEAD gespeicherte Version zurückgesetzt. Werden neue Dateien zurückgesetzt, so wird die Information darüber aus Git wieder entfernt.
-Mit einer zu update und revert sehr ähnlichen Bedienweise können mit Git noch nicht verwaltete Dateien zum Index hinzugefügt werden.
-Ermöglicht die Auswahl eines Pfades aus der status Liste. Anschließend wird der diff zwischen dem Index und der Datei im Arbeitsbereich angezeigt und gefragt, ob die einzelnen Brocken hinzugefügt werden sollen. Man kann auswählen zwischen (Übersetzung in Klammern):
-y - diesen Patch-Block zum Commit vormerken -n - diesen Patch-Block nicht zum Commit vormerken -q - Beenden; diesen oder alle verbleibenden Patch-Blöcke nicht zum Commit vormerken -a - diesen und alle weiteren Patch-Blöcke dieser Datei zum Commit vormerken -d - diesen oder alle weiteren Patch-Blöcke in dieser Datei nicht zum Commit vormerken -g - Patch-Block zum hinspringen auswählen -/ - nach Patch-Block suchen, der gegebenem regulärem Ausdruck entspricht -j - diesen Patch-Block unbestimmt lassen, nächsten unbestimmten Patch-Block anzeigen -J - diesen Patch-Block unbestimmt lassen, nächsten Patch-Block anzeigen -k - diesen Patch-Block unbestimmt lassen, vorherigen unbestimmten Patch-Block anzeigen -K - diesen Patch-Block unbestimmt lassen, vorherigen Patch-Block anzeigen -s - aktuellen Patch-Block in kleinere Patch-Blöcke aufteilen -e - aktuellen Patch-Block manuell editieren -? - Hilfe anzeigen-
Nachdem zumindest ein Source Brocken ausgewählt wurde werden die ausgewählten Brocken in den Index aufgenommen.
-Sie können die Konfigurations-Variable interactive.singleKey auf true setzen um hier nicht Enter drücken zu müssen.
Zeigt die Änderungen an, die committet werden würden (also zwischen HEAD und Index).
-Der Aufruf von git add -e oder die Auswahl von e aus dem interaktiven Hunk-Selector öffnet einen Patch in Ihrem Editor. Nach Verlassen des Editors wird das Ergebnis in den Index übernommen. Es ist Ihre Entscheidung, beliebige Änderungen an dem Patch vorzunehmen, aber beachten Sie, dass einige Änderungen irreführende Ergebnisse haben oder sogar zu einem Patch führen können, der nicht angewendet werden kann. Wenn Sie die Operation vollständig abbrechen wollen (d.h. nichts Neues in den Index stagen), löschen Sie einfach alle Zeilen des Patches. Die folgende Liste beschreibt einige gängige Elemente, die Sie in einem Patch sehen können, und welche Bearbeitungsvorgänge bei ihnen sinnvoll sind.
Hinzugefügter Inhalt wird durch Zeilen dargestellt, die mit "+" beginnen. Sie können das Staging von hinzugefügten Zeilen verhindern, indem Sie diese löschen.
-Entfernter Inhalt wird durch Zeilen dargestellt, die mit "-" beginnen. Sie können die Entfernung aus der Staging Area verhindern, indem Sie das "-" in ein " " (Leerzeichen) umwandeln.
-Geänderter Inhalt wird durch "-" Zeilen (entfernen des alten Inhalts), gefolgt von "+" Zeilen (hinzufügen des Ersatzinhalts) dargestellt. Sie können das Staging der Änderung verhindern, indem Sie "-" Zeilen in " " konvertieren und "+"-Zeilen entfernen. Achten Sie darauf, dass die Änderung von nur der Hälfte des Paares wahrscheinlich irreführende Änderungen am Index mit sich bringt.
-Es gibt auch komplexere Operationen, die durchgeführt werden könnten. Aber Vorsicht: Da der Patch nur auf den Index und nicht auf den Arbeitsbereich angewendet wird, scheint es, als würde der Arbeitsbereich die Änderung im Index "rückgängig machen". Wenn zum Beispiel eine neue Zeile in den Index eingefügt wird, die sich weder im HEAD noch im Arbeitsbereich befindet, wird sie für einen Commit bereitgestellt, aber diese Zeile erscheint im Arbeitsbereich als zurückgesetzt.
-Vermeiden Sie diese Konstrukte oder gehen Sie mit äußerster Vorsicht vor.
-Inhalt, der nicht zwischen Index und Arbeitsbereich differiert, kann in Kontextzeilen angezeigt werden, die mit einem " " (Leerzeichen) beginnen. Sie können Kontextzeilen zum Entfernen vorsehen, indem Sie das Leerzeichen in ein "-" umwandeln. Die resultierende Datei des Arbeitsbereichs wird angezeigt, um den Inhalt erneut hinzuzufügen.
-Man kann auch Kontextzeilen modifizieren, indem man sie zur Entfernung bereitstellt (man wandelt " " in "-" um) und eine "+" Zeile mit dem neuen Inhalt hinzufügt. In ähnlicher Weise kann man "+" Zeilen für bestehende Erweiterungen oder Modifikationen verändern. In allen Fällen erscheint die neue Modifikation im Arbeitsbereich als zurückgesetzt.
-Man kann auch Inhalt neu hinzufügen, der im Patch nicht vorhanden ist. Dazu einfach neue Zeilen einfügen, die jeweils mit "+" beginnen. Die Erweiterung erscheint dann im Arbeitsbereich als zurückgesetzt.
-Es gibt auch einige Operationen, die ganz vermieden werden sollten, da sie die Anwendung des Patches unmöglich machen würden:
-Hinzufügen von Kontext (" ") oder Entfernen ("-") von Zeilen
-Löschen von Kontext oder Entfernen von Zeilen
-Ändern des Inhalts von Kontextzeilen oder entfernen von Zeilen
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Teil der git[1] Suite
-git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] - [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--sparse] - [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize] - [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]] - [--] [<pathspec>…]-
Þessi skipun uppfærir atriðaskrána með því að nota það innihald sem finnst í verktrénu á þeirri stundu, til þess að undirbúa innihaldið sem hefur verið staðhæft fyrir næsta innlegg. Hún bætir venjulega við því innihaldi sem er til staðar í heild, en með sumum valmöguleikum er einnig hægt að nota hana til þess að bæta við innihaldi þar sem einungis hluti þeirra breytinga sem hafa verið gerðar í verktrénu eru lagðar við, eða til að fjarlægja slóðir sem eru ekki lengur til í verktrénu.
-"index"-inn (atriðaskráin) inniheldur tækifærismynd af innihaldi verktrésins, og það er þessi mynd sem er tekin sem innihald næsta innleggs. Þannig að eftir að þú hefur gert breytingar á verktrénu, og áður en þú setur af stað skipun um nýtt innlegg, verðurðu að nota add (bæta við) skipunina til þess að bæta við öllum nýjum og breyttum skjölum í atriðaskrána.
Hægt er að framkvæma þessa skipun oft áður en innlegg er staðfest. Hún bætir einungis við innihaldi skjals/skjala sem eru tiltekin þegar skipunin um að bæta við er sett í gang; ef þú vilt að breytingar sem gerðar eru seinna séu innifaldar í næsta innleggi verður þú að nota git add (git bæta við) skipunina aftur til þess að bæta nýju innihaldi í atriðaskrána.
Hægt er að nota git status (git staða) skipunina til þess að fá samantekt á því hvaða skjöl innihalda breytingar sem eru staðhæfðar fyrir næsta innlegg.
Skipunin git add (git bæta við) er forstillt þannig að skjöl sem merkt eru sem hunsuð eru ekki tekin með. Ef skjölum sem merkt eru sem hunsuð er sérstaklega bætt í skipunina mun git add misfarast og gefa upp lista af hunsuðum skjölum. Hunsuð skjöl sem hitt er á í rakningu skráasafna eða skjalaklumpun (skilgreinið klumpana áður en skipun er framkvæmd í skelinni) sem Git framkvæmir verða hunsuð án endursvars. Hægt er að nota git add skipunina til þess að bæta við hunsuðum skjölum með valkostinum -f (force, þvinga).
Vinsamlegast skoðið git-commit[1] fyrir aðrar leiðir til þess að bæta innihaldi við innlegg.
-Skjöl sem innihald er fengið úr. Hægt er að tilgreina skjalaklumpa (t.d. *.c) til þess að bæta við öllum skjölum sem eiga við. Einnig er hægt að tilgreina ákveðna skrá á undan (t.d. skrá til að bæta við skrá/skjal1 og skrá/skjal2) til þess að uppfæra atriðaskrána svo hún passi við núverandi ástand skrárinnar í heild (t.d. ef skrá er tilgreind verða ekki einungis skjalið`skrá/skjal1` sem var breytt í verktrénu, og skjalið`skrá/skjal2`sem var bætt við verktréð teknar með, heldur einnig skjalið skrá/skjal3 sem var eytt úr verktrénu). Athugið að eldri útgáfur af Git hunsa skjöl sem hafa verið fjarlægð; notið --no-all (ekki allt) valmölguleikann ef þú vilt bæta við breyttum og nýjum skjölum en hunsa þau sem hafa verið fjarlægð.
Fyrir meiri upplýsingar um samsetningareglur <slóðatilgreiningar> , sjá færsluna fyrir pathspec í gitglossary[7] skýringaskránni.
-Ekki bæta skjalinu/skjölunum við, heldur einungis sýna hvort að þau séu til og/eða verði hunsuð.
-Sýna ferlisupplýsingar.
-Leyfa það að bæta við skjölum sem annars væru hunsuð.
-Allow updating index entries outside of the sparse-checkout cone. Normally, git add refuses to update index entries whose paths do not fit within the sparse-checkout cone, since those files might be removed from the working tree without warning. See git-sparse-checkout[1] for more details.
Bætið innihaldi sem hefur breyst gagnvirkt við atriðaskrána. Hægt er að bæta valfrjálsum slóðarbreytum við skipanir til þess að takmarka aðgerðir við undirgrein verktrésins. Sjá “Gagnvirkt fyrirkomulag” fyrir frekari upplýsingar.
-Velja gagnvirkt stykki úr viðbótum á milli atriðaskráarinnar og vinnutrésins og bætið þeim við atriðaskrána. Þetta gefur notandanum tækifæri til þess að yfirfara mismuninn áður en hinu breytta innihaldi verður bætt við atriðaskrána.
-Þetta jafngildir að einhverju leyti skipuninni add --interactive (bæta við gagnvirkt), en stekkur yfir upphafshluta skipunarinnar og fer beint í undirskipunina patch(viðbætur). Sjá “Gagnvirkt fyrirkomulag” fyrir frekari upplýsingar.
Opna mismunaskrána gagnvart atriðaskránni og leyfa notandanum að breyta henni. Eftir að ritvinnsluforritinu er lokað, aðlaga stykkjahausana og leggja viðbæturnar við atriðaskrána.
-Tilgangur þessa valmöguleika er að velja sérstakar línur í viðbótunum til þess að leggja við, eða jafnvel breyta innihaldi þeirra lína sem á að staðhæfa. Þetta getur verið fljótlegra og sveigjanlegra heldur en að nota gagnvirka stykkjavalið. Hins vegar er auðvelt að ruglast að búa til viðbætur sem leggjast ekki við atriðaskrána. Sjá AÐ BREYTA VIÐBÓTUM hér fyrir neðan.
-Uppfæra atriðaskrána einungis þar sem nú þegar er færsla sem passar við <slóðartilgreining>. Þetta fjarlægir og breytir færslum í atriðaskránni til þess að hún passi við verktréð, en bætir ekki við neinum nýjum skjölum.
-Ef engin <slóðatilgreining> er gefin þegar -u (update, uppfæra) valmöguleikinn er notaður, eru öll skjöl undir eftirliti í öllu verktrénu uppfærð (eldri útgáfur af Git takmörkuðu uppfærsluna við þá skrá sem verið var að vinna í og undirskrár hennar).
Ekki bara uppfæra atriðaskrána þegar verktréð inniheldur skjal sem passar við <slóðatilgreining> heldur einnig þegar atriðaskráin inniheldur færslu nú þegar. Þetta bætir við, breytir, og fjarlægir færslur úr atriðaskránni til þess að passa við verktréð.
-Ef engin <slóðatilgreining> er gefin þegar -A (all, allt) valmöguleikinn er notaður, eru öll sjöl í vinnutrénu uppfærð (eldri útgáfur af Git takmörkuðu uppfærsluna við þá skrá sem verið var að vinna í og undirskrár hennar).
Uppfæra atriðaskrána með því að bæta við skjölum sem finnast ekki í atriðaskránni og skjöl sem hefur verið breytt í verktrénu, en hunsa skjöl sem búið er að fjarlægja úr verktrénu. Þessi valmöguleiki er slæpi þegar engin <slóðatilgreining> er notuð (þ.e.a.s. gerir ekki neitt).
-Þessi valmöguleiki er fyrst og fremst til þess að hjálpa notendum sem eru vanir eldri útgáfum af Git, þar sem "git add <slóðatilgreining>…" var samheiti fyrir "git add --no-all <slóðatilgreining>…", þ.e. hunsa skjöl sem hafa verið fjarlægð.
-Einungis skrá að slóðinni verði bætt við síðar. Færsla er búin til fyrir slóðina og sett í atriðaskrána án innihalds. Þetta er meðal annars nytsamlegt til þess að sýna óstaðhæft innihald slíkra skráa með git diff (git mismunaskrá) og að leggja þær inn með git commit -a (git innlegg allt).
Ekki bæta skjalinu/skjölunum við, einungis uppfæra stat() (staða) upplýsingar í atriðaskránni.
-Ef ekki er hægt að bæta við skjölum vegna villna við skráningu, ekki hætta við aðgerðina heldur halda áfram að bæta öðrum skjölum við. Skipuninni mun samt ljúka í "ekki núll" stöðu, þ.e. ekki villulaust. Hægt er að skrá breytuna add.ignoreErrors (hunsa villur í viðbótum) sem "true" (satt) til þess að þetta sé forstillt hegðun.
Þennan valmöguleika er einungis hægt að nota með --dry-run (forprófun). Með því að nota þennan valmöguleika getur notandinn athugað hvort einhver af viðkomandi skjölum verði hunsuð, alveg sama hvort þau eru nú þegar í verktrénu eða ekki.
-Forstilling skipunarinnar git add mun vara notandann við þegar innfelldri hirslu er bætt við atriðaskrána án þess að nota git submodule add (git bæta við undirskipaðri verkeiningu) til þess að búa til færslu í .gitmodules (verkeiningar í git). Þessi valmöguleiki mun þagga viðvörunina (þ.e. ef þú ert handvirkt að framkvæma aðgerðir á undirskipuðum verkeiningum).
Apply the "clean" process freshly to all tracked files to forcibly add them again to the index. This is useful after changing core.autocrlf configuration or the text attribute in order to correct files added with wrong CRLF/LF line endings. This option implies -u. Lone CR characters are untouched, thus while a CRLF cleans to LF, a CRCRLF sequence is only partially cleaned to CRLF.
Taka ekki tilliti til keyranlega hluta þeirra skjala sem bætt er við. Keyranlegu hlutunum er einungis breytt í atriðaskránni, skjölin á diskdrifinu eru óbreytt á eftir.
-Slóðatilgreiningar eru sendar til skipunarinnar í <skjal> í staðinn fyrir að gera það með breytum á skipanalínunni. Ef <skjal> er návkæmlega - er staðalílag notað, þ.e. það sem viðkomandi forrit telur hefðbundna ílagsaðferð. Sératriði í slóðatilgreiningaskránni skal aðskilja með LF (almennu línuendatákni) eða CR/LF (Windows línuendatákni). Hægt er að setja sératriði í gæsalappir eins og útskýrt er í sambandi við stillingarbreytuna core.quotePath(tilvísun slóðar í kjarna) (sjá git-config[1], git stillingar). Sjá einnig --pathspec-file-nul (ekkert skjal fyrir slóðartilgreiningu) og altækar --literal-pathspecs (bóksaflegar slóðatilgreiningar) stillingar.
Hefur einungis merkingu með --pathspec-from-file (slóðatilgreiningar úr skali). Sératriði slóðatilgreiningar eru aðskild með NUL (merkingarlaus) tákni og öll önnur tákn eru tekin bókstaflega (þar með talin nýlínutákn og gæsalappir).
Hægt er að nota þennan valmöguleika til þess að aðskilja valmöguleika skipanalínunnar frá skjalalistanum (hjálplegt þegar skjalanöfn gætu verið mistekin fyrir skipanalínuvalmöguleika).
-Bætir innihaldi allra *.txt(textaskjöl) í Documentation (leiðbeiningasafn) skránni og undirskrám hennar:
$ git add Documentation/\*.txt-
Athugið að stjarnan * er í gæsalöppum í þessu dæmi; þetta leyfir skipuninni að taka með skjöl úr undirskrám Documentation/ (leiðbeiningaskrá).
Íhugar að bæta við innihaldi úr öllum git-*.sh (forrit fyrir skel) forritlingum:
-$ git add git-*.sh-
Vegna þess að þetta dæmi leyfir skelinni að útvíkka stjörnuna (þ.e. þú ert að lista skjölin beint), tekur hún ekki til greina`undirskrá/git-foo.sh`(þú hefur einungis tilgreint skjöl í þessari skrá).
-Þegar skipunin er framkvæmd með gagnvirku fyrirkomulagi, sýnir hún frálag status (staða) undirskipunarinnar, og fer svo yfir í gagnvirku skipanalykkjuna.
-Skipanalykkjan sýnir lista yfir þær undirskipanir sem eru tiltækar, og kvaðninguna "What now> " (hvað nú). Almennt þegar kvaðning á skipanalínu endar með einum oddklofa, >, getur þú valið einn af þeim möguleikum sem eru uppgefnir og ýtt á nýlínutakkann (enter), svona:
-*** Skipanir*** - 1: status 2: update 3: revert 4: add untracked - 5: patch 6: diff 7: quit 8: help - What now> 1-
Þú getur einnig notað s eða sta eða status(staða) hér fyrir ofan svo lengi sem valið er sérstakt.
Aðalskipanalykkjan hefur 6 undirskipanir (fyrir utan hjálp og hætta).
-Þessi skipun sýnir breytingar á milli HAUS og atriðaskrár (þ.e. það sem verður lagt inn ef þú gefur skipunina git commit (git inlegg)), og á milli atriðaskrárinnar og skjala í verktrénu (þ.e. það sem þú gætir staðhæft frekar með því að nota git add (git bæta við) áður en þú notar git commit(git inlegg)) fyrir hverja slóð. Frálagssýnishorn lítur svona út:
staged unstaged path - 1: binary nothing foo.png - 2: +403/-35 +1/-1 add-interactive.c-
It shows that foo.png has differences from HEAD (but that is binary so line count cannot be shown) and there is no difference between indexed copy and the working tree version (if the working tree version were also different, binary would have been shown in place of nothing). The other file, add-interactive.c, has 403 lines added and 35 lines deleted if you commit what is in the index, but working tree file has further modifications (one addition and one deletion).
-Þessi skipun sýnir upplýsingar um stöðu gagna og setur fram kvaðninguna "Update>>" (uppfærsla). Þegar kvaðning endar með tvöföldum oddklofa, >>, getur þú valið fleiri en eina skipun með bil eða kommu á milli. Þú getur einnig tilgreint seilingar. T.d. "2-5 7,9" til að velja 2,3,4,5,7,9 úr listanum. Ef seinni tölunni er sleppt úr tilgreiningu seilingar, tekur skipunin með allar viðbætur sem eru eftir. T.d. "7-" til að velja 7,8,9 úr listanum. Þú getur tilgreint * til þess að velja allt.
-Það sem þú velur er þá auðkennt með stjörnu, *, svona:
-staged unstaged path - 1: binary nothing foo.png -* 2: +403/-35 +1/-1 add-interactive.c-
Til þess að fjarlægja val er sett mínus, -, á undan ílaginu, svona:
Update>> -2-
Eftir að hafa valið það sem áætlað er að uppfæra þarf að svara skipuninni með tómri línu til þess að staðhæfa innihald þeirra skjala í verktrénu sem samsvara völdum slóðum í atriðaskránni.
-Þessi skipun hefur mjög svipað viðmót og update (uppfæra), og staðhæfðu upplýsingarnar fyrir valdar slóðir eru bakfærðar til HAUS útgáfunnar. Þegar nýjar slóðir eru bakfærðar eru þær ekki lengur undir eftirliti.
-Þessi skipun hefur mjög svipað viðmót og update (uppfæra) og revert (bakfæra) og leyfir þér að bæta slóðum sem ekki eru undir eftirliti við atriðaskrána.
-Þessi skipun gefur þér möguleika á að velja eina slóð úr mengi sem líkist status (staða). Eftir að hafa valið slóðina setur skipunin fram mismunaskrá á milli skjalsins í atriðaskránni og skjalsins í verktrénu og spyr hvort þú viljir staðfæra breytingar hvers stykkis fyrir sig. Þú getur valið einhvern af eftirfarandi valmöguleikum og ýtt á nýlínutakkann:
-y - staðhæfa þetta stykki -n - ekki staðhæfa þetta stykki -q - hætta (quit); ekki staðhæfa þetta stykki eða neitt af þeim sem eftir eru -a - staðhæfa þetta stykki og öll sem eftir eru -d - ekki staðhæfa þetta stykki eða neitt af þeim sem eftir eru -g - velja stykki til að færa sig til -/ - velja stykki sem passar við uppgefna reglusegð -j - skilja þetta stykki eftir óútkljáð, sjá næsta óútkljáða stykki -J - skilja þetta stykki eftir óútkljáð, sjá næsta stykki -k - skilja þetta stykki eftir óútkljáð, sjá fyrra óútkljáða stykki -K - skilja þetta stykki eftir óútkljáð, sjá fyrra stykki -s - skipta viðkomandi stykki í minni stykki -e - breyta viðkomandi stykki handvirkt -? - prenta hjálp-
Eftir að hafa ákveðið örlög allra stykkja, ef einhver stykki voru valin, er atriðaskráin uppfærð með völdum stykkjum.
-Þú getur sleppt því að þurfa að ýta á nýlínutakkann hér með því að gefa stillingabreytunni interactive.singleKey (gagnvirkur einn takki) gildið true (satt).
Þessi skipun leyfir þér að skoða yfir hvað verður lagt inn (þ.e. á milli HAUS og atriðaskrár).
-Með því að gefa skipunina git add -e (git bæta við með breytingum) eða að velja e (edit, breyta) þegar stykki eru valin gagnvirkt opnar þú viðbætur í ritvinnsluforritinu þínu; eftir að ritvinnsluforritið lokast er breytingunum bætt við atriðaskrána. Þér er frjálst að breyta viðbótunum eins og þér sýnist, en athugaðu að sumar breytingar gætu haft ruglandi afleiðingar, eða jafnvel komið í veg fyrir að viðbótunum sé bætt við atriðaskrána. Ef þú vilt hætta alveg við þess aðgerð (þ.e. ekki staðhæfa neitt nýtt yfir í atriðaskrána), þá einfaldlega eyðirðu öllum línunum úr viðbótunum. Listinn hér fyrir neðan lýsir nokkrum algengum hlutum sem þú gætir séð í viðbótum, og hvaða aðgerðir til breytinga er gáfulegt að nota á þá.
Innihald í skjali sem bætt hefur verið við er merkt með plús, "+". Þú getur komið í veg fyrir staðhæfingu slíkra lína með því að eyða þeim.
-Innihald skjals sem hefur verið fjarlægt er merkt í byrjun línu með mínus, "-". Þú getur komið í veg fyrir að þær séu fjarlægðar við staðhæfingu með því að breyta mínusnum í bil, " ".
-Innihald skjals sem hefur verið breytt er merkt með mínus "-" við línuna sem hefur verið breytt (sem fjarlægir gamla innihaldið) og þeirri línu fylgja línur merktar með plús, "+" (sem bæta inn því innihaldi sem kemur í staðinn). Þú getur komið í veg fyrir að þessar breytingar séu staðhæfðar með því að breyta mínusnum í bil, " ", og fjarlægja þær línur sem merktar eru með plús. Varaðu þig á því að breyta aðeins öðru hvoru (mínus í bil eða fjarlægja plúsmerktrar línur) getur valdið ruglandi breytingum í atriðaskránni.
-Til eru flóknari aðgerðir sem hægt er að framkvæma. En varaðu þig á því að vegna þess að viðbæturnar eru einungis færðar inn í atriðaskrána en ekki verktréð lítur það út eins og verktréð "afturkalli" breytingarnar í atriðaskránni. Til dæmis, ef þú bætir við nýrri línu í atriðaskránni sem er hvorki í HAUS né verktré mun staðhæfa nýju línuna fyrir næsta innlegg en hún mun birtast eins og hún hafi verið afturkölluð í vektrénu.
-Varist að nota eftirfarandi aðgerðir, eða notið þær með mikilli varúð.
-Innihald skjals sem er eins í atriðaskrá og verktré er sýnt sem línur sem byrja á bili, " ". Þú getur staðhæft slíkar línur til að vera fjarlægðar með því að breyta bilinu í mínus, "-". Afleiðing þess er að í verktrénu mun líta svo út að línunni hafi verið bætt inn í skjalið aftur.
-Það er líka hægt að breyta línum með því að staðhæfa þær til að verða fjarlægðar (með því að breyta bili, " ", í mínus, "-") og að bæta við plúslínu ("+") með nýja innihaldinu. Á sama hátt er hægt að breyta plúslínum sem gefa til kynna breytingar og viðbætur í skjalinu. Í öllum tilfellum mun líta svo út að nýju breytingarnar hafi verið afturkallaðar í verktrénu.
-Þú getur líka bætt við nýju innihaldi sem ekki var í viðbótunum fyrir; bættu einfaldlega við nýjum línum, og merktu hverja þeirra með plús, "+". Hver breyting mun líta út eins og afturkölluð í verktrénu.
-Einnig eru fjölmargar aðgerðir sem forðast ætti algjörlega, þar sem þær gera það ómögulegt að leggja viðbæturnar við:
-Að bæta við (" ") línum eins og þær séu þegar til eða fjarlæga ("-") línur sem ekki eru til í skjalinu
-Að eyða línum sem eru til (" ") eða línum sem á að fjarlægja ("-")
-Að breyta innihaldi lína sem eru til (" ") eða á að fjarlægja ("-")
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Hluti af git[1] fylkingunni
-git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] - [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--sparse] - [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize] - [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]] - [--] [<pathspec>…]-
Această comandă actualizează indexul folosind conținutul curent găsit în arborele de lucru, pentru a pregăti conținutul pregătit pentru următoarea confirmare. De obicei, adaugă conținutul actual al căilor de acces existente ca întreg, dar, cu ajutorul unor opțiuni, poate fi utilizată și pentru a adăuga conținut cu aplicarea doar a unei părți din modificările aduse fișierelor din arborele de lucru sau pentru a elimina căile de acces care nu mai există în arborele de lucru.
-"Index" conține un instantaneu al conținutului configurației de lucru, iar acest instantaneu este luat ca fiind conținutul următoarei comenzi. Prin urmare, după ce ați efectuat orice modificare în configurația de lucru și înainte de a rula comanda commit, trebuie să utilizați comanda add pentru a adăuga orice fișier nou sau modificat la index.
Această comandă poate fi executată de mai multe ori înainte de o confirmare. Aceasta adaugă doar conținutul fișierului (fișierelor) specificat(e) în momentul în care comanda add este executată; dacă doriți ca modificările ulterioare să fie incluse în următoarea confirmare, trebuie să executați din nou git add pentru a adăuga noul conținut la index.
Comanda git status poate fi utilizată pentru a obține un rezumat al fișierelor care au modificări care sunt pregătite pentru următoarea confirmare.
Comanda git add nu va adăuga în mod implicit fișiere ignorate. Dacă în linia de comandă au fost specificate în mod explicit fișiere ignorate, git add va eșua cu o listă de fișiere ignorate. Fișierele ignorate la care se ajunge prin recursivitatea directoarelor sau prin globarea numelor de fișiere efectuată de Git (citați glob-urile înainte de shell) vor fi ignorate în mod silențios. Comanda "git add" poate fi utilizată pentru a adăuga fișiere ignorate cu opțiunea -f (force).
Vă rugăm să consultați git-commit[1] pentru modalități alternative de a adăuga conținut la un commit.
-Fișiere din care se adaugă conținut. Se pot introduce blocuri de fișiere (de exemplu, *.c) pentru a adăuga toate fișierele corespunzătoare. De asemenea, se poate introduce un nume de director (de exemplu, dir pentru a adăuga dir/file1 și dir/file2) pentru a actualiza indexul pentru a se potrivi cu starea curentă a directorului ca întreg (de exemplu, dacă se specifică dir se va înregistra nu numai un fișier dir/file1 modificat în configurația de lucru, un fișier dir/file2 adăugat în configurația de lucru, ci și un fișier dir/file3 eliminat din acesta). Rețineți că versiunile mai vechi ale Git obișnuiau să ignore fișierele eliminate; utilizați opțiunea --no-all dacă doriți să adăugați fișiere modificate sau noi, dar să le ignorați pe cele eliminate.
Pentru mai multe detalii despre sintaxa <pathspec>, consultați intrarea "pathspec" din gitglossary[7].
-Nu adăugați de fapt fișierul (fișierele), doar arătați dacă acestea există și/sau vor fi ignorate.
-Poți să fii vorbăreț.
-Permite adăugarea de fișiere altfel ignorate.
-Permite actualizarea intrărilor din index în afara conului de verificare a sparse-checkout. În mod normal, git add refuză să actualizeze intrările de index ale căror căi de acces nu se încadrează în conul sparse-checkout, deoarece aceste fișiere ar putea fi eliminate din arborele de lucru fără avertisment. Vezi git-sparse-checkout[1] pentru mai multe detalii.
Adăugați în mod interactiv la index conținutul modificat în configurația de lucru. Se pot furniza argumente opționale privind calea de acces pentru a limita operațiunea la un subset al structurii de lucru. A se vedea "Mod interactiv" pentru detalii.
-Alegeți în mod interactiv bucăți de patch-uri între index și arborele de lucru și adăugați-le la index. Astfel, utilizatorul are posibilitatea de a examina diferența înainte de a adăuga conținutul modificat la index.
-Acest lucru rulează efectiv add --interactive, dar ocolește meniul inițial de comenzi și trece direct la subcomanda patch. Pentru detalii, consultați “Modul interactiv”.
Deschideți fișierul diferență față de index într-un editor și lăsați utilizatorul să îl editeze. După ce editorul a fost închis, ajustați anteturile hunk și aplicați patch-ul la index.
-Scopul acestei opțiuni este de a selecta și de a alege liniile din patch-ul care urmează să fie aplicat sau chiar de a modifica conținutul liniilor care urmează să fie etapizate. Această opțiune poate fi mai rapidă și mai flexibilă decât utilizarea selectorului interactiv de hunk-uri. Cu toate acestea, este ușor să te confunzi și să creezi un patch care nu se aplică la index. Consultați EDITING PATCHES (Editarea patch-urilor) de mai jos.
-Actualizează indexul doar acolo unde există deja o intrare care corespunde cu <pathspec>. Acest lucru elimină și modifică intrările din index pentru a se potrivi cu arborele de lucru, dar nu adaugă fișiere noi.
-Dacă nu se dă nici o <pathspec> atunci când se utilizează opțiunea -u, sunt actualizate toate fișierele urmărite din întregul configurație de lucru (vechile versiuni ale Git obișnuiau să limiteze actualizarea la directorul curent și la subdirectoarele sale).
Actualizează indexul nu numai în cazul în care în arborele de lucru există un fișier care se potrivește cu <pathspec>, ci și în cazul în care indexul are deja o intrare. Această operațiune adaugă, modifică și elimină intrări din index pentru a se potrivi cu structura de lucru.
-Dacă nu se indică nicio <pathspec> atunci când se utilizează opțiunea -A, sunt actualizate toate fișierele din întregul configurator de lucru (vechile versiuni ale Git obișnuiau să limiteze actualizarea la directorul curent și la subdirectoarele sale).
Actualizarea indexului prin adăugarea de fișiere noi necunoscute indexului și a fișierelor modificate în configurația de lucru, dar ignoră fișierele care au fost eliminate din configurația de lucru. Această opțiune nu este opțională atunci când nu se utilizează <pathspec>.
-Această opțiune este în primul rând pentru a ajuta utilizatorii care sunt obișnuiți cu versiunile mai vechi de Git, în care "git add <pathspec>…" era un sinonim pentru "git add --no-all <pathspec>…", adică ignora fișierele eliminate.
-Înregistrați doar faptul că traseul va fi adăugat ulterior. O intrare pentru calea de acces este plasată în index fără conținut. Acest lucru este util, printre altele, pentru a arăta conținutul neetajat al unor astfel de fișiere cu git diff și pentru a le confirma cu git commit -a.
Nu adăugați fișierul (sau fișierele), ci doar reîmprospătați informațiile stat() ale acestora în index.
-În cazul în care unele fișiere nu au putut fi adăugate din cauza unor erori de indexare, nu întrerupeți operațiunea, ci continuați să le adăugați pe celelalte. Comanda va ieși în continuare cu un status diferit de zero. Variabila de configurare add.ignoreErrors poate fi setată la true pentru ca acesta să fie comportamentul implicit.
Această opțiune poate fi utilizată numai împreună cu --dry-run. Utilizând această opțiune, utilizatorul poate verifica dacă vreunul dintre fișierele date va fi ignorat, indiferent dacă acestea sunt deja prezente sau nu în configurația de lucru.
-În mod implicit, git add va avertiza atunci când se adaugă un depozit încorporat în index fără a folosi git submodule add pentru a crea o intrare în .gitmodules. Această opțiune va suprima avertismentul (de exemplu, dacă efectuați manual operațiuni asupra submodulelor).
Apply the "clean" process freshly to all tracked files to forcibly add them again to the index. This is useful after changing core.autocrlf configuration or the text attribute in order to correct files added with wrong CRLF/LF line endings. This option implies -u. Lone CR characters are untouched, thus while a CRLF cleans to LF, a CRCRLF sequence is only partially cleaned to CRLF.
Suprascrieți bitul executabil al fișierelor adăugate. Bitul executabil este modificat doar în index, fișierele de pe disc rămân neschimbate.
-Pathspec este transmis în <file> în loc de argetele din linia de comandă. Dacă <file> este exact -, se utilizează intrarea standard. Elementele Pathspec sunt separate prin LF sau CR/LF. Elementele Pathspec pot fi citate așa cum se explică pentru variabila de configurare core.quotePath (a se vedea git-config[1]). A se vedea și --pathspec-file-nul și --literal-pathspecs global.
Are sens numai cu --pathspec-from-file. Elementele Pathspec sunt separate prin caracterul NUL, iar toate celelalte caractere sunt luate în considerare în mod literal (inclusiv liniile de început și ghilimelele).
Această opțiune poate fi utilizată pentru a separa opțiunile liniei de comandă de lista de fișiere (util atunci când numele fișierelor pot fi confundate cu opțiunile liniei de comandă).
-Adaugă conținutul din toate fișierele *.txt din directorul Documentation și din subdirectoarele sale:
$ git add Documentation/\*.txt-
Observați că asteriscul * este citat din shell în acest exemplu; acest lucru permite comenzii să includă fișierele din subdirectoarele din directorul Documentation/.
Are în vedere adăugarea conținutului din toate scripturile git-*.sh:
-$ git add git-*.sh-
Deoarece acest exemplu permite shell-ului să extindă asteriscul (adică listați fișierele în mod explicit), nu ia în considerare subdir/git-foo.sh.
Atunci când comanda intră în modul interactiv, aceasta afișează rezultatul subcomandei "status" și apoi intră în bucla de comandă interactivă.
-Bucla de comenzi afișează lista de subcomandă disponibile și oferă o solicitare "What now> ". În general, atunci când promptul se termină cu un singur ">", puteți alege doar una dintre opțiunile oferite și tasta return, astfel:
-*** Comenzi *** - 1: status 2: update 3: revert 4: add untracked - 5: patch 6: diff 7: quit 8: help - Ce se întâmplă acum> 1 -patch 6: diff 7: quit 8: help - What now> 1-
De asemenea, puteți spune s sau sta sau status mai sus, atâta timp cât alegerea este unică.
Bucla comenzii principale are 6 subcomandă (plus help și quit).
-Aceasta arată modificarea între HEAD și index (adică ceea ce va fi trimis dacă spui git commit) și între index și fișierele din configurația de lucru (adică ceea ce ai putea modifica înainte de git commit folosind git add) pentru fiecare cale. Un exemplu de ieșire arată astfel:
staged unstaged path - 1: binary nothing foo.png - 2: +403/-35 +1/-1 add-interactive.c-
It shows that foo.png has differences from HEAD (but that is binary so line count cannot be shown) and there is no difference between indexed copy and the working tree version (if the working tree version were also different, binary would have been shown in place of nothing). The other file, add-interactive.c, has 403 lines added and 35 lines deleted if you commit what is in the index, but working tree file has further modifications (one addition and one deletion).
-Aceasta afișează informațiile de stare și emite o solicitare "Update>>". Atunci când promptul se termină cu dublu ">>", puteți face mai multe selecții, concatenate cu spații albe sau virgule. De asemenea, puteți spune intervale. De exemplu, "2-5 7,9" pentru a alege 2,3,4,5,7,9 din listă. Dacă al doilea număr dintr-un interval este omis, sunt luate toate patch-urile rămase. De exemplu, "7-" pentru a alege 7,8,9 din listă. Puteți spune "*" pentru a alege totul.
-Cele pe care le-ați ales sunt apoi evidențiate cu "*", astfel:
-staged unstaged path - 1: binary nothing foo.png -* 2: +403/-35 +1/-1 add-interactive.c-
Pentru a elimina selecția, prefixați intrarea cu -, astfel:
Update>> -2-
După efectuarea selecției, răspundeți cu o linie goală pentru a pune în scenă conținutul fișierelor din configurația de lucru pentru căile selectate în index.
-Aceasta are o interfață de utilizare foarte asemănătoare cu "update", iar informațiile etapizate pentru căile selectate sunt readuse la cele din versiunea HEAD. Anularea căilor de acces noi le face să nu mai fie urmărite.
-Aceasta are o interfață de utilizare foarte asemănătoare cu update și revert și vă permite să adăugați la index căi de acces netrasate.
-Acest lucru vă permite să alegeți o cale dintr-o selecție de tip "status". După alegerea căii, vă prezintă diferența dintre fișierul index și fișierul de lucru și vă întreabă dacă doriți să etapizați modificarea fiecărei bucăți. Puteți selecta una dintre următoarele opțiuni și tasta return:
-y - pune în scenă această bucată -n - nu puneți în scenă această bucată -q - renunță; nu pune în scenă această bucată sau oricare dintre cele rămase -a - pune în scenă această bucată și toate bucățile ulterioare din fișier -d - nu pune în scenă această bucată și nici una dintre bucățile ulterioare din fișier -g - selectează o bucată la care să treacă -/ - caută o bucată care se potrivește cu regex-ul dat -j - lasă această bucată nehotărâtă, vezi următoarea bucată nehotărâtă -J - lasă acest hunk nehotărât, vezi următorul hunk -k - lasă această bucată nehotărâtă, vezi bucată nehotărâtă anterioară -K - lasă această bucată nehotărâtă, vezi bucată anterioară -s - împarte bucata curentă în bucăți mai mici -e - editează manual hunk-ul curent -? - tipărește ajutorul-
După ce se hotărăște ce se întâmplă cu toate părțile, în cazul în care există o parte care a fost aleasă, indexul este actualizat cu părțile selectate.
-Puteți omite să tastați return aici, prin setarea variabilei de configurare interactive.singleKey la true.
Acest lucru vă permite să verificați ce va fi confirmat (adică între HEAD și index).
-Invocând git add -e sau selectând e din selectorul interactiv hunk va deschide un patch în editorul dumneavoastră; după ce editorul iese, rezultatul este aplicat la index. Sunteți liber să faceți modificări arbitrare la patch, dar rețineți că unele modificări pot avea rezultate confuze sau chiar pot duce la un patch care nu poate fi aplicat. Dacă doriți să abandonați complet operațiunea (adică să nu mai puneți nimic nou în index), ștergeți pur și simplu toate liniile din patch. Lista de mai jos descrie unele lucruri comune pe care le puteți vedea într-un patch și ce operații de editare au sens asupra lor.
Conținutul adăugat este reprezentat de liniile care încep cu "+". Puteți împiedica punerea în scenă a liniilor de adăugare prin ștergerea acestora.
-Conținutul eliminat este reprezentat de liniile care încep cu "-". Puteți preveni eliminarea lor prin transformarea lui "-" într-un " " (spațiu).
-Conținutul modificat este reprezentat prin linii "-" (eliminarea conținutului vechi) urmate de linii "+" (adăugarea conținutului de înlocuire). Puteți preveni etapizarea modificării prin transformarea liniilor "-" în " " și prin eliminarea liniilor "+". Aveți grijă că modificarea doar a jumătate din pereche este posibil să introducă modificări confuze în index.
-Există, de asemenea, operații mai complexe care pot fi efectuate. Atenție însă, deoarece patch-ul este aplicat numai la index și nu la configurația de lucru, arborele de lucru va părea că "anulează" modificarea din index. De exemplu, introducerea unei linii noi în index care nu se află nici în HEAD, nici în configurația de lucru va pune în scenă noua linie pentru confirmare, dar linia va părea că a fost anulată în acesta.
-Evitați să utilizați aceste construcții sau faceți acest lucru cu mare precauție.
-Conținutul care nu diferă între index și structura de lucru poate fi afișat pe linii de context, începând cu un " " (spațiu). Puteți etapiza liniile de context pentru a fi eliminate prin transformarea spațiului în "-". Fișierul configurat în structura de lucru va apărea pentru a reintroduce conținutul.
-Se pot modifica, de asemenea, liniile de context, prin pregătirea lor pentru eliminare (prin transformarea " " în "-") și adăugarea unei linii "+" cu noul conținut. În mod similar, se pot modifica liniile "+" pentru adăugirile sau modificările existente. În toate cazurile, noua modificare va apărea inversată în configurația de lucru.
-De asemenea, puteți adăuga conținut nou care nu există în patch; pur și simplu adăugați linii noi, fiecare începând cu "+". Adăugarea va apărea inversată în configurația de lucru.
-Există, de asemenea, câteva operațiuni care ar trebui evitate în totalitate, deoarece acestea vor face imposibilă aplicarea patch-ului:
-adăugarea de linii de context (" ") sau de eliminare ("-")
-ștergerea liniilor de context sau de eliminare
-modificarea conținutului liniilor de context sau de eliminare
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Parte a suitei git[1]
-Para cada “Name <user@host>” ou “<user@host>” na linha de comando ou na entrada padrão (ao utilizar o --stdin), procure o nome canônico e o endereço do e-mail da pessoa (consulte "Mapeando os autores" logo abaixo). Se encontrado, exiba-os; caso contrário, exiba a entrada como estiver.
Para cada contato, é emitida uma única linha, terminada por uma nova linha. Se o nome for informado ou conhecido pelo mailmap, o “Name <user@host>$” será impresso; caso contrário, será impresso apenas “<user@host>$”.
-Consulte mailmap.file e mailmap.blob no git-config[1] para saber como definir um arquivo alvo .mailmap personalizado ou um objeto.
Consulte gitmailmap[5].
-Parte do conjunto git[1]
-git clone [--template=<template-directory>] - [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] - [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] - [--dissociate] [--separate-git-dir <git-dir>] - [--depth <depth>] [--[no-]single-branch] [--no-tags] - [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] - [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow] - [--filter=<filter> [--also-filter-submodules]] [--] <repository> - [<directory>]-
Klont ein Repository in ein neu erzeugtes Verzeichnis, erzeugt Remote-Tracking-Branches zum Nachverfolgen aller Branches des geklonten Repositorys (sichtbar durch git branch --remotes). Zusätzlich wird der gerade aktive Branch des geklonten Projektarchivs lokal angelegt und dessen Inhalte geholt.
Nach dem Klonen aktualisiert ein einfaches git fetch (ohne weitere Argumente) alle Remote-Tracking-Branches und ein Aufruf von git pull (ohne weitere Argumente) wird zusätzlich die Änderungen der Remote-Branch ‚master‘ in den lokalen Master-Branch mergen (das gilt nicht, wenn „--single-branch“ angegeben wird; siehe unten).
Diese Standard-Konfiguration wird durch Anlegen einer Referenz auf den HEAD der Remote-Branch unter refs/remotes/origin und der Einrichtung der Konfigurations-Variablen remote.origin.url und remote.origin.fetch erreicht.
Ist das zu klonende Projektarchiv lokal auf der Maschine, kann durch dieses Flag der normale Git-Transportmechanismus umgangen werden und es wird ein einfacher Kopiervorgang von HEAD und allen unter den objects und refs Verzeichnissen gelegenen Daten durchgeführt. Die Dateien unter .git/objects/ werden zum Platzsparen mittels hard link referenziert anstatt sie physikalisch zu kopieren.
-Wenn das Repository als lokaler Pfad angegeben wird (z.B. /Pfad/zum/Repo), das ist ja die Voreinstellung und --local ist eigentlich überflüssig (Nulloperation). Sobald das Repository als URL angegeben wird, dann wird dieses Flag ignoriert (und wird niemals die lokalen Optimierungen anwenden). Die Angabe von --no-local wird die Vorgabe überschreiben, wenn /Pfad/zum/Repo angegeben wird, und stattdessen den regulären Git-Transport verwenden.
If the repository’s $GIT_DIR/objects has symbolic links or is a symbolic link, the clone will fail. This is a security measure to prevent the unintentional copying of files by dereferencing the symbolic links.
HINWEIS: Dieser Vorgang kann mit gleichzeitigen Änderungen am
-Quell-Repository konkurrieren, ähnlich wie beim Ausführen von
-cp -r src dst bei gleichzeitigem Ändern von src.
Erzwingt ein physikalisches Kopieren aller Dateien im .git/objects/ Verzeichnis anstelle von Hard-Links. Dies kann erwünscht sein, wenn eine Sicherung des Repositorys erstellt werden soll.
Befindet sich das zu klonende Repository lokal auf der Maschine (anstatt Hard-Links zu verwenden), dann werden automatisch alle Objekte mittels .git/objects/info/alternates gemeinsam verwendet. Das erzeugte Repository enthält initial keine eigenen Objekte.
HINWEIS: Dies ist potentiell ein gefährlicher Vorgang; verwenden Sie ihn nicht
-wenn Sie nicht verstehen, was er bewirkt. Wenn Sie Ihr Repository mit dieser Option
-klonen und später Branches im Quell-Repository löschen (oder einen anderen
-Git-Befehl verwenden, der bestehende Commits dereferenziert),
-werden manche Objekte möglicherweise dereferenziert (oder hängengelassen).
-Solche Objekte könnten durch normale Git-Operationen (wie git commit)
-entfernt werden, die automatisch git maintenance run --auto aufrufen. (Siehe
-git-maintenance[1].) Wenn diese Objekte entfernt werden und vom geklonten
-Repository referenziert wurden, wird das geklonte Repository beschädigt.
Man sollte beachten, dass das Ausführen von git repack ohne die Option --local in einem Repository, das mit --shared geklont wurde, Objekte aus dem Quell-Repository in ein Paket im geklonten Repository kopiert und so den von clone --shared eingesparten Plattenplatz entfernt. Dagegen kann git gc sicher ausgeführt werden, das standardmäßig die Option --local verwendet.
Wenn die Abhängigkeit eines mit --shared geklonten Repositorys von seinem Quell-Repository gebrochen werden soll, kann einfach git repack -a ausgeführt werden, um alle Objekte aus dem Quell-Repository „in einem Rutsch“ in das geklonte Repository zu kopieren.
Wenn sich das Referenz-Repository auf dem lokalen Rechner befindet, wird automatisch .git/objects/info/alternates eingerichtet, um Objekte aus dem Referenz-Repository zu erhalten. Wenn, alternativ, ein bereits vorhandenes Repository verwendet wird, müssen weniger Objekte aus dem zu klonenden Repository kopiert werden, was die Belastung für Netzwerk und lokale Sicherung reduziert. Bei der Anwendung von --reference-if-able wird ein nicht existierendes Verzeichnis mit einer Warnung übersprungen, anstatt den Klon abzubrechen.
HINWEIS: Siehe den HINWEIS für die Option --shared
-und auch für die Option --dissociate.
Objekte, die mit der Option --reference spezifiziert sind, von Referenz-Repositorys entlehnen. Dadurch wird der Netzwerktransfer reduziert und die Überführung von Objekten aus diesen Repositorys beendet, nachdem ein Klon mit den notwendigen lokalen Kopien der entlehnten Objekte erstellt wurden. Diese Option kann auch verwendet werden, wenn lokal von einem Repository geklont wird, das schon Objekte von einem anderen Repository übernimmt – das neue Repository wird wiederum Objekte vom selben Repository entlehnen. Diese Option kann verwendet werden, um die Übernahme zu stoppen.
Geräuschlos arbeiten. Der Fortschritt wird nicht an den Standardfehlerstrom gemeldet.
-„Wortreich“ ausführen. Beeinflusst nicht die Fortschrittsmeldung an den Standardfehlerstrom.
-Der Fortschrittsstatus wird standardmäßig auf dem Standardfehlerstrom gemeldet, wenn dieser an ein Terminal angeschlossen ist, es sei denn, --quiet ist angegeben. Dieses Flag erzwingt den Fortschrittsstatus auch dann, wenn der Standardfehlerstrom nicht an ein Terminal gerichtet ist.
Übertragen Sie die angegebene Zeichenfolge an den Server, wenn Sie mit Protokollversion 2 kommunizieren. Die angegebene Zeichenfolge darf kein NUL- oder LF-Zeichen enthalten. Die Behandlung von Server-Optionen, einschließlich unbekannter, durch den Server ist serverspezifisch. Wenn mehrmals --server-option=<Option> angegeben wird, werden sie alle, wie in angegebenen Reihenfolge, an die andere Seite gesendet.
Unterdrückt das Abrufen (checkout) von HEAD, nachdem das Klonen fertig ist.
-Fail if the source repository is a shallow repository. The clone.rejectShallow configuration variable can be used to specify the default.
-Erstellt ein bare Git-Repository. D.h. anstatt ein <Directory> zu erstellen und die Verwaltungsdateien in <Directory>/.git abzulegen, wird aus dem <Directory> selbst das $GIT_DIR. Dies impliziert offensichtlich --no-checkout, weil es nirgendwo eine Möglichkeit gibt, das Arbeitsbereich auszuchecken. Auch die Branch-Heads auf der Remote-Seite werden direkt auf die entsprechenden lokalen Branch-Heads kopiert, ohne sie auf refs/remotes/origin/ abzubilden. Wenn diese Option verwendet wird, werden weder Remote-Tracking-Branches noch die zugehörigen Konfigurationsvariablen erstellt.
Employ a sparse-checkout, with only files in the toplevel directory initially being present. The git-sparse-checkout[1] command can be used to grow the working directory as needed.
-Verwendet die Funktion des partiellen Klonens und fordert den Server auf, eine Teilmenge der verfügbaren Objekte, entsprechend einem vorgegebenen Objektfilter, zu senden. Bei der Verwendung von --filter wird die mit angegebene <filter-spec> für den partiellen Klon-Filter verwendet. Zum Beispiel wird --filter=blob:none alle Blobs (Dateiinhalte) herausfiltern, bis sie von Git benötigt werden. Außerdem wird --filter=blob:limit=<size> alle BLOBs herausfiltern, die mindestens die Größe <size> haben. Weitere Details zu den Filterspezifikationen finden Sie unter der Option --filter in git-rev-list[1].
Also apply the partial clone filter to any submodules in the repository. Requires --filter and --recurse-submodules. This can be turned on by default by setting the clone.filterSubmodules config option.
Erstellt einen Spiegel des Quell-Repositorys. Das enthält auch --bare. Im Vergleich zu --bare bildet --mirror nicht nur lokale Branches der Quelle auf lokale Branches des Ziel-Repositorys ab, sondern bildet auch alle Refs ab (einschließlich der Remote-Tracking-Branches, Notizen usw.). Es richtet eine refspec-Konfiguration ein, sodass alle diese Refs durch ein git remote update im Ziel-Repository überschrieben werden können.
Verwendet den Namen <Name> statt origin zum Tracken der Änderungen des Upstream-Repository. Überschreibt clone.defaultRemoteName aus der Konfiguration.
Anstatt dass der neu erstellte HEAD auf den Branch zeigt, auf den der HEAD des geklonten Repositorys zeigt, verweist er stattdessen auf den Branch <Name>. In einem „non-bare“ Repository ist dies der Branch, der ausgecheckt wird. --branch kann auch Tags übernehmen und HEAD im resultierenden Repository von diesem Commit abtrennen.
Wurde diese Option angegeben und der Zugriff auf das zu klonende Repository erfolgt über SSH, so wird damit ein Nicht-Standardpfad für den Befehlsaufruf am anderen Ende angegeben.
-Bestimmt das Verzeichnis, aus dem Templates ausgelesen werden sollen; (Siehe den Abschnitt "TEMPLATE DIRECTORY" in git-init[1].)
-Setzt eine Konfigurations-Variable im neu angelegten Repository; die sofort nach der Initialisierung des Repositorys wirksam wird, noch bevor der Remote-Verlauf geholt oder irgendwelche Dateien ausgecheckt werden. Der Schlüssel hat das gleiche Format wie es von git-config[1] erwartet wird (z.B. core.eol=true). Wenn für den gleichen Schlüssel mehrere Werte angegeben werden, wird jeder Wert in die Konfigurationsdatei geschrieben. Auf diese Weise ist es z.B. möglich, zusätzliche Fetch-Referenzen zum Ursprungs-Remote hinzuzufügen.
Aufgrund von Einschränkungen der aktuellen Implementierung werden einige Konfigurations-Variablen erst nach dem initialen Fetchen und Checkout wirksam. Bekanntermaßen nicht wirksame Konfigurations-Variablen sind: remote.<Name>.mirror und remote.<Name>.tagOpt. Verwenden Sie stattdessen die entsprechenden Optionen ---mirror und --no-tags.
Erstellt einen „flachen“ Klon mit einem auf die angegebene Anzahl von Commits gekürzten Verlauf. Das impliziert --single-branch, es sei denn, es wird --no-single-branch angegeben, um den Verlauf nahe der Spitzen aller Branches zu fetchen. Wenn Submodule gekürzt geklont werden sollen, geben Sie zusätzlich --shallow-submodules an.
Erstellt einen „flachen“, gekürzten Klon mit einem Verlauf nach dem festgelegten Zeitpunkt.
-Erstellt einen flachen Klon mit einem Verlauf, der Commits ausschließt, die von einem angegebenen Remote-Branch oder Tag erreichbar sind. Diese Option kann mehrfach angegeben werden.
-Klont nur die Historie, die zur Spitze eines einzelnen Branchs gehört, entweder spezifiziert durch die --branch-Option oder den primären Branch auf den der Remote-HEAD zeigt. Nachfolgende Fetches in das resultierende Repository werden nur den Remote-Tracking-Branch für den Branch aktualisieren, auf dem diese Option für das anfängliche Klonen verwendet wurde. Wenn der HEAD des Remote-Repositorys auf keinen Branch zeigte, als mit --single-branch geklont wurde, wird kein Remote-Tracking-Branch erzeugt.
Klont keine Tags und setzt in der Konfiguration remote.<Remote>.tagOpt=--no-tags, um sicherzustellen, dass zukünftige git pull und git fetch Operationen keinen Tags folgen. Nachfolgende explizite Tag-Fetches werden trotzdem funktionieren (siehe git-fetch[1]).
Kann in Verbindung mit --single-branch verwendet werden, um einen Branch zu klonen und zu verwalten, der außer einem einzelnen geklonten Branch keine Referenzen enthält. Das ist z.B. nützlich, um minimale Klone des Standard-Branchs eines Repositorys für die Indexierung von Suchvorgängen zu erhalten.
Initialisiert und klont nach der Erstellung des Klons Submodule auf der Basis der angegebenen Pfadspezifikation. Wenn keine Pfadspezifikation angegeben wird, werden alle Submodule initialisiert und geklont. Diese Option kann für Pfadspezifikationen, die aus mehreren Einträgen bestehen, mehrfach angegeben werden. Der resultierende Klon hat submodule.active oder "." (d.h. alle Submodule) auf die angegebene Pfadspezifikation gesetzt, wenn keine Pfadspezifikation vorhanden ist.
Submodule werden mit ihren Standardeinstellungen initialisiert und geklont. Dies entspricht dem Ausführen von git submodule update --init --recursive <Pfadspezifikation> unmittelbar, nachdem der Klon beendet ist. Diese Option wird ignoriert, wenn das geklonte Repository keinen Arbeitsbereich/Checkout hat (d.h. wenn eine der Optionen --no-checkout/-n, --bare oder --mirror angegeben wurde)
Alle zu klonenden Submodule werden auf eine Tiefe von 1 gekürzt.
-Alle geklonten Submodule verwenden den Status der Remote-Tracking-Branch des Submoduls, um das Submodul zu aktualisieren, aber nicht den registrierten SHA-1 des Hauptprojekts. Das entspricht der Option von --remote mit dem Befehl git submodule update.
Verwendet das angegebene Verzeichnis als Speicherort für das geklonte Repository, anstatt das übliche Verzeichnis zu verwenden. Dann wird ein Dateisystem-unabhängiger, symbolischer Git-Link dorthin erstellt. Das führt dazu, dass das Git-Repository vom Arbeitsbereich getrennt werden kann.
-Anzahl der gleichzeitig abgerufenen Submodule. Standardmäßig wird die Option submodule.fetchJobs verwendet.
Bezeichnet das (möglicherweise externe) Repository, das geklont werden soll. Siehe unten den Abschnitt GIT URLS für weiterführende Informationen zum Bestimmen von Repositorys.
-Der Name eines neuen Verzeichnisses, in das geklont werden soll. Der „menschenfreundliche“ Teil des Quell-Repositorys wird verwendet, wenn kein Verzeichnis explizit angegeben wird (repo für /path/to/repo.git und foo für host.xz:foo/.git). Das Klonen in ein bestehendes Verzeichnis ist nur erlaubt, wenn das Verzeichnis leer ist.
Before fetching from the remote, fetch a bundle from the given <uri> and unbundle the data into the local repository. The refs in the bundle will be stored under the hidden refs/bundle/* namespace. This option is incompatible with --depth, --shallow-since, and --shallow-exclude.
In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.
-Git supports ssh, git, http, and https protocols (in addition, ftp and ftps can be used for fetching, but this is inefficient and deprecated; do not use them).
-Der native Transport (d.h. git:// URL) führt keine Authentifizierung durch und sollte in ungesicherten Netzwerken mit Vorsicht verwendet werden.
-Folgende Syntaxen können damit verwendet werden:
-ssh://[user@]host.xz[:port]/Pfad/zum/Repo.git/
-git://host.xz[:port]/Pfad/zum/Repo.git/
-http[s]://host.xz[:port]/Pfad/zum/Repo.git/
-ftp[s]://host.xz[:port]/Pfad/zum/Repo.git/
-Eine alternative, scp-ähnliche Syntax kann auch mit dem Protokoll SSH verwendet werden:
-[user@]host.xz:Pfad/zum/Repo.git/
-Diese Syntax wird nur erkannt, wenn vor dem ersten Doppelpunkt keine Schrägstriche stehen. Dadurch kann ein lokaler Pfad, der einen Doppelpunkt enthält, besser erkannt werden. Zum Beispiel könnte der lokale Pfad foo:bar als absoluter Pfad oder ./foo:bar angegeben werden, um zu vermeiden, dass er als SSH-URL fehlinterpretiert wird.
Die Protokolle SSH und GIT unterstützen zusätzlich die Erweiterung ~username:
-ssh://[user@]host.xz[:port]/~[user]/Pfad/zum/Repo.git/
-git://host.xz[:port]/~[user]/Pfad/zum/Repo.git/
-[user@]host.xz:/~[user]/Pfad/zum/Repo.git/
-Für lokale Repositorys, die von Git ebenfalls nativ unterstützt werden, können die folgenden Syntaxen verwendet werden:
-/Pfad/zum/Repo.git/
-file:///Pfad/zum/Repo.git/
-Diese beiden Syntaxen sind größtenteils äquivalent, außer dass die erstgenannte die Option --local beinhaltet.
-git clone, git fetch und git pull, aber nicht git push, akzeptieren auch eine geeignete Bundle-Datei. Siehe git-bundle[1].
-Wenn Git nicht versteht, wie ein bestimmtes Transportprotokoll zu verwenden ist, versucht es, das Remote-<Transport>-Hilfsprogramm zu benutzen, falls es eines gibt. Um ein Remote-Hilfsprogramm explizit anzufordern, kann die folgende Syntax verwendet werden:
-<Transport>::<Adresse>
-wobei <Adresse> ein Pfad, ein Server und Pfad oder eine beliebige URL-ähnliche Zeichenfolge sein kann, die von dem aufgerufenen, spezifischen Remote-Hilfsprogramm erkannt wird. Siehe gitremote-helpers[7] für weitere Details.
-Wenn es eine große Anzahl ähnlich benannter Remote-Repositorys gibt und Sie für diese ein anderes Format verwenden möchten (sodass die von Ihnen verwendeten URLs in funktionierende URLs umgeschrieben werden), kann ein Konfigurations-Abschnitt in dieser Form erstellt werden:
-[url "<actual-url-base>"] - insteadOf = <other-url-base>-
Beispielsweise mit folgendem:
-[url "git://git.host.xz/"] - insteadOf = host.xz:/Pfad/zu/ - insteadOf = work:-
eine URL wie "work:Repo.git" oder wie "host.xz:/fad/zu/Repo.git" wird in jedem Kontext umgeschrieben, der eine URL zu "git://git.host.xz/Repo.git" umwandelt.
-Wenn Sie URLs nur zum Pushen neu schreiben möchten, können Sie einen Konfiguration-Abschnitt in der folgenden Form erstellen:
-[url "<actual-url-base>"] - pushInsteadOf = <other-url-base>-
Beispielsweise mit folgendem:
-[url "ssh://example.org/"] - pushInsteadOf = git://example.org/-
eine URL wie „git://example.org/path/to/repo.git“ wird für Pushes in „ssh://example.org/path/to/repo.git“ umgeschrieben, aber Pulls verwenden weiterhin die Original-URL.
-Klonen eines Upstream-Repositorys:
-$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux -$ cd my-linux -$ make-
Erstellt einen lokalen Klon, der vom aktuellen Verzeichnis entlehnt wird, ohne die Daten auszuchecken:
-$ git clone -l -s -n . ../copy -$ cd ../copy -$ git show-branch-
Klonen eines Upstream-Repositorys wobei Objekte von einem lokalen Repository entlehnt werden:
-$ git clone --reference /git/linux.git \ - git://git.kernel.org/pub/scm/.../linux.git \ - my-linux -$ cd my-linux-
Erzeugt ein „leeres“ (bare) Repository um Ihre Änderungen zu veröffentlichen:
-$ git clone --bare -l /home/proj/.git /pub/scm/proj.git-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Teil der git[1] Suite
-git clone [--template=<template-directory>] - [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] - [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] - [--dissociate] [--separate-git-dir <git-dir>] - [--depth <depth>] [--[no-]single-branch] [--no-tags] - [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] - [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow] - [--filter=<filter> [--also-filter-submodules]] [--] <repository> - [<directory>]-
Einritar hirslu í nýtilbúna skrá, býr til greinar undir fjareftirliti fyrir hverja grein í einrituðu hirslunni (hægt að sjá með því að nota git branch --remotes (git grein fjarlægjur)), og býr til og útskráir upphafsgrein sem kvíslast frá viðkomandi virkri grein þeirrar hirslu sem verið er að einrita.
Eftir að einritunin hefur verið framkvæmd mun einfalt git fetch(git sækja) án breyta uppfæra allar greinar sem eru undir fjareftirliti, og git pull (git draga) án breyta mun auk þess steypa saman fjarlægu höfuðgreininni við viðeigandi höfuðgrein, ef einhver finnst (þetta á ekki við þegar "--single-branch" (ein grein) valmöguleikinn er gefinn; sjá fyrir neðan).
Þessi forstillta hegðun færst með því að skapa tilvísanir til hausa fjarlægu greinanna undir refs/remotes/origin (tilvísanir fjarlægjur uppruni) og með því að frumstilla stillingabreyturnar remote.origin.url(fjarlægja uppruni vefslóð) og remote.origin.fetch(fjarlægja uppruni sækja).
Þegar hirslan sem á að einrita er á staðbundinni vél leiðir þessi stilling hinn venjulega "Git aware" (git meðvitaður) flutningsmáta hjá sér og einritar hirsluna með því að gera afrit af HAUS og öllu sem er undir viðfangs- og tilvísanaskránum. Skjölin sem finnast undir .git/objects/(git viðföng) eru harðhlekkjuð til þess að spara pláss eftir því sem mögulegt er.
Ef hirslan er skilgreind sem sértæk slóð (t.d. /slóð/að/hirslu) þá er þetta forstillt hegðurn, og --local er í eðli sínu slæpi (ofaukið). Ef hirslan er skilgreind sem URL (vefslóð) þá er þessi valmöguleiki hunsaður (og staðbundnar fínstillingar eru aldrei notaðar). Að tiltaka --no-local (ekkert staðbundið) mun valda því að skipunin tekur ekki tillit til forstillinga þegar /slóð/að/hirslu er uppgefin, og nota hinn hefðbundna Git milliflutning í staðinn.
If the repository’s $GIT_DIR/objects has symbolic links or is a symbolic link, the clone will fail. This is a security measure to prevent the unintentional copying of files by dereferencing the symbolic links.
ATHUGIÐ: þessi aðgerð getur keppt við samhliða breytingar á upprunahirslunni, svipað og að framkvæma cp -r src dst`á sama tíma og `src er breytt.
Þvinga einitunarferli hirslu á staðbundnu skráakerfi til að afrita skjöl undir .git/objects(git viðföng) skránni í stað þess að nota harðhlekki. Þetta gæti verið æskilegt ef þú ert að reyna að taka varaafrit af hirslunni þinni.
Þegar hirslan sem á að einrita er á staðbundinni vél, setjið sjálfkrafa upp .git/objects/info/alternates(git viðföng upplýsingar staðgenglar) í stað þess að nota harðhlekki til að deila viðföngum með upptakahirslunni. Hirslan sem verður til byrjar án nokkurra eigin viðfanga.
ATHUGIÐ: þetta er mögulega hættuleg aðgerð; ekki nota
-hana nema þú vitir hvað hún gerir. Ef þú einritar hirsluna þína
-með þessum valmöguleika og eyðir síðan greinum (eða notar einhverja
-aðra Git skipun sem gerir það að verkum að tilvísanir í innlegg sem eru til hverfa) í
-upprunahirslunni, geta sum viðföng týnt tilvísunum sínum (þau lafa).
-Þessi viðföng er hægt að fjarlægja með venjulegum Git aðgerðum (svo sem git commit(git inlegg))
-sem sjálfkrafa kallar á git maintenance run --auto (git viðhald sjálfkrafa). (Sjá git-maintenance[1].)
-Ef þessi viðföng eru fjarlægð og hafa tilvísun í afrituðu hirslunni
-þá skrumskælist afritaða hirslan.
Athugaðu að nota skipunina git repack(git endurpakka) án --local (staðbundinn) valmöguleikans í hirslu sem hefur verið einrituð með --shared (deildur) mun afrita viðföng úr upptakahirslunni inn í pakka í einrituðu hirslunni og fjarlæga diskplássið sem sparaðist með clone --shared (einrita deildur). Það er hins vegar öruggt að nota git gc(garbace collection, git ruslasöfnun) sem notar --local(staðbundinn) valmöguleikann sem forstillingu.
Ef þú vilt rifta ákvæðatengslum hirslu við upptakahirsluna sem var einrituð með --shared(deildur) geturðu einfaldlega notað skipunina git repack -a(git endurpakka allt) til að afrita öll viðföng úr upptakahirslunni yfir í nýjan pakka í einrituðu hirslunni.
If the reference repository is on the local machine, automatically setup .git/objects/info/alternates to obtain objects from the reference repository. Using an already existing repository as an alternate will require fewer objects to be copied from the repository being cloned, reducing network and local storage costs. When using the --reference-if-able, a non existing directory is skipped with a warning instead of aborting the clone.
ATHUGASEMD: sjá ATHUGASEMD fyrir --shared(deildur) valmöguleikann, og einnig
---dissociate(aðskilja) valmöguleikann.
Þessi valmöguleiki gerir það að verkum að viðföng úr tilvísunarhirslum sem skilgreindar eru með --reference (tilvísun) valmöguleikanum eru fengin lánuð einungis til þess að minnka netkerfisflutning, og eftir að einrit hefur verið gert með því að búa til nauðsynleg staðbundin afrit af þeim viðföngum sem voru fengið lánuð fellur lánið úr gildi. Þennan valmöguleika er einnig hægt að nota þegar verið er að einrita staðbundið frá hirslu sem nú þegar fær viðföng lánuð úr annari hirslu—nýja hirslan mun fá lánuð viðföng úr sömu hirslu, þá er hægt að fella lánið úr gildi með honum.
Verka án frálags. Framvinda er ekki birt í stöðluðu villustreymi.
-Sýna ferlisupplýsingar. Hefur ekki áhrif á birtingu framvindustöðu í stöðluðu villustreymi.
-Staða framvindu er birt í stöðluðu villustreymi sem forstilling þegar það er tengt við útstöð, nema --quiet (án frálags) sé tilgreindur. Þessi valmöguleiki þvingar birtingu framvindustöðu jafnvel þó að staðlaða villustreyminu sé ekki beint í útstöð.
Senda viðkomandi textastreng til netþjónsins þegar samskiptin eru samkvæmt samskiptareglum af gerð 2. Viðkomandi strengur má ekki innihalda NUL (innihaldslaust) eða LF (línuskipta-) tákn. Meðferð netþjónsins á netþjónsvalmöguleikum, þar með talið óþekktum valmöguleikum, er undir vefþjóninum komin. Þegar margir --server-option=<valmöguleiki> (netþjónsvalmöguleikar) eru gefnir upp eru þeir sendir yfir í þeirri röð sem þeir koma fyrir í á skipanalínunni.
Endurupptaka HAUS er ekki framkvæmd eftir að einritið er fullgert.
-Misfarast ef upptakahirslan er grunn hirlsa. Hægt er að nota stillingabreytuna clone.rejectShallow til þess að tiltaka sjálfgefinn valmöguleika.
-Þessi valmöguleiki býr til nakta Git hirslu. Það er að segja, í stað þess að búa til <skrá> og setja stjórnunarskrárnar í <skrá>/git. gerir hann <skrá> sjálfa $GIT_DIR`skrána. Þetta felur augljóslega í sér `--no-checkout(engin endurupptaka) vegna þess að það er ekki neinn staður til þar sem hægt er að endurupptaka verktréð. Einnig eru greinahausarnir sem eru fjarlægir afritaðir beint yfir í samsvarandi staðbundna greinahausa, án þess að kortleggja þá í refs/remotes/origin/(tilvísanir fjarlægjur uppruni). Þegar þessi valmöguleiki er notaður eru hvorki búnar til greinarnar sem eru undir fjareftirliti né tilheyrandi stillingabreytur.
Employ a sparse-checkout, with only files in the toplevel directory initially being present. The git-sparse-checkout[1] command can be used to grow the working directory as needed.
-Nota möguleikann til hlutaeinritunar og mælast til þess að netþjónninn sendi undirsafn viðfanga sem hægt er að ná í samkvæmt ákveðinni viðfangasíu. Þegar --filter(sía) er uppgefið er <síutilgreining>`notuð til þess að sía hlutaeinritunina. Til dæmis `--filter=blob:none(sía slumma engin) mun sía út allar slummur (innihald skjals) þangað til Git þarf á þeim að halda. Einnig er hægt að nota --filter=blob:limit=<stærð>(sía slumma takmörk) til þess að sía út allar slummur af lágmarksstærð <stærð>. Fyrir meiri upplýsingar um tilgreiningar á síum, sjá --filter(sía) valmöguleikann í git-rev-list[1].
Also apply the partial clone filter to any submodules in the repository. Requires --filter and --recurse-submodules. This can be turned on by default by setting the clone.filterSubmodules config option.
Setja upp spegilmynd af upptakahirslunni. Þetta felur í sér --bare(nakinn). Í samanburði við --bare(nakinn) þá kortleggur --mirror (spegilmynd) ekki bara staðbundnar greinar upprunans yfir í staðbundnar greinar áfangastaðarins, heldur kortleggur allar tilvísanir (þar með taldar greinar sem eru undir fjareftirliti, athugasemdir, o.s.frv.) og setur up stillingar fyrir tilvísanatilgreiningar þannig að allar þessar tilvísanir verði yfirritaðar með git remote update(git fjarlægja uppfærsla) í áfangastaðarhirslunni.
Tiltakið <nafn> í staðinn fyrir að nota fjarlægjunafnið origin(uppruni) til þess að fylgjast með hirslunni í bakáttina. Ógildir clone.defaultRemoteName(einrita sjálfgefið fjarlægjunafn) úr stillingaskránni.
Í stað þess að benda hinum nýskapaða HAUS á sömu grein og HAUS hinnar einrituðu hirslu bendir á, gefur `<nafn>`upp nýja grein til að benda á. Í ónaktri hirslu þá er þetta greinin sem verður útskráð. Valmöguleikinn `--branch`getur einnig tekið merki og losar af HAUS í viðeigandi innleggi í þeirri hirslu sem verður til við aðgerðina.
-Þegar þessi valmöguleiki er uppgefinn, og aðgangur að hirslunni sem á að afrita er í gegn um ssh (secure shell, öryggisskel), þá skilgreinir hann óforstillta slóð fyrir skipunina sem framkvæmd er á hinum endanum.
-Skilgreina skrá þar sem sniðmót eru geymd (sjá "SNIÐMÁTSSKRÁ" hluta git-init[1].)
-Skilgreina stillingabreytu í hinni nýsköpuðu hirslu; þetta tekur gildi um leið og hirslan er frumstillt, en áður en að fjarlæg saga er sótt eða nein skjöl útskráð. Lykillin er með sama sniði og git-config[1] býst við (t.d. core.eol=true, kjarni línuending satt). Ef mörg gildi eru gefin fyrir sama lykil er hvert gildi skrifað í stillingaskrána. Þetta gerir það að verkum að til dæmis er öruggt að bæta við auka tilvísanatilgreiningum fyrir "sækja" í upprunafjarlægjuna.
Vegna takmarkana í þeirri útfærslu sem er í notkun byrja sumar stillingabreytur ekki að virka fyrr en eftir fyrsta "sækja" og "endurupptaka". Stillingabreytur sem vitað er að virka ekki eru: remote.<nafn>.mirror(fjarlæg spegilmynd) og remote.<nafn>.tagOpt(fjarlæg merki valfrjáls). Notaðu samsvarandi valmöguleika, --mirror(spegilmynd) og --no-tags(engin merki), í staðinn.
Búa til grunnt einrit með stytta sögu takmarkaða við uppgefinn fjölda innleggja. Felur í sér --single-branch (ein grein) nema --no-single-branch (ekki ein grein) sé gefið upp til þess að sækja sögu sem nær til enda allra greina. Ef þú vilt einrita undirverkeiningar grunnt, gefðu einnig upp --shallow-submodules (grunnar verkeiningar).
Búa til grunnt einrit með sögu eftir tilgreindan tíma.
-Búa til grunnt einrit með sögu, en útiloka innlegg sem hægt er að ná í frá tilgreindri fjargrein eða merki. Hægt er að nota þennan valmöguleika oft.
-Einungis einrita sögu sem nær til enda einnar greinar sem er annað hvort grein tilgreind með --branch(grein) valmöguleikanum eða er aðalgreinin sem HAUS fjarlægjunnar bendir á. Þegar "sækja" er notað aftur á hirsluna sem verður til eru einungis gerðar uppfærslur á greinina sem var undir fjareftirliti fyrir þá grein sem þessi valmöguleiki var notaður á í upprunalegri einritun. Ef HAUS og fjarlægja bentu ekki á neina grein þegar --single-branch(ein grein) einritið ver gert er engin grein undir fjareftirliti búin til.
Ekki einrita nein merki, og tilgreina`remote.<fjarlægja>.tagOpt=--no-tags`(fjarlægja merki valmöguleikar, engin merki) í stillingaskránni, sem gerir það að verkum að í framtíðinni munu git pull (git draga) og`git fetch` (git sækja) ekki elta nein merki. Sérstakar skilgreiningar á merkjum þegar "sækja" er notað eftir á munu samt virka (sjá git-fetch[1]).
Hægt er að nota þennan valmöguleika í samfloti við --single-branch (ein grein) til þess að einrita og viðhalda grein sem hefur engar tilvísanir aðrar en ein einrituð grein. Þetta er nytsamlegt t.d. til þess að viðhalda lágmarkseinritum af forstilltri grein í einhverri hirslu svo hægt sé að leita í henni eftir atriðaskrá.
Frumstilla og einrita undirverkeiningar innan einrits byggt á uppgefinni slóðartilgreiningu eftir að einritið hefur verið búið til. Ef engin slóðatilgreining er gefin upp eru allar undirverkeiningar frumstilltar og einritaðar. Hægt er að tilgreina þennan valmöguleika oftar en einu sinni fyrir slóðatilgreiningar sem innihalda fleiri en eina færslu. Einritið sem verður til fær`submodule.active`(undirverkeining virk) stillt á viðkomandi slóðatilgreiningu, eða "." (þ.e. allar verkeiningar) ef engin slóðatilgreining er gefin upp.
-Undirverkeiningar eru frumstilltar og einritaðar með sínum forstillingum. Þetta jafngildir því að nota git submodule update --init --recursive <slóðatilgreining> (git undirverkeining uppfæra frumstilla endurkvæmt) um leið og einritið er tilbúið. Þessi valmöguleiki er hunsaður er einritaða hirslan hefur ekki verktré/endurupptöku (þ.e. ef einver af valmöguleikunum --no-checkout/-n (engin endurupptaka), --bare (nakinn), eða --mirror(spegilmynd) eru gefnir upp)
Allar undirverkeiningar sem eru einritaðar munu verða grunnar með dýpt 1.
-Allar undirverkeiningar sem eru einritðaðar nota stöðu viðeigandi greinar undir fjareftirliti til þess að uppfæra undirverkeininguna, fremur en skráða SHA-1 öryggisundirskrift yfirverksins. Jafngildir því að gefa upp --remote(fjarlægja) með git submodule update (undirverkeining uppfæra).
Í stað þess að setja einrituðu hirsluna þar sem hún á að vera, setja hana í tilgreinda skrá, og búa síðan til Git hlekk þangað sem er ómeðvitaður um skráasafnið. Árangurinn verður sá að Git hirslan verður aðskilin verktrénu.
-Fjöldi undirverkeininga sem eru sóttar á sama tíma. Er forstillt samkvæmt submodule.fetchJobs (undirverkeining sæja verk) valmöguleikanum.
Hirslan (mögulega fjarlæg) til þess að einrita frá. Sjá GIT URLS (vefslóð) hlutann hér fyrir neðan fyrir frekari upplýsingar um það hvernig á að tilgreina hirslur.
-Nafn skrárinnar sem á að einrita í. Ef engin skrá er uppgefin er "mennsklegi" hluti upprunahirslunnar notaður (repo fyrir /path/to/repo.git og`foo` fyrir host.xz:foo/.git). Einungis er leyfilegt að einrita í skrá sem þegar er til ef hún er tóm.
Before fetching from the remote, fetch a bundle from the given <uri> and unbundle the data into the local repository. The refs in the bundle will be stored under the hidden refs/bundle/* namespace. This option is incompatible with --depth, --shallow-since, and --shallow-exclude.
In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.
-Git supports ssh, git, http, and https protocols (in addition, ftp and ftps can be used for fetching, but this is inefficient and deprecated; do not use them).
-Innbyggði milliflutningurinn (þ.e. git://VEFSLÓÐ) framkvæmir ekki neina sannvottun og ætti að notast með varúð í óöruggum netkerfum.
-Með samskiptareglunum er hægt að nota eftirfarandi samsetningareglur:
-ssh://[notandi@]hýsill.xz[:tengill]/slóð/til/hirsla.git/
-git://hýsill.xz[:tengill]/slóð/til/hirsla.git/
-http[s]://hýsill.xz[:tengill]/slóð/til/hirsla.git/
-ftp[s]://hýsill.xz[:tengill]/slóð/til/hirsla.git/
-Hægt er að nota aðrar SCP-líkar samsetningarreglur með SSH samskiptareglunum:
-[notandi@]hýsill.xz:slóð/til/hirsla.git/
-Þessar samsetningarreglur virka einungis ef það eru engin skástrik á undan fyrsta tvípunktinum. Þetta hjálpar til við að aðgreina staðbundna slóð sem inniheldur tvípunkt. Til dæmis er hægt að skilgreina staðbundnu slóðina foo:bar sem algilda slóð, eða ./foo:bar, til þess að forðast það að hún verði túlkuð sem SSH vefslóð.
Auk þess styðja SSH- og Git-samskiptareglurnar framlenginguna ~notandanafn:
-ssh://[notandi@]hýsill.xz[:tengill]/~[notandi]/slóð/til/hirsla.git/
-git://hýsill.xz[:tengill]/~[notandi]/slóð/til/hirsla.git/
-[notandi@]hýsill.xz:/~[notandi]/slóð/til/hirsla.git/
-Fyrir staðbundnar hirslur, sem Git hefur einnig innbyggðan stuðning fyrir, er hægt að nota eftirfarandi samsetninagrreglu:
-/slóð/til/hirsla.git/
-file:///slóð/til/hirsla.git/
-Þessar reglur eru að mestu jafngildar, nema að fyrri reglan felur í sér --local (staðbundinn) valmöguleikann.
-git clone (einrita), git fetch (sækja) og git pull (draga), but not git push (stjaka) samþykkja líka viðeigandi knippisskjal. Sjá git-bundle[1].
-Þegar Git veit ekki hvernig á að meðhöndla ákveðna flutningsreglu reynir það að nota remote-<flutningur> (fjarlægja) hjálpargagn, ef það er til. Til þess að biðja sértstaklega um fjarlægjuhjálpargagn er hægt að nota eftirfarandi samsetningarreglu:
-<flutningur>::<fang>
-þar sem <fang> getur verið slóð, netþjónn og slóð, eða einhver strengur líkur veffangi sem viðkomandi fjarlægjuhjálpargagn þekkir. Sjá gitremote-helpers[7] fyrir frekari upplýsingar.
-Ef um er að ræða mikinn fjölda fjarlægra hirsla með svipuð heiti og þú vilt nota annað snið fyrir þær (svo að vefslóðirnar sem þú notar verði endurskrifaðar yfir í vefslóðir sem virka) geturðu búið til stillingareiningu með:
-[url "<actual-url-base>"] - insteadOf = <other-url-base>-
Til dæmis, með þessu:
-[url "git://git.hýsill.xz/"] - insteadOf = hýsill.xz:/slóð/til/ - insteadOf = vinna:-
vefslóð eins og "vinna:hirsla.git" eða "hýsill.xz:/slóð/til/hirsla.git" verða endurskrifaðar í öllum samhengjum semtaka vefslóð til þess að vera "git://git.hýsill.xz/hirsla.git".
-Ef þú vilt endurskrifa vefslóðir einungis þegar þú stjakar, þá geturðu búið til stillingareiningu með sniðinu:
-[url "<actual-url-base>"] - pushInsteadOf = <other-url-base>-
Til dæmis, með þessu:
-[url "ssh://dæmi.org/"] - pushInsteadOf = git://dæmi.org/-
vefslóð eins og "git://dæmi.org/slóð/til/hirsla.git" verður endurskrifuð sem "ssh://dæmi.org/slóð/til/hirlsa.git" þegar þú stjakar, en upprunalega vefslóðin verður notuð þegar þú dregur.
-Einrita í bakátt:
-$ git clone git://git.kernel.org/pub/scm/.../linux.git mitt-línux -$ cd mitt-línux -$ make-
Búa til staðbundið einrit sem fær lánað úr núgildandi skrá, án þess að útskrá neitt:
-$ git clone -l -s -n . ../afrit -$ cd ../afrit -$ git show-branch-
Einrita í bakátt á meðan fengið er lánað frá staðbundinni skrá sem þegar er til:
-$ git clone --reference /git/linux.git \ - git://git.kernel.org/pub/scm/.../linux.git \ - mitt-línux -$ cd mitt-línux-
Búa til nakta hirslu til þess að birta breytingar þínar almenningi:
-$ git clone --bare -l /home/proj/.git /pub/scm/proj.git-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Hluti af git[1] fylkingunni
-git clone [--template=<テンプレートディレクトリ>] - [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] - [-o <名前>] [-b <名前>] [-u <アップロードするパック>] [--reference <リポジトリ>] - [--dissociate] [--separate-git-dir <gitディレクトリ>] - [--depth <深さ>] [--[no-]single-branch] [--no-tags] - [--recurse-submodules[=<パススペック>]] [--[no-]shallow-submodules] - [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow] - [--filter=<フィルタ> [--also-filter-submodules]] [--] <リポジトリ> - [<ディレクトリ>]-
リポジトリを新たに作成されたディレクトリにクローンし、クローンされたリポジトリの各ブランチにリモートトラッキングブランチを作成し（git branch --remotes で確認できます）、クローンされたリポジトリの現在アクティブなブランチからフォークされた初期ブランチを作成、チェックアウトします。
また、引数なしの git pull は、リモートのマスターブランチがあれば、それを現在のマスターブランチにマージします (これは "--single-branch" を指定した場合には当てはまりません。後述します)。
このデフォルトの構成は、リモートブランチヘッドへの参照を refs/remotes/origin の下に作成し、構成変数 remote.origin.url と remote.origin.fetch を初期化することで実現しています。
クローンを作成するリポジトリがローカルマシン上にある場合、このフラグは通常の「Git を意識した」転送メカニズムをバイパスして、HEAD と objects および refs ディレクトリ以下のすべてのコピーを作成してリポジトリをクローンします。.git/objects/ ディレクトリ以下のファイルは、可能な限りスペースを節約するためにハードリンクされます。
リポジトリがローカルパス（例: /path/to/repo）で指定されている場合は、これがデフォルトであり、--local は基本的に何もしません。リポジトリが URL として指定されている場合は、このフラグは無視されます（ローカルでの最適化も使用されません）。--no-local を指定すると、 /path/to/repo が指定されたときのデフォルトを上書きし、代わりに通常のGitトランスポートを使用します。
リポジトリの`$GIT_DIR/objects`がシンボリックリンクを含むか、またはシンボリックリンクである場合、クローンは失敗します。これは、シンボリックリンクの参照をたどることによるファイルの意図しないコピーを防ぐためのセキュリティ対策です。
-注意: この操作は、ソースリポジトリの同時変更と競合する可能性があります。この操作は、ソースリポジトリの同時変更と競合する可能性があります。これは、 src を変更しながら cp -r src dst を実行するのと同じです。src を変更しながら cp -r src dst を実行するのと同じように、この操作はソースリポジトリの同時変更と競合する可能性があります。
ローカルファイルシステム上のリポジトリからクローン作成プロセスを強制して、ハードリンクを使用するのではなく .git/objects ディレクトリの下にファイルをコピーします。これは、リポジトリのバックアップを作成する場合に適しています。
クローンを作成するリポジトリがローカルマシン上にある場合、ハードリンクを使用する代わりに、オブジェクトをソースリポジトリと共有するように .git/objects/info/alternates を自動的に設定します。結果のリポジトリは、独自のオブジェクトなしで開始されます。
注意: これは危険な操作になりうるため、理解できない限り使用 *しないで*ください。このオプションを使ってリポジトリをクローンし、ソースリポジトリでブランチを削除（あるいは既存のコミットを参照しなくなるようなGitコマンドを使用）すると、いくつかのオブジェクトが参照されなくなる (あるいはぶら下がる) ことがあります。これらのオブジェクトは、自動的に git maintenance run --auto を呼び出す通常のGit 操作 (たとえば git commit) で削除されるかもしれません。(参照git-maintenance[1].) もしこれらのオブジェクトが削除され、クローンリポジトリから参照されていた場合は、クローンリポジトリが壊れてしまいます。
なお、--shared でクローンされたリポジトリで git repack を --local オプションを指定せずに 実行すると、ソースリポジトリのオブジェクトがクローンされたリポジトリのパックにコピーされ、clone --shared によるディスクスペースの節約効果がなくなります。しかし、 --local オプションをデフォルトで使用する git gc を実行することは安全です。
--shared でクローンされたリポジトリのソースリポジトリへの依存関係を解消したい場合は、単純に git repack -a を実行して、ソースリポジトリのすべてのオブジェクトをクローンされたリポジトリのパックにコピーします。
参照リポジトリがローカルマシン上にある場合は、参照リポジトリからオブジェクトを取得するように .git/objects/info/alternates を自動的に設定します。既存のリポジトリを代替として使用すると、クローンを作成するリポジトリからコピーする必要のあるオブジェクトが少なくなり、ネットワークとローカルのストレージコストが削減されます。 --reference-if-able を使用すると、クローンを中止する代わりに、存在しないディレクトリがスキップされ、警告が表示されます。
注意: --shared オプションの 注意 を参照してください。また、--dissociate オプションも参照してください。
ネットワーク転送を減らすために、--reference オプションで指定された参照リポジトリからオブジェクトを借用し、借用したオブジェクトの必要なローカルコピーを作成してクローンを作成した後に、借用を停止します。このオプションは、すでに他のリポジトリからオブジェクトを借用しているリポジトリからローカルにクローンを作成する場合にも使用できます。新しいリポジトリは同じリポジトリからオブジェクトを借用しますが、このオプションを使用して借用を停止することができます。
静かに動作します。 進行状況は標準エラーストリームに報告されません。
-冗長に実行します。標準エラーストリームへの進行状況の報告には影響しません。
-標準エラーストリームがターミナルに接続されている場合、--quiet が指定されていない限り、進捗状況はデフォルトで標準エラーストリームに報告されます。このフラグは、標準エラーストリームがターミナルに向けられていない場合でも、進行状況を強制的に報告します。
プロトコルバージョン2を使用して通信するときに、指定された文字列をサーバーに送信します。指定された文字列には、NUL または LF 文字を含めることはできません。不明なオプションを含むサーバーオプションのサーバーの処理は、サーバー固有です。複数の --server-option=<オプション> が指定されている場合、それらはすべてコマンドラインにリストされている順序で反対側に送信されます。
クローンの完了後、HEAD のチェックアウトは行われません。
-ソースリポジトリがシャローリポジトリの場合は失敗します。clone.rejectShallow 設定変数でデフォルトを指定することができます。
-「ベア」Git リポジトリを作成します。つまり、<ディレクトリ> を作成して管理用のファイルを <ディレクトリ>/.git に置くのではなく、<ディレクトリ> 自体を $GIT_DIR にするのです。これは明らかに、作業ツリーをチェックアウトする場所がないため、--no-checkout を意味します。また、リモートのブランチヘッドは、refs/remotes/origin/ にマッピングされることなく、対応するローカルのブランチヘッドに直接コピーされます。このオプションを使用すると、リモートトラッキングブランチも関連する設定変数も作成されません。
sparse-checkout を採用し、最初にトップレベル・ディレクトリのファイルのみが存在するようにします。git-sparse-checkout[1] コマンドを使うと、必要に応じて作業ディレクトリを増やすことができます。
-パーシャルクローン機能を使って、与えられたオブジェクト・フィルタにしたがって、到達可能なオブジェクトのサブセットを送るようにサーバに要求します。--filter を使う場合、パーシャルクローンのフィルタには、与えられた <フィルタ仕様> が使われます。たとえば、 --filter=blob:none とすると、Gitが必要とするまで、すべてのblob（ファイルの内容）をフィルタリングします。また、 --filter=blob:limit=<サイズ> とすると、少なくとも <サイズ> 以上のサイズのblobをすべてフィルタリングします。フィルターの仕様についての詳細は、 git-rev-list[1] の --filter オプションを参照してください。
また、リポジトリ内の任意のサブモジュールにパーシャルクローンフィルタを適用します。--filter と --recurse-submodules が必要です。これは、 clone.filterSubmodules 設定オプションで、デフォルトで有効にすることができます。
Set up a mirror of the source repository. This implies --bare. Compared to --bare, --mirror not only maps local branches of the source to local branches of the target, it maps all refs (including remote-tracking branches, notes etc.) and sets up a refspec configuration such that all these refs are overwritten by a git remote update in the target repository.
上流のリポジトリを追跡するためにリモート名 origin を使用する代わりに、 <名前> を使用します。コンフィグの clone.defaultRemoteName をオーバーライドします。
新しく作成された HEAD を、クローンされたリポジトリの HEAD が指すブランチに向けるのではなく、代わりに <名前> ブランチを指します。ベアリポジトリでない場合は、このブランチがチェックアウトされます。また、--branch はタグを取ることができ、できあがったリポジトリのそのコミットの HEAD をデタッチします。
指定された場合、クローンを作成するリポジトリにssh経由でアクセスすると、相手側で実行するコマンドのデフォルト以外のパスを指定します。
-テンプレートを使用するディレクトリを指定します。(git-init[1]の "TEMPLATE DIRECTORY "セクションを参照)
-新しく作成されたリポジトリに設定変数を指定します。これは、リポジトリが初期化された直後で、リモートの履歴が取得されたり、ファイルがチェックアウトされたりする前に有効になります。キーは git-config[1] で期待されるのものと同じ形式です (例: core.eol=true)。同じキーに複数の値が与えられた場合は、それぞれの値が設定ファイルに書き込まれます。これにより、たとえばオリジンのリモートに追加のフェッチrefspecを追加しても安全になります。
現在の実装の制限により、一部の設定変数は最初のフェッチとチェックアウトが終わるまで有効になりません。反映されない設定変数には次のようなものがあります。 remote.<名前>.mirror と remote.<名前>.tagOpt です。代わりに、対応する --mirror と --no-tags オプションを使用してください。
指定された数のコミットに切り詰められたヒストリーを持つ、「浅い」クローンを作成します。 --no-single-branch が指定されていない限り、--single-branch を意味し、すべてのブランチの先端付近の履歴を取得します。サブモジュールを浅くクローンしたい場合には、--shallow-submodules も指定してください。
指定した日時以降の履歴を持つシャロークローンを作成します。
-指定したリモートブランチやタグから到達可能なコミットを除いた、履歴付きのシャロークローンを作成します。このオプションは複数回指定できます。
---branch オプションで指定されたブランチ、またはリモートの HEAD が指し示すプライマリブランチの先端に至るまでの履歴のみをクローンします。結果として得られるリポジトリをさらにフェッチすると、最初のクローン作成時にこのオプションが使用されたブランチのリモートトラッキングブランチのみが更新されます。--single-branch クローンを作成したときに、リモートの HEAD がどのブランチも指していなかった場合は、リモートトラッキングブランチは作成されません。
タグをクローンせず、コンフィグで remote.<リモート>.tagOpt=--no-tags と指定することで、今後の git pull や git fetch の操作でタグを追いかけることができなくなります。その後、明示的にタグを取得しても動作します（git-fetch[1] を参照）。
--single-branch と一緒に使うことで、クローンされた単一のブランチ以外の参照を持たないブランチをクローンして維持することができます。これは、例えば、あるリポジトリのデフォルトブランチの最小限のクローンを維持して、検索インデックスを作成するのに便利です。
クローンが作成されると、与えられたpathspecに基づいて、その中のサブモジュールを初期化し、クローンを作成します。pathspecが指定されていない場合は、すべてのサブモジュールが初期化され、クローンが作成されます。このオプションは、複数のエントリからなる pathspec に対して複数回指定できます。できあがったクローンは、submodule.active に与えられた pathspec が、あるいは "." (すべてのサブモジュールを意味する)が pathspec が与えられなかった場合に設定されます。
サブモジュールは初期化され、デフォルトの設定でクローンされます。これは、クローンが終了した直後に、git submodule update --init --recursive <パススペック> を実行するのと同じです。このオプションは、クローンされるリポジトリに worktree/checkout がない場合(つまり、--no-checkout / -n、 --bare、 --mirror のいずれかが与えられた場合)には無視されます
複製されたすべてのサブモジュールは、深さが1の浅いものになります。
-クローンされたすべてのサブモジュールは、サブモジュールを更新する際に、親プロジェクトで記録された SHA-1 ではなく、サブモジュールのリモート追跡ブランチの状態を使用します。 git submodule update に --remote を渡すのと同じです。
クローンリポジトリを本来あるべき場所に置くのではなく、クローンリポジトリを指定したディレクトリに置き、そこにファイルシステムに依存しないGitシンボリックリンクを作成します。その結果、Gitリポジトリを作業ツリーから切り離すことができるようになります。
-リポジトリの参照ストレージフォーマットを指定します。有効な値は:
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
同時に取得するサブモジュールの数です。既定値は submodule.fetchJobs オプションになります。
クローンを作成するリポジトリ（リモートの場合もあります）。リポジトリの指定についての詳細は、後の GIT URLS セクションを参照してください。
-クローンを作成する新しいディレクトリの名前です。ディレクトリが明示的に指定されていない場合は、ソースリポジトリの "humanish" の部分が使用されます（/path/to/repo.git の場合は repo 、host.xz:foo/.git の場合は foo となります）。既存のディレクトリへのクローン作成は、そのディレクトリが空の場合のみ可能です。
リモートからフェッチする前に、指定された <uri> からバンドルをフェッチし、そのデータをローカルリポジトリに展開します。バンドル内の参照は、隠された refs/bundle/*`名前空間の下に格納されます。このオプションは `--depth、--shallow-since、`--shallow-exclude`と互換性がありません。
一般的に、URLにはトランスポートプロトコル、リモートサーバーのアドレス、リポジトリへのパスなどの情報が含まれています。トランスポートプロトコルによっては、これらの情報の一部が含まれていない場合があります。
-Gitは、ssh、git、http、httpsのプロトコルをサポートしています（さらに、ftp、ftpsもフェッチに使用できますが、これらは効率が悪く、非推奨ですので使用しないでください）。
-ネイティブトランスポート (つまり git:// URL) は認証を行わないので、セキュリティのないネットワークでは注意が必要です。
-以下の構文を使用することができます。
-ssh://[user@]host.xz[:port]/path/to/repo.git/
-git://host.xz[:port]/path/to/repo.git/
-http[s]://host.xz[:port]/path/to/repo.git/
-ftp[s]://host.xz[:port]/path/to/repo.git/
-scpのような別の構文をsshプロトコルで使用することもできます。
-[user@]host.xz:path/to/repo.git/
-この構文は、最初のコロンより前にスラッシュがない場合にのみ認識されます。これにより、コロンを含むローカルパスを区別することができます。例えば、ローカルパス foo:bar を絶対パスまたは ./foo:bar として指定することで、ssh の url と誤認されるのを防ぐことができます。
sshおよびgitプロトコルでは、さらに ~username の展開がサポートされています。
-ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
-git://host.xz[:port]/~[user]/path/to/repo.git/
-[user@]host.xz:/~[user]/path/to/repo.git/
-Gitがネイティブにサポートしているローカルリポジトリについては、次のような構文を使用できます。
-/path/to/repo.git/
-file:///path/to/repo.git/
-この2つの構文はほとんど同じですが、前者は --local オプションを必要とします。
-git clone、git fetch、'git pull’は、適切なバンドルファイルを受け取ることができ、'git push’はできません。git-bundle[1]を参照してください。
-Git が特定のトランスポート・プロトコルの扱い方を知らない場合は、remote-<トランスポート> リモート・ヘルパーがあればそれを使おうとします。リモートヘルパーを明示的に要求するには、次のような構文を使います。
-<トランスポート>::<アドレス>
-ここで <アドレス> には、パス、サーバーとパス、あるいは起動するリモートヘルパーが認識する任意の URL ライクな文字列を指定します。詳細は gitremote-helpers[7] を参照してください。
-似たような名前のリモートリポジトリが多数あり、それらに異なるフォーマットを使用したい場合（使用するURLが機能的なURLに書き換えられるような場合）、フォームに設定セクションを作成することができます。
-[url "<実際のURLベース>"] - insteadOf = <他のURLベース>-
例えば、このようになります。
-[url "git://git.host.xz/"] - insteadOf = host.xz:/path/to/ - insteadOf = work:-
"work:repo.git" や "host.xz:/path/to/repo.git" のような URL は、URLが "git://git.host.xz/repo" になるコンテキストで書き換えられます。
-プッシュのみでURLを書き換えたい場合は、フォームに設定項目を作ります。
-[url "<実際のURLベース>"] - pushInsteadOf = <他のURLベース>-
例えば、このようになります。
-[url "ssh://example.org/"] - pushInsteadOf = git://example.org/-
"git://example.org/path/to/repo.git" のようなURLは、プッシュの際に "ssh://example.org/path/to/repo.git" に書き換えられますが、プルの際には元の URL が使われたままになります。
-上流からのクローン:
-$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux -$ cd my-linux -$ make-
チェックアウトせずに、現在のディレクトリから借用するローカルクローンを作成する:
-$ git clone -l -s -n . ../copy -$ cd ../copy -$ git show-branch-
既存のローカルディレクトリから借用しながら、上流からクローンを作成する:
-$ git clone --reference /git/linux.git \ - git://git.kernel.org/pub/scm/.../linux.git \ - my-linux -$ cd my-linux-
変更した内容を公開するためにベア・リポジトリを作成する:
-$ git clone --bare -l /home/proj/.git /pub/scm/proj.git-
このセクションのこの行以下は、 git-config[1] のドキュメントから抜粋して含まれています。内容は同ドキュメントにあるものと同じです:
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Part of the git[1] suite
-git clone [--template=<diretório-modelo>] - [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] - [-o <nome>] [-b <nome>] [-u <upload-pack>] [--reference <repositório>] - [--dissociate] [--separate-git-dir <dir-git>] - [--depth <profundidade>] [--[no-]single-branch] [--no-tags] - [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] - [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow] - [--filter=<filtro>] [--also-filter-submodules]] [--] <repositório> - [<diretório>]-
Clona um repositório em um diretório recém-criado, cria o monitoramento remoto dos ramos para cada ramo no repositório clonado (visível utilizando git branch --remotes), cria e verifica um ramo inicial que é bifurcado do ramo ativo atualmente do repositório clonado .
Após a clonagem, um simples git fetch sem argumentos atualizará todas os ramos remotos e um git pull sem argumentos irá além disso, fará a mesclagem do ramo master (mestre) remoto no ramo atual caso haja (isso não se torna verdadeiro quando "--single-branch" é utilizado; veja abaixo).
Esta configuração predefinida é obtida através da criação de referências nos cabeçalhos das ramificações remotas em refs/remotos/origem e inicializando as variáveis de configuração remote.origin.url e remote.origin.fetch.
Quando o repositório que será clonada está numa máquina local, esta opção ignora o mecanismo de transporte "compatível com Git" normal e clona o repositório fazendo uma cópia do HEAD e tudo sob os diretórios dos objetos e das refs. Os arquivos sob o diretório .git / objects / são vinculados para economizar espaço sempre que possível.
É predefinido que caso o repositório seja definido como um caminho local (/path/to/repo por exemplo) e a opção --local não seja operacional. Caso o repositório seja definido como uma URL, então a opção será ignorada (e as otimizações locais nunca serão utilizadas). Utilizando a opção --no-local irá sobrescrever o valor predefinido quando /path/to/repo for informado em vez de utilizar o transporte regular do Git.
Se o repositório $GIT_DIR/objects tiver links simbólicos ou for um link simbólico, a clonagem falhará. Esta é uma medida de segurança para evitar uma cópia não intencional dos arquivos, removendo a referência dos links simbólicos.
OBSERVAÇÃO: esta operação pode competir com as alterações concomitantes ao código fonte no repositório, semelhante ao executar cp -r src dst enquanto altera o "src".
Impõem o processo de clonagem a partir de um repositório num sistema de arquivos local para copiar os arquivos no diretório .git/objects em vez de utilizar links físicos. Pode ser desejável caso esteja tentando fazer um backup do seu repositório.
Quando o repositório que será clonado estiver na máquina local, em vez de utilizar links físicos, configure automaticamente o .git/objetos/info/alternates para compartilhar os objetos com o repositório da origem. O repositório resultante é iniciado sem nenhum objeto próprio.
OBSERVAÇÃO: provavelmente está uma operação muito perigosa; não utilize a menos que compreenda o que ela faz. Caso clone o seu repositório utilizando esta opção e em seguida exclua os ramos (ou use qualquer outro comando Git que faz qualquer commit existente perder a referência) no repositório da origem, alguns objetos podem perder a referência (ou ficarem soltos). Estes objetos podem ser removidos através das operações normais do Git (como git commit) que chama automaticamente o comando git-maintenance run --auto. (Consulte git-maintenance[1].) Caso estes objetos sejam removidos e foram referenciados pelo repositório clonado, o repositório clonado se tornará corrompido.
Observe que executar o comando git repack sem a opção --local em um repositório clonado com --shared, este irá copiar os objetos do repositório da origem em um pacote no repositório que foi clonado, removendo a economia de espaço em disco do clone --shared. É seguro, no entanto, executar o comando git gc, que por predefinição utiliza a opção --local.
Caso queira quebrar a dependência de um repositório clonado com --shared no seu repositório de origem, você pode simplesmente executar o comando git repack -a para copiar todos os objetos do repositório de origem em um pacote dentro do repositório clonado.
Caso o repositório de referência estiver na máquina local, configure automaticamente o arquivo de configuração .git/objects/info/alternates para obter os objetos do repositório de referência. A utilização de um repositório já existente como alternativa, exigirá que menos objetos sejam copiados do repositório que está sendo clonado, reduzindo as despesas do armazenamento local e da rede. Ao utilizar o comando --reference-if-able, um diretório não existente é ignorado com um aviso em vez de interromper a clonagem.
OBSERVAÇÃO: consulte a OBSERVAÇÃO para a opção --shared e também para a opção --dissociate.
Emprestar os objetos dos repositórios a partir da referência utilizada com as opções --reference apenas para reduzir a transferência de rede e parar de tomar emprestado deles após a clonagem, fazendo cópias locais necessárias dos objetos emprestados. Esta opção também pode ser usada na clonagem local a partir de um repositório que já toma emprestado os objetos de um outro repositório—o novo repositório pegará emprestado os objetos do mesmo repositório, e esta opção pode ser usada para interromper o empréstimo.
Operate quietly. O progresso não é relatado para o fluxo de erro predefinido.
-Executa em modo loquaz. Não afera o relatório da condição geral do progresso para o fluxo de erro padrão.
-A condição do progresso é relatado no padrão do fluxo de erro por padrão quando ele é anexado em um terminal, a menos que --quiet seja utilizado. Esta sinalização impõe a condição geral de progresso mesmo que o fluxo de erro predefinido não seja direcionado para um terminal.
Transmita a sequência usada para o servidor ao se comunicar utilizando o protocolo versão 2. A sequência informada não deve conter um caractere NUL ou LF. O tratamento das opções do servidor, incluindo os desconhecidos, é específico do servidor. Quando a opção --server-option=<opção> forem utilizadas várias vezes, todos serão enviados para o outro lado na ordem listada na linha de comando.
Nenhum checkout de HEAD é executado após o clone estar completo.
-Falha caso o repositório de fontes for um repositório superficial. A variável de configuração clone.rejectShallow pode ser usada para definir o padrão.
-Faça um repositório Git vazio. Ou seja, em vez de criar o <diretório> e colocar os arquivos administrativos dentro do <diretório>/.git, faça com que o próprio <diretório> seja o $GIT_DIR. Por questões óbvias, há a obrigatoriedade da utilização da opção --no-checkout porque não há onde averiguar a árvore de trabalho. Além disso os cabeçalhos do ramo remoto são copiados diretamente para os cabeçalhos locais correspondentes, sem mapeá-los para refs/remotes/origin/. Quando essa opção é utilizada, nem as ramificações monitoradas remotamente tão pouco as variáveis de configuração relacionadas à elas são criadas.
Empregue a averiguação esparsa (sparse-checkout), apenas nos arquivos inicialmente presentes no diretório do primeiro nível. O comando git-sparse-checkout[1] para aumentar o diretório de trabalho sempre que for necessário.
-Utilize o recurso parcial de clonagem e solicite que o servidor envie um subconjunto de objetos acessíveis de acordo com determinados filtros do objeto. Ao utilizar a opção --filter, o <filter-spec> fornecido é usado para o filtro de clonagem parcial. Como, por exemplo, a opção --filter=blob:none irá filtrar todas as bolhas (conteúdo dos arquivos) até que sejam requisitados pelo Git. A opção --filter=blob:limit=<tamanho> também filtrará todas as bolhas com o tamanho de pelo menos <tamanho>. Para mais detalhes sobre as especificações dos filtros, consulte a opção --filter no git-rev-list[1].
Aplique também o filtro clone parcial a quaisquer submódulos no repositório. Requer a opção --filter e --recurse-submodules. Isso pode ser ativado por padrão, ao definir a opção de configuração clone.filterSubmodules.
Configure um espelho do repositório de origem. Implica no uso da opção --bare. Comparado com a opção --bare, --mirror não apenas mapeia as ramificações locais da origem para as ramificações locais do destino, ele mapeia todas as refs (incluindo as ramificações monitoradas remotamente, anotações, etc.) e define uma configuração refspec onde todas estas refs sejam substituídas através um git remote update no repositório do destino.
Em vez de utilizar o nome remoto origin para acompanhar o repositório "upstream" utilize o <nome> `. Sobrescreve o arquivo `clone.defaultRemoteName a partir da configuração.
Em vez de apontar o recém-criado HEAD para um ramo apontado pelo HEAD do repositório clonado, em vez disso, aponte para o ramo <nome>. Em um repositório não vazio, esse é o ramo que será averiguado. A opção --branch também pode pegar as tags e desanexar o HEAD daquele commit no repositório resultante.
Quando informado e o repositório a ser clonado for acessível através do ssh, determina que seja executado um caminho fora do padrão na outra extremidade.
-Informe o diretório de onde os modelos serão utilizados; (Consulte a seção "DIRETÓRIO MODELO" do git-init[1].)
-Define uma variável de configuração no repositório recém-criado; isso entra em vigor imediatamente após a inicialização do repositório, antes da captura remota do histórico ou da averiguação de quaisquer arquivos. Como é esperado, a chave está no mesmo formato de git-config[1] (ou seja, core.eol=true). Caso vários valores sejam informados para a mesma chave, cada valor será gravado no arquivo de configuração. Isso o torna mais seguro para incluir "fetch refspecs" adicionais ao "origin" remoto por exemplo.
Devido as limitações da implementação atual, algumas variáveis de configuração não entram em vigor até o próximo "fetch" e "checkout". As variáveis de configuração que são conhecidas por não terem efeito são: remote.<nome>.mirror and remote.<nome>.tagOpt. Em vez disso, utilize as opções correspondentes --mirror e --no-tags.
Crie um clone raso com um histórico truncado para uma quantidade determinada de revisões. Implica no uso da opção --single-branch a menos que --no-single-branch seja utilizado para resgatar os históricos próximos às pontas de todos os ramos. Caso queira clonar os submódulos superficialmente, utilize também --shallow-submodules.
Crie um clone superficial com um histórico após o tempo especificado.
-Crie um clone superficial com um histórico, excluindo os commits acessíveis a partir de um ramo remoto ou tag específica. Esta opção pode ser utilizada várias vezes.
-Clone apenas o histórico que leva à ponta de uma única ramificação, usada pela opção --branch ou pelo ramo primário remoto onde HEAD aponta. As outras capturas feitas no repositório resultante, atualizarão apenas as ramificações monitoradas remotamente onde esta opção foi utilizada para a clonagem inicial. Caso o HEAD remoto não aponte para nenhuma ramificação quando o clone --single-branch foi feito, nenhuma ramificação de rastreamento remoto é criado.
Não clone nenhuma tag e defina remote.<remoto>.tagOpt=--no-tags na configuração, garantindo que futuras operações do comando git pull e do comando git fetch não sigam nenhuma tag. As buscas explícitas subsequentes das tags ainda funcionarão (consulte git-fetch[1]).
Pode ser utilizado em conjunto com o --single-branch para clonar e manter um ramo sem referências além de um único ramo clonado. É útil para manter uma quantidade mínima dos clones do ramo predefinido de algum repositório para a indexação da pesquisa por exemplo.
Depois que o clone é criado, inicialize e clone os submódulos com base no pathspec informado. Caso nenhum pathspec seja informado, todos serão inicializados e clonados. Esta opção pode ser utilizada várias vezes para a consulta de diversas entradas pathspec. O clone resultante de submodule.active define o pathspec informado ou "." (significa todos os submódulos) caso nenhum pathspec seja provido.
Os submódulos são inicializados e clonados utilizando as suas respectivas configurações predefinidas. Este é o equivalente a executar o comando git submodule update --init --recursive <pathspec> imediatamente após que a clonagem for finalizada. Esta opção é ignorada caso o repositório clonado não tenha uma árvore de trabalho/verificação (ou seja quaisquer dos comandos --no-checkout/-n, --bare, ou --mirror seja utilizado)
Todos os submódulos clonados serão rasos e com uma profundidade 1.
-Todos os submódulos que forem clonados, para realizar a atualização os submódulos usarão a condição remota do ramo do submódulo de rastreamento em vez do SHA-1 registrado no superprojeto. Equivale encaminhar --remote para git submodule update.
Em vez de colocar o repositório clonado onde deveria estar, coloque o repositório clonado no diretório especificado e em seguida, faça um link simbólico Git independente do sistema de arquivos para lá. O resultado é que o repositório Git pode ser separado da árvore de trabalho.
-Define o formato de armazenamento de referência fornecido para o repositório. Os valores válidos são:
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
A quantidade de submódulos que foram recuperados ao mesmo tempo. A predefinição retorna para a opção submodule.fetchJobs.
Os repositórios que serão clonados (possivelmente remotos). Consulte a seção GIT URLS abaixo para mais informações sobre as especificidades dos repositórios.
-O nome de um novo diretório que será clonado. A parte "humanística" do repositório de origem é utilizada caso nenhum diretório seja explicitamente informado (repo para /path/to/repo.git e foo para host.xz:foo/.git). A clonagem num diretório existente é permitida apenas caso o diretório esteja vazio.
Antes de fazer a busca remota, obtenha um pacote da <uri> fornecida e desfaça os dados no repositório local. As refs no pacote serão armazenadas sob o nome oculto refs/bundle/*. Esta opção é incompatível com --depth, --shallow-since e --shallow-exclude.
Em geral as URLs contêm informações sobre o protocolo de transporte, o endereço do servidor remoto e o caminho para o repositório. Dependendo do protocolo de transporte, algumas dessas informações podem estar ausentes.
-O Git suporta os protocolos ssh, git, http e https (além do ftp e ftps podem ser utilizados para captura (feching), porém é ineficiente e obsoleto; não os utilize).
-O transporte nativo (ou seja, git:// URL) não faz a autenticação e deve ser utilizado com cuidado em redes sem segurança.
-As seguintes sintaxes podem ser utilizadas com eles:
-ssh://[user@]host.xz[:port]/caminho/para/o/repositório.git/
-git://host.xz[:port]/caminho/para/o/repositório.git/
-http[s]://host.xz[:port]/caminho/para/o/repositório.git/
-ftp[s]://host.xz[:port]/caminho/para/o/repositório.git/
-Uma sintaxe alternativa como scp também pode ser utilizada com o protocolo ssh:
-[user@]host.xz:caminho/para/o/repositório.git/
-Essa sintaxe apenas é reconhecida caso não haja barras antes dos primeiros dois pontos. Isso ajuda a diferenciar um caminho local que contém dois pontos. Por exemplo, o caminho local foo:bar pode ser utilizado como um caminho absoluto ou ./foo:bar para evitar ser mal interpretado como uma url ssh.
Os protocolos ssh e git também oferecem suporte à expansão do ~nome do usuário:
-ssh://[user@]host.xz[:port]/~[user]/caminho/para/o/repositório.git/
-git://host.xz[:port]/~[user]/caminho/para/o/repositório.git/
-[user@]host.xz:/~[user]/caminho/para/o/repositório.git/
-Para os repositórios locais, as seguintes sintaxes podem ser utilizadas que também são compatíveis de forma nativa pelo Git:
-/caminho/para/o/repositório.git/
-file:///caminho/para/o/repositório.git/
-Essas duas sintaxes são basicamente equivalentes, exceto que a primeira implica no uso da opção --local.
O git clone, git fetch e git pull, mas não o git push, também aceitarão um arquivo do pacote adequado. Consulte git-bundle[1].
-Quando o Git não sabe como lidar com um determinado protocolo de transporte, quando existe, ele tenta usar o auxiliar remote-<transporte>. Para os repositórios locais, as seguintes sintaxes podem ser utilizadas:
<transporte>::<endereço>
-onde <endereço> pode ser um caminho, um servidor e um caminho ou uma sequência arbitrária semelhante a uma URL reconhecida por um auxiliar remoto em específico que está sendo chamado. Para mais detalhes, consulte gitremote-helpers[7].
-Se houver um grande número de repositórios remotos com nomes semelhantes e caso queira usar um formato diferente para eles (de modo que as URLs utilizadas sejam reescritas nas URLs que funcionam), você poderá criar uma seção de configuração da opção:
-[url "<url-da-base-atual>"] - insteadOf = <url-da-outra-base>-
Por exemplo, com isso:
-[url "git://git.host.xz/"] - insteadOf = host.xz:/path/to/ - insteadOf = work:-
uma URL como "work:repo.git" ou como "host.xz:/caminho/para/o/repositório.git" será reescrito em qualquer contexto onde a URL seja "git://git.host.xz/repo.git".
-Caso queira reescrever apenas as URLs para envio por "push" (impulsionamento), é possível criar uma seção de configuração da opção:
-[url "<url da base atual>"] - pushInsteadOf = <a url da outra base>-
Por exemplo, com isso:
-[url "ssh://exemplo.org/"] - pushInsteadOf = git://exemplo.org/-
uma URL como "git://exemplo.org/caminho/para/o/repositório.git" será reescrito para "ssh://exemplo.org/caminho/para/o/repositório.git" para os "pushes" (impulsionamentos), porém os "pulls" (obtenções) ainda usarão a URL original.
-Clonando a partir de um "upstream":
-$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux -$ cd my-linux -$ make-
Faça uma clonagem local que pegue emprestado do diretório atual sem realizar uma averiguação:
-$ git clone -l -s -n . ../copy -$ cd ../copy -$ git show-branch-
Clone a partir de um "upstream" enquanto pega emprestado de um diretório local já existente:
-$ git clone --reference /git/linux.git \ - git://git.kernel.org/pub/scm/.../linux.git \ - my-linux -$ cd my-linux-
Crie um repositório simples para publicar as suas alterações para o público:
-$ git clone --bare -l /home/proj/.git /pub/scm/proj.git-
Tudo abaixo desta linha nesta seção, está seletivamente incluído na documentação git-config[1]. O conteúdo é o mesmo que é encontrado ali:
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Parte do conjunto git[1]
-git clone [--template=<template-directory>] - [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] - [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] - [--dissociate] [--separate-git-dir <git-dir>] - [--depth <depth>] [--[no-]single-branch] [--no-tags] - [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] - [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow] - [--filter=<filter> [--also-filter-submodules]] [--] <repository> - [<directory>]-
Clonează un depozit într-un director nou creat, creează branșe de urmărire la distanță pentru fiecare branșă din depozitul clonat (vizibile folosind git branch --remotes) și creează și extrage o branșă inițială care este bifurcată din branșa activă a depozitului clonat.
După clonare, un simplu git fetch fără argumente va actualiza toate branșele de urmărire de la distanță, iar un git pull fără argumente va unifica în plus branșa master de la distanță în branșa master curentă, dacă există (acest lucru nu este adevărat atunci când se dă "--single-branch"; vezi mai jos).
Această configurație implicită este realizată prin crearea de referințe la capetele de branșă la distanță în refs/remotes/origin și prin inițializarea variabilelor de configurare remote.origin.url și remote.origin.fetch.
Atunci când depozitul din care se clonează se află pe o mașină locală, acest indicator ocolește mecanismul normal de transport "Git aware" și clonează depozitul prin copierea lui HEAD și a tot ceea ce se află în directoarele objects și refs. Fișierele din directorul .git/objects/ sunt legate prin hardlinking pentru a economisi spațiu atunci când este posibil.
Dacă depozitul este specificat ca fiind o cale locală (de exemplu, /path/to/repo), aceasta este calea implicită, iar --local este în esență o opțiune fără efect. Dacă depozitul este specificat ca o adresă URL, atunci acest indicator este ignorat (și nu vom folosi niciodată optimizările locale). Dacă se specifică --no-local, se va anula valoarea implicită atunci când se indică /path/to/repo, utilizând în schimb transportul Git obișnuit.
If the repository’s $GIT_DIR/objects has symbolic links or is a symbolic link, the clone will fail. This is a security measure to prevent the unintentional copying of files by dereferencing the symbolic links.
NOTA: această operațiune se poate întrece cu modificarea concurentă a fișierului
-depozitului sursă, similar cu rularea cp -r src dst în timp ce se modifică
-src.
Forțează procesul de clonare de la un depozit pe un sistem de fișiere local să copieze fișierele din directorul .git/objects în loc să folosească hardlink-uri. Acest lucru poate fi de dorit dacă încercați să faceți o copie de siguranță a depozitului dumneavoastră.
Atunci când depozitul de clonat se află pe calculatorul local, în loc să folosiți legături dure, configurați automat .git/objects/info/alternates pentru a partaja obiectele cu depozitul sursă. Depozitul rezultat pornește fără niciun obiect propriu.
NOTA: aceasta este o operațiune care poate fi periculoasă; nu folosiți
-dacă nu înțelegeți ce face. Dacă vă clonați
-depozitul folosind această opțiune și apoi ștergeți ramuri (sau folosiți orice
-altă comandă Git care face ca orice comitere existentă să nu mai aibă referință) în
-depozit sursă, este posibil ca unele obiecte să nu mai aibă referințe (sau să fie suspendate).
-Aceste obiecte pot fi eliminate prin operațiuni Git normale (cum ar fi git commit)
-care apelează automat git maintenance run --auto. (A se vedea
-git-maintenance[1].) În cazul în care aceste obiecte sunt eliminate și au fost menționate
-de către depozitul clonat, atunci depozitul clonat va deveni corupt.
Rețineți că rularea git repack fără opțiunea --local într-un depozit clonat cu --shared va copia obiectele din depozitul sursă într-un pachet din depozitul clonat, eliminând economiile de spațiu pe disc realizate de clone --shared. Cu toate acestea, este sigur să rulați git gc, care utilizează opțiunea --local în mod implicit.
Dacă doriți să întrerupeți dependența unui depozit clonat cu --shared de depozitul sursă, puteți rula pur și simplu git repack -a pentru a copia toate obiectele din depozitul sursă într-un pachet din depozitul clonat.
În cazul în care depozitul de referință se află pe calculatorul local, configurați automat .git/objects/info/alternates pentru a obține obiecte din depozitul de referință. Utilizarea unui depozit deja existent ca alternativă va necesita mai puține obiecte care să fie copiate din depozitul clonat, reducând costurile de rețea și de stocare locală. Atunci când se utilizează --reference-if-able, un director inexistent este sărit cu un avertisment în loc să se anuleze clonarea.
NOTA: a se vedea NOTA pentru opțiunea --shared și, de asemenea, opțiunea
---dissociate.
Împrumutați obiectele din depozitele de referință specificate cu opțiunile --reference numai pentru a reduce transferul de rețea și încetați să mai împrumutați din acestea după ce se face o clonă, făcând copiile locale necesare ale obiectelor împrumutate. Această opțiune poate fi utilizată și atunci când se clonează local dintr-un depozit care împrumută deja obiecte de la un alt depozit - noul depozit va împrumuta obiecte din același depozit, iar această opțiune poate fi utilizată pentru a opri împrumutul.
Funcționează în liniște. Progresul nu este raportat la fluxul de eroare standard.
-Se execută la nivel verbal. Nu afectează raportarea stării de progres către fluxul de eroare standard.
-Starea de progres este raportată în mod implicit pe fluxul de eroare standard atunci când este atașat la un terminal, cu excepția cazului în care se specifică --quiet. Acest indicator forțează starea de progres chiar dacă fluxul de eroare standard nu este direcționat către un terminal.
Transmite serverului șirul de caractere dat atunci când se comunică folosind versiunea 2 a protocolului. Șirul dat nu trebuie să conțină un caracter NUL sau LF. Gestionarea de către server a opțiunilor serverului, inclusiv a celor necunoscute, este specifică serverului. Atunci când sunt date mai multe --server-option=<option>, toate sunt trimise celeilalte părți în ordinea listată pe linia de comandă.
După finalizarea clonei, nu se efectuează nicio verificare a lui HEAD.
-Eșuează dacă depozitul sursă este un depozit superficial. Variabila de configurare "clone.rejectShallow" poate fi utilizată pentru a specifica valoarea implicită.
-Creați un depozit Git "gol". Adică, în loc să creați <directory> și să plasați fișierele administrative în <directory>/.git, faceți din <directory> însuși <directory> $GIT_DIR. Acest lucru implică în mod evident --no-checkout, deoarece nu există niciun loc unde să se verifice structura de lucru. De asemenea, capetele de branșă de la distanță sunt copiate direct în capetele de branșă locale corespunzătoare, fără a le cartografia în refs/remotes/origin/. Când se utilizează această opțiune, nu se creează nici branșele de urmărire la distanță, nici variabilele de configurare aferente.
Employ a sparse-checkout, with only files in the toplevel directory initially being present. The git-sparse-checkout[1] command can be used to grow the working directory as needed.
-Utilizați funcția de clonare parțială și solicitați ca serverul să trimită un subset de obiecte accesibile în funcție de un anumit filtru de obiecte. Atunci când se utilizează --filter, se utilizează <filter-spec> furnizat pentru filtrul de clonare parțială. De exemplu, --filter=blob:none va filtra toate blob-urile (conținutul fișierelor) până când Git va avea nevoie de ele. De asemenea, --filter=blob:limit=<size> va filtra toate blob-urile cu o dimensiune de cel puțin <size>. Pentru mai multe detalii despre specificațiile filtrelor, consultați opțiunea --filter din git-rev-list[1].
Also apply the partial clone filter to any submodules in the repository. Requires --filter and --recurse-submodules. This can be turned on by default by setting the clone.filterSubmodules config option.
Configurați o oglindă a depozitului sursă. Acest lucru implică --bare. În comparație cu --bare, --mirror nu numai că mapează branșele locale ale sursei în branșele locale ale țintei, ci mapează toate referințele (inclusiv branșele de urmărire la distanță, notele etc.) și stabilește o configurație refspec astfel încât toate aceste referințe să fie suprascrise de o git remote update în depozitul țintă.
În loc să folosiți numele de la distanță origin pentru a ține evidența depozitului din upstream, folosiți <name>. Suprascrie clone.defaultRemoteName din configurare.
În loc să direcționați HEAD nou creat către branșa indicată de HEAD-ul depozitului clonat, direcționați-l către ramura <name>. Într-un depozit non-bare, aceasta este branșa care va fi verificată. --branch poate, de asemenea, să primească etichete și detașează HEAD la acea confirmare în depozitul rezultat.
Atunci când este dată, iar depozitul din care se clonează este accesat prin ssh, aceasta specifică o cale diferită de cea implicită pentru comanda executată la celălalt capăt.
-Specificați directorul din care vor fi utilizate șabloanele; (Consultați secțiunea "TEMPLATE DIRECTORY" din git-init[1])
-Setați o variabilă de configurare în depozitul nou-creat; aceasta intră în vigoare imediat după ce depozitul este inițializat, dar înainte ca istoricul de la distanță să fie preluat sau ca orice fișier să fie verificat. Cheia este în același format ca cel așteptat de git-config[1] (de exemplu, core.eol=true). Dacă sunt date mai multe valori pentru aceeași cheie, fiecare valoare va fi scrisă în fișierul de configurare. Acest lucru face ca, de exemplu, să fie sigură adăugarea unor refspecs suplimentare de preluare la remote origin.
Din cauza limitărilor implementării actuale, unele variabile de configurare nu intră în vigoare decât după preluarea și verificarea inițială. Se știe că variabilele de configurare care nu își fac efectul sunt: remote.<name>.mirror și remote.<name>.tagOpt. Utilizați în schimb opțiunile corespunzătoare --mirror și --no-tags.
Creează o clonă "superficială" cu un istoric trunchiat la numărul specificat de comenzi. Implică --single-branch, cu excepția cazului în care se specifică --no-single-branch pentru a prelua istoricul din apropierea vârfurilor tuturor ramurilor. Dacă doriți să clonați submodulele superficial, treceți și --shallow-submodules.
Creează o clonă superficială cu un istoric după timpul specificat.
-Creează o clonă superficială cu un istoric, excluzând comenzile care pot fi accesate de la o branșă sau etichetă la distanță specificată. Această opțiune poate fi specificată de mai multe ori.
-Clonează numai istoricul care duce la vârful unei singure branșe, fie că este specificat de opțiunea --branch, fie că este vorba de ramura principală la care indică HEAD de la distanță. Preluările ulterioare în depozitul rezultat vor actualiza numai branșa de urmărire de la distanță pentru branșa pentru care această opțiune a fost utilizată pentru clonarea inițială. În cazul în care HEAD de la distanță nu a indicat nicio branșă atunci când s-a efectuat clonarea --single-branch, nu se creează nicio branșă de urmărire la distanță.
Nu clonați niciun tag și setați remote.<remote>.tagOpt=--no-tags în configurație, asigurându-vă că viitoarele operațiuni git pull și git fetch nu vor urmări niciun tag. Recuperările ulterioare explicite de etichete vor funcționa în continuare (a se vedea git-fetch[1]).
Poate fi utilizat împreună cu --single-branch pentru a clona și a menține o branșă fără alte referințe decât o singură branșă clonată. Acest lucru este util, de exemplu, pentru a menține un număr minim de clone ale branșei implicite a unui depozit pentru indexarea căutărilor.
După ce clona este creată, inițializați și clonați submodulele din cadrul acesteia pe baza specificației de traseu furnizate. Dacă nu este furnizată nicio specificație de traseu, toate submodulele sunt inițializate și clonate. Această opțiune poate fi furnizată de mai multe ori pentru specificațiile de traseu compuse din mai multe intrări. Clona rezultată are submodule.active setat la specificația de traseu furnizată sau "." (însemnând toate submodulele) dacă nu este furnizată nicio specificație de traseu.
Submodulele sunt inițializate și clonate folosind setările lor implicite. Acest lucru este echivalent cu rularea git submodule update --init --recursive <pathspec> imediat după ce clona este terminată. Această opțiune este ignorată dacă depozitul clonat nu are un registru de lucru/checkout (de exemplu, dacă se dă oricare dintre --no-checkout/-n, --bare sau --mirror)
Toate submodulele care sunt clonate vor fi superficiale, cu o adâncime de 1.
-Toate submodulele care sunt clonate vor utiliza starea branșei de urmărire la distanță a submodulelor pentru a actualiza submodulele, mai degrabă decât SHA-1 înregistrat de superproiect. Echivalent cu trecerea --remote la git submodule update.
În loc să plasați depozitul clonat acolo unde ar trebui să fie, plasați depozitul clonat în directorul specificat, apoi creați o legătură simbolică Git agnostică pentru sistemul de fișiere. Rezultatul este că depozitul Git poate fi separat de structura de lucru.
-Numărul de submodule preluate în același timp. Valoarea implicită este cea a opțiunii submodule.fetchJobs.
Depozitul (eventual la distanță) din care se clonează. Consultați secțiunea GIT URLS de mai jos pentru mai multe informații despre specificarea depozitelor.
-Numele unui nou director în care se clonează. Partea "humanish" a depozitului sursă este utilizată dacă nu se indică în mod explicit un director (repo pentru /path/to/repo.git și foo pentru host.xz:foo/.git). Clonarea într-un director existent este permisă numai dacă directorul este gol.
Before fetching from the remote, fetch a bundle from the given <uri> and unbundle the data into the local repository. The refs in the bundle will be stored under the hidden refs/bundle/* namespace. This option is incompatible with --depth, --shallow-since, and --shallow-exclude.
In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.
-Git supports ssh, git, http, and https protocols (in addition, ftp and ftps can be used for fetching, but this is inefficient and deprecated; do not use them).
-Transportul nativ (adică git:// URL) nu face autentificare și ar trebui utilizat cu precauție în rețelele nesecurizate.
-Următoarele sintaxe pot fi utilizate cu acestea:
-ssh://[user@]host.xz[:port]/path/to/repo.git/
-git://host.xz[:port]/path/to/repo.git/
-http[s]://host.xz[:port]/path/to/repo.git/
-ftp[s]://host.xz[:port]/path/to/repo.git/
-O sintaxă alternativă de tip scp poate fi utilizată, de asemenea, cu protocolul ssh:
-[user@]host.xz:path/to/repo.git/
-Această sintaxă este recunoscută numai dacă nu există bariere înaintea primelor două puncte. Acest lucru ajută la diferențierea unei căi locale care conține două puncte. De exemplu, calea locală foo:bar ar putea fi specificată ca o cale absolută sau ./foo:bar pentru a evita să fie interpretată greșit ca o adresă url ssh.
Protocoalele ssh și git acceptă, în plus, extinderea ~username:
-ssh://[utilizator@]host.xz[:port]/~[user]/path/to/repo.git/
-git://host.xz[:port]/~[user]/path/to/repo.git/
-[utilizator@]host.xz:/~[user]/path/to/repo.git/
-Pentru depozitele locale, de asemenea suportate nativ de Git, se pot folosi următoarele sintaxe:
-/path/to/repo.git/
-file:///path/to/repo.git/
-Aceste două sintaxe sunt în mare parte echivalente, cu excepția faptului că prima implică opțiunea --local.
-git clone, git fetch și git pull, dar nu și git push, vor accepta, de asemenea, un fișier bundle adecvat. A se vedea git-bundle[1].
-Atunci când Git nu știe cum să gestioneze un anumit protocol de transport, încearcă să utilizeze ajutorul de la distanță "remote-<transport>", dacă există unul. Pentru a solicita în mod explicit un ajutor la distanță, se poate utiliza următoarea sintaxă:
-<transport>::<address>
-unde <address> poate fi o cale, un server și o cale sau un șir arbitrar de tip URL recunoscut de ajutorul specific de la distanță care este invocat. Pentru detalii, consultați gitremote-helpers[7].
-Dacă există un număr mare de depozite la distanță cu nume similare și doriți să utilizați un format diferit pentru acestea (astfel încât URL-urile pe care le utilizați să fie rescrise în URL-uri care funcționează), puteți crea o secțiune de configurare a formularului:
-[url "<actual-url-base>"] - insteadOf = <other-url-base>-
De exemplu, cu aceasta:
-[url "git://git.host.xz/"] - insteadOf = host.xz:/path/to/ - insteadOf = work:-
o adresă URL de tipul "work:repo.git" sau "host.xz:/path/to/repo.git" va fi rescrisă în orice context care consideră că o adresă URL este "git://git.host.xz/repo.git".
-Dacă doriți să rescrieți URL-urile doar pentru push, puteți crea o secțiune de configurare a formularului:
-[url "<actual-url-base>"] - pushInsteadOf = <other-url-base>-
De exemplu, cu aceasta:
-[url "ssh://example.org/"] - pushInsteadOf = git://example.org/-
o adresă URL de tipul "git://example.org/path/to/repo.git" va fi rescrisă în "ssh://example.org/path/to/repo.git" pentru împingeri, dar pentru extrageri se va utiliza în continuare adresa URL originală.
-Clonă din upstream:
-$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux -$ cd my-linux -$ make-
Realizează o clonă locală care împrumută din directorul curent, fără a verifica lucrurile:
-$ git clone -l -s -n . ../copy -$ cd ../copy -$ git show-branch-
Clonarea din upstream în timp ce împrumutați dintr-un director local existent:
-$ git clone --reference /git/linux.git \ - git://git.kernel.org/pub/scm/.../linux.git \ - my-linux -$ cd my-linux-
Creați un depozit gol pentru a vă publica modificările în mod public:
-$ git clone --bare -l /home/proj/.git /pub/scm/proj.git-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Parte a suitei git[1]
-git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend] - [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>] - [-F <file> | -m <msg>] [--reset-author] [--allow-empty] - [--allow-empty-message] [--no-verify] [-e] [--author=<author>] - [--date=<date>] [--cleanup=<mode>] [--[no-]status] - [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]] - [(--trailer <token>[(=|:)<value>])…] [-S[<keyid>]] - [--] [<pathspec>…]-
Cria um novo commit que tenha todos os conteúdos atuais do índice e a mensagem informada no registro log descrevendo as alterações. Um novo commit é um herdeiro direto do HEAD que em geral é o topo do ramo atual e o ramo é atualizado para apontar para ele (a menos que nenhum ramo seja associado com a árvore de trabalho onde no caso o HEAD esteja desanexado como descrito em git-checkout[1]).
O conteúdo a ser feito o commit pode ser definido de diferente maneiras:
-ao usar git-add[1] para ir incrementando mudanças com "add" para o índice antes de usar o comando (Nota: devem ser "adicionados" até mesmo os arquivos modificados);
-ao usar git-rm[1] para remover os arquivos da árvore de trabalho e do índice, novamente, antes de usar o comando commit;
-ao listar os arquivos como argumentos para o comando commit (sem usar as opções --interactive ou --patch), nesse caso, o commit ignorará as alterações organizadas no índice e em vez disso registrará o conteúdo atual dos arquivos listados (que já devem ser informados pelo Git );
-ao usar a opção -a com o comando commit para "adicionar" automaticamente as alterações de todos os arquivos informados (ou seja, todos os arquivos que já estão listados no índice) e "rm" para remover os arquivos automaticamente da árvore de trabalho e assim executar o commit de fato;
-usando as opções --interactive ou --patch com o comando commit para decidir um por um quais os arquivos ou os blocos devem fazer parte do commit além do conteúdo do índice, antes de finalizar a operação. Consulte a seção “Modo Interativo” do git-add[1] para aprender como operar estes modos.
A opção --dry-run pode ser utilizada para obter um resumo do que está incluído em qualquer uma das opções acima para o próximo commit, fornecendo o mesmo conjunto de parâmetros (opções e caminhos).
Caso faça um commit e imediatamente encontre um erro logo em seguida, é possível recuperá-lo com o comando git reset.
-Diz ao comando para preparar automaticamente os arquivos que foram modificados e excluídos, porém os novos arquivos que você não informou ao Git não são afetados.
-Utilize a interface interativa do patch para selecionar quais as alterações serão aplicadas ao commit. Para mais detalhes, consulte git-add[1].
-Pega um objeto commit existente e o reutiliza na mensagem do registro log, assim como as informações da autoria (incluindo o registro de data e hora) durante a criação de um commit.
-Como -C, porém com -c o editor é chamado para que o usuário possa editar ainda mais a mensagem do commit.
Crie um novo commit que "corrija" o <commit> quando for aplicado com o comando git rebase --autosquash. Somente a opção --fixup=<commit> cria um "fixup!" (correção) que altera o conteúdo de um <commit> contudo deixa a mensagem de registro intacta. --fixup=amend:<commit> é semelhante, porém, cria um commit "amend!" que também substitui a mensagem do registro do <commit> pela mensagem de registro do commit "amend!". A opção --fixup=reword:<commit> cria um commit "amend!" que substitui a mensagem do registro do <commit> por sua própria mensagem de registro, mas não faz quaisquer alterações no conteúdo do <commit>.
O commit criado somente com a opção --fixup=<commit> tem o assunto da mensagem composto por "fixup!" seguido pela linha do assunto do <commit>, também é reconhecido especialmente através do comando git rebase --autosquash. A opção -m pode ser usada para complementar o registro da mensagem do commit criado, porém o comentário adicional será jogado fora assim que o commit "fixup!" for aplicado ao <commit> através do comando git rebase --autosquash.
O commit criado através da opção --fixup=amend:<commit> é semelhante porém seu assunto é prefixado com "amend!". A mensagem do log do <commit> é copiada para a mensagem de log do commit "amend!" e aberto em um editor para que possa ser refinado. Quando o comando git rebase --autosquash comprime o commit "amend!" no <commit>, a mensagem de log do <commit> é substituída pela mensagem de log refinada do commit "amend!". É considerado um erro quando o registro da mensagem do commit "amend!" esteja vazia, a menos que a opção --allow-empty-message seja definida.
--fixup=reword:<commit> é uma abreviação para --fixup=amend:<commit> --only. Isso cria um commit "amend!" com apenas uma mensagem log (ignorando quaisquer alterações preparadas no índice). Quando é comprimido através do comando git rebase --autosquash, ele substitui a mensagem do log do <commit> sem fazer quaisquer outras alterações.
Nem os commits "fixup!" tampouco os commits "amend!" alteram a autoria do <commit> quando aplicadas através do comando git rebase --autosquash. Para mais detalhes consulte git-rebase[1].
Constrói a mensagem de um commit para utilizar com rebase --autosquash. A linha do assunto da mensagem do commit é retirada de um determinado commit com um prefixo "squash! ". Pode ser usado com as opções adicionais das mensagens dos commits (-m/-c/-C/-F). Para mais detalhes, consulte git-rebase[1].
Quando utilizado com as opções -C/-c/--amend, ou ao fazer o commit após uma escolha seletiva conflitante, declare que a autoria do commit resultante agora pertence a quem fez o commit. Isso também renova o registro de data e hora do autor.
-Ao executar um ensaio, informe a saída no formato curto. Para mais detalhes, consulte git-status[1]. Implica no uso da opção --dry-run.
Exibe o ramo e a informação de rastreio quando estiver em formato curto.
-Ao executar um ensaio, informe a saída no formato porcelana. Para mais detalhes, consulte git-status[1]. Implica no uso da opção --dry-run.
Ao executar um ensaio, informe a saída no formato curto. Implica no uso da opção --dry-run.
Ao exibir a condição de saída short ou porcelain, imprima o nome do arquivo literalmente e termine as entradas com um NUL, em vez do LF. Caso nenhum formato de saída seja informado, implica no uso da opção --porcelain. Sem a opção -z, os nomes dos arquivos com caracteres "incomuns" serão citados conforme explicado nas variáveis de configuração core.quotePath (consulte git-config[1]).
Pega a mensagem de commit vindo de um determinado arquivo. Utilize - para ler a mensagem da entrada padrão.
-Sobrescreva o commit do autor. Defina o autor de forma explicita usando o formato padrão Chiquinha <chiquinha@examplo.com>. Caso contrário, assume-se que a predefinição seja <autor> que é usado para localizar um commit já existente feito através deste autor (ou seja, rev-list --all -i --author=<autor>); o autor do commit é copiado a partir do primeiro commit que for encontrado.
Substitua a data do autor que foi utilizada no commit.
-Usa <msg> como uma mensagem de commit. Caso múltiplas opções -m sejam usadas, o seu conteúdo será disposto em parágrafos separados.
A opção -m é utilizado em conjunto exclusivamente com -c, -C e -F.
Ao editar a mensagem do commit, inicie o editor com o conteúdo do arquivo informado. A variável de configuração commit.template é frequentemente utilizada para fornecer esta opção de forma implícita ao comando. Esse mecanismo pode ser utilizado por projetos que desejam orientar os participantes com algumas dicas sobre o que escrever na mensagem e em qual ordem. Aborte o commit caso o usuário saia do editor sem editar a mensagem. Não qualquer efeito quando uma mensagem é dada por outros meios, por exemplo, com as opções -m ou -F.
Adicione uma linha Signed-off-by de quem fez o commit no final da mensagem de registro do commit. O significado de uma aprovação depende do projeto onde você está fazendo o commit. Por exemplo, ele pode certificar que quem fez o commit tem o direito de enviar o trabalho sob a licença do projeto ou concorda com alguma representação do contribuinte, como um certificado de origem do desenvolvedor. (Consulte https://developercertificate.org para saber qual é a usada pelo kernel do Linux e pelos projetos Git). Consulte a documentação ou a liderança do projeto para onde está contribuindo para compreender como as assinaturas são usadas nesse projeto.
A opção --no-signoff pode ser usada para contra-ordenar uma opção --signoff anterior na linha de comando.
-Determine um par (<token>, <valor>) que deve ser aplicado como um caracteres de resposta. (por exemplo, git commit --trailer "Auxiliado por:C O Mitter \ <committer@example.com>" --trailer "Auxiliado por:C O Mitter \ <committer@example.com>" será atrelado o "Auxiliado por" e o "Auxiliado por" à mensagem do commit.) A variável de configuração do trailer.* (git-interpret-trailers[1]) pode ser usado para definir se um atrelado duplicado será omitido, onde na rodada de atrelados cada atrelado apareceria em conjunto com outros detalhes.
É predefinido que os ganchos pre-commit e commit-msg sejam executados. Quando qualquer uma das opções --no-verify ou -n são usadas, elas são ignoradas. Consulte também githooks[5].
Geralmente, ao gravar um commit que tenha exatamente a mesma árvore como se fosse a sua origem, é um erro, o comando impede que você faça um commit desta natureza. Esta opção ignora a segurança e deve ser utilizada principalmente por scripts SCM externos.
-Como a opção --allow-empty, este comando é principalmente para uso por scripts de interface SCM externos. Permite criar um commit com uma mensagem vazia sem usar os comandos de "encanamento" como git-commit-tree[1].
Esta opção determina como a mensagem que foi informada ao commit deve ser limpa antes do commit ser feito. O <modo> pode ser strip, whitespace, verbatim, scissors ou default.
Retira as linhas vazias no inicio e no final, e os rastros dos espaços finais, os comentários e reduza as linhas vazias consecutivamente.
-O mesmo que strip, exceto que o #comentário não é removido.
Não altera a mensagem de forma alguma.
-O mesmo que whitespace (espaço), exceto que tudo incluindo a linha encontrada abaixo seja truncada caso a mensagem precise ser editada. "#" pode ser personalizada com core.commentChar.
# ------------------------ >8 -------------------------
O mesmo que strip caso a mensagem esteja para ser editada. Caso contrário, whitespace (espaço).
A predefinição pode ser alterada através da variável de configuração commit.cleanup (consulte git-config[1]).
A mensagem obtida do arquivo com a opção -F, da linha de comando com a opção -m e do objeto commit com -C é normalmente utilizada como a mensagem de registro log do commit não modificado. Esta opção permite editar ainda mais a mensagem retirada destas fontes.
Utilize a mensagem do commit selecionado sem rodar um editor. Por exemplo, git commit --amend --no-edit altera um commit sem alterar o conteúdo da mensagem do mesmo.
Substitua o cume do ramo atual criando um novo commit. A árvore gravada é preparada como de costume (incluindo a aplicação das opções -i e -o; e pathspec explicitamente), a mensagem do commit original é utilizada como um ponto de partida, em vez de uma mensagem vazia. Quando nenhuma outra mensagem é utilizada na linha de comando através de opções como -m, -F, -c, etc. O novo commit possuirá as mesmas origens e seu respectivo autor como o atual (a opção --reset-author pode ser utilizada para mudar isso).
É grosseiramente um equivalente para:
-$ git reset --soft HEAD^ - $ ... faça qualquer outra coisa para encontrar a árvore certa ... - $ git commit -c ORIG_HEAD-
mas pode ser utilizado para corrigir a mesclagem de um commit.
-Você deve entender as implicações de sobrescrever o histórico caso corrija um commit que já tenha sido publicado. (Consulte a seção "RECUPERANDO DO UPSTREAM REBASE" no git-rebase[1].)
-Ignore o gancho de reescrita de postagem.
-Antes de fazer um commit dos conteúdos preparados até o momento, prepare também o conteúdo dos caminhos utilizados na linha de comando. Isso geralmente não é o que você quer, a menos que esteja concluindo um mesclagem conflitante.
-Faça um commit utilizando o conteúdo atualizado da árvore de trabalho dos caminhos definidos na linha de comando, desconsiderando qualquer outro conteúdo que tenha sido preparado para os outros caminhos. Essa é a maneira predefinida de operação do comando git commit caso algum outro caminho tenha sido informado na linha de comando; nesse caso, essa opção poderá ser omitida. Caso esta opção seja utilizada junto com --amend, nenhum outro caminho precisará ser informado, o que pode ser utilizado para alterar o último commit sem confirmar as alterações que já foram preparadas. Se utilizado junto com a opção`--allow-empty` também não são necessários e um commit vazio será criado.
O "pathspec" é passado com <arquivo> em vez dos argumentos da linha de comando. Caso o <arquivo> seja exatamente -, a entrada padrão será utilizada. Os elementos do "pathspec" são separados por caracteres de término de linha LF ou CR/LF. Os elementos do "pathspec" podem ser citados conforme explicado na variável de configuração core.quotePath (consulte git-config[1]). Consulte também opção --pathspec-file-nul e o global --literal-pathspecs.
Só faz algum sentido caso seja utilizado junto com a opção --pathspec-from-file. Os elementos "pathspec" são separados com caracteres NUL e todos os outros caracteres são considerados de forma literal (incluindo as novas linhas e as citações).
Exibe arquivos sem rastreamento.
-O parâmetro mode é opcional, a predefinição retorna para all (todos), sendo utilizado para determinar a manipulação dos arquivos que não foram rastreados; quando a opção -u não for utilizada, a predefinição volta para normal, ou seja, exibe os arquivos e os diretórios que não foram rastreados.
As opções disponíveis são:
-no - Não exibe quaisquer arquivos que não tenham sido rastreados
-normal - Exibe todos os arquivo e diretórios que não foram rastreados
-all - Exibe todos os arquivos individualmente nos diretórios não rastreados.
-All usual spellings for Boolean value true are taken as normal and false as no. The default can be changed using the status.showUntrackedFiles configuration variable documented in git-config[1].
Exibe as diferenças unificadas entre o commit no HEAD e o que seria feito o commit na parte inferior do modelo da mensagem do commit para ajudar o usuário a descrever o commit lembrando quais as alterações que o commit possui. Note que esta saída "diff" não tem suas linhas prefixadas com #. Este "diff" não fará parte da mensagem do commit. Consulte a configuração da variável commit.verbose em git-config[1].
Caso seja utilizado duas vezes exibirá além do diferencial unificado entre o que seriam feitos os commits e os arquivos da árvore de trabalho, ou seja, as alterações não-estáticas nos arquivos rastreados.
-Suprimir a mensagem de resumo do commit.
-Não crie um commit porém exiba uma lista dos caminhos onde os commits devem ser feitos, os caminhos com as alterações locais onde os commits serão deixados de lado e os caminhos que não serão rastreados.
-Inclua a saída do git-status[1] na mensagem do commit ao usar um editor para preparar a mensagem do commit. A predefinição retorna para ligado, porém pode ser utilizado para substituir a variável de configuração commit.status.
Não inclua a saída do git-status[1] no modelo da mensagem do commit ao utilizar um editor para preparar a mensagem predefinida do commit.
-Commits assinados com o GPG O argumento keyid é opcional e a predefinição retorna para a identidade de quem fez o commit; caso seja utilizado, deve estar anexado a opção e sem espaço. A opção --no-gpg-sign é útil para revogar a variável de configuração commit.gpgSign e a anterior --gpg-sign.
Não interprete mais argumentos como opções.
-Quando o pathspec é utilizado na linha de comando, faça o commit do conteúdo dos arquivos que correspondem ao pathspec sem registrar as alterações já adicionadas ao índice. O conteúdo desses arquivos também é preparado para o próximo commit, além do que já foi preparado anteriormente.
Para mais detalhes sobre a sintaxe, consulte a entrada pathspec em gitglossary[7].
-Ao gravar o seu próprio trabalho, o conteúdo dos arquivos modificados na sua árvore de trabalho é temporariamente armazenado em uma área intermediária chamada "índice" com git add. Um arquivo pode ser revertido para o último commit com git restore --staged apenas no índice mas não na árvore de trabalho, que reverte efetivamente o git add e impede que as alterações nesse arquivo façam parte do próximo commit. Após criar a condição a ser feito o commit incrementalmente com esses comandos, o git commit (sem nenhum parâmetro pathname) é utilizado para registrar o que foi preparado até o momento. Essa é a forma mais básica do comando. Um exemplo:
$ edit hello.c -$ git rm goodbye.c -$ git add hello.c -$ git commit-
Em vez de disponibilizar arquivos após cada alteração individual, você pode dizer ao git commit para observar as alterações nos arquivos cujo conteúdo é rastreado na sua árvore de trabalho e faz os comandos correspondentes git add e git rm para você. Ou seja, este exemplo faz o mesmo que o exemplo anterior, se não houver outra alteração na sua árvore de trabalho:
$ edit hello.c -$ rm goodbye.c -$ git commit -a-
O comando git commit -a primeiro olha para a sua árvore de trabalho, nota que você modificou o hello.c e removeu o goodbye.c e executa os comandos necessários git add e git rm para você.
Após preparar as mudanças em muitos arquivos, você pode alterar a ordem em que as alterações são registradas ao encaminhar pathnames para git commit. Quando pathnames são utilizados, o comando faz um commit que registra apenas as alterações feitas nos caminhos informados:
$ edit hello.c hello.h -$ git add hello.c hello.h -$ edit Makefile -$ git commit Makefile-
Isso faz um commit que registra a modificação no arquivo Makefile. As mudanças preparadas para hello.c e hello.h não são incluídas no commit resultante. No entanto as suas mudanças não se perdem, elas ainda são preparadas e meramente retidas. Após a sequência acima, se fizer:
$ git commit-
este segundo commit registraria as alterações em hello.c e hello.h conforme o esperado.
Depois que uma mesclagem (iniciada pelo comando git merge ou git pull) é interrompida por causa de conflitos, os caminhos mesclados de maneira limpa já são preparados para serem confirmados para você, e os caminhos em conflito são deixados num estado inalterado. Você precisaria primeiro verificar quais são os caminhos que estão em conflito com o comando git status e após corrigi-los manualmente em sua árvore de trabalho, você prepararia o resultado como de costume com o comando git add:
$ git status | grep unmerged -unmerged: hello.c -$ edit hello.c -$ git add hello.c-
Após resolver os conflitos e organizar o resultado, o git ls-files -u deixaria de mencionar o caminho conflitado. Quando terminar, execute git commit para finalmente registrar a mesclagem:
$ git commit-
Como no caso de registrar as suas próprias alterações, você pode usar a opção -a para salvar a digitação. Uma diferença é que durante uma resolução da mesclagem, você não pode utilizar o comando git commit com o pathnames para alterar a ordem onde as alterações dos commits foram realizados porque a mesclagem deve ser registrada como um commit. De fato, o comando se recusa a ser executado quando recebem os nomes do caminho (consulte a opção -i).
A informação do autor e de quem fez o commit são extraídas das seguintes variáveis do ambiente, se definido:
-GIT_AUTHOR_NAME -GIT_AUTHOR_EMAIL -GIT_AUTHOR_DATE -GIT_COMMITTER_NAME -GIT_COMMITTER_EMAIL -GIT_COMMITTER_DATE-
(nb "<", ">" e "\n"s serão removidos)
-É de praxe utilizar um nome pessoal como sendo os nomes dos autores e de quem fez os commits (isto é, um nome pela qual outros humanos usam para se referir a você), no entanto o Git não impõem ou requer qualquer forma em particular. Um unicode arbitrário pode ser utilizado e é sujeito às restrições listadas acima. Este nome não tem nenhum efeito na autenticação; para isso consulte a variável credential.username em git-config[1].
Caso (algumas dessas) variáveis de ambiente não sejam definidas, as informações são obtidas dos itens da configuração user.name e user.email ou caso não haja, na variável de ambiente EMAIL ou se também não existir ou tenha sido definida, o nome de usuário do sistema e nome do host (hostname) utilizado pelo email enviado (extraído de /etc/mailname e retornando ao nome completo do host quando esse arquivo não existir).
O author.name e committer.name e suas respectivas opções de email correspondentes substituem o user.name e user.email caso sejam configurados e são substituídos pelas variáveis do ambiente.
O uso típico é definir apenas as variáveis user.name e user.email; as outras opções são informadas para casos de uso mais complexos.
As variáveis de ambiente GIT_AUTHOR_DATE e GIT_COMMITTER_DATE são compatíveis com os seguintes formatos de data:
É <unix-timestamp> <time-zone-offset>, onde desde a época do UNIX <unix-timestamp> é o valor em segundos. O <time-zone-offset> é o desvio positivo ou negativo a partir do UTC. O CET por exemplo (onde é 1 hora à frente do UTC ) é +0100.
The standard date format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200.
A data e hora definidas pela norma ISO 8601 2005-04-07T22:13:13 por exemplo. O analisador também aceita um espaço em vez do caractere T. O analisador aceita um espaço em vez do caractere T também. As partes fracionadas de um segundo serão ignoradas, logo 2005-04-07T22:13:13.019 por exemplo, será tratada como 2005-04-07T22:13:13.
|
- Note
- |
-
-Além disso, a parte da data é aceita nos seguintes formatos: YYYY.MM.DD, MM/DD/YYYY e DD.MM.YYYY.
- |
-
Além de reconhecer todos os formatos da data acima, a opção --date também tentará dar sentido aos outros formatos para que sejam legíveis, como "ontem" ou "a última sexta-feira ao meio-dia".
Embora não seja obrigatório, é uma boa ideia iniciar a mensagem do commit com uma única linha curta (não mais que 50 caracteres) resumindo a alteração, seguida por uma linha em branco e em seguida, uma descrição mais completa. O texto até a primeira linha em branco numa mensagem do commit é tratado como o título do commit e esse título é utilizado através de todo o Git. Por exemplo, o git-format-patch[1] transforma um commit num email e usa o título na linha de assunto e o restante do commit no corpo da mensagem.
-O Git é, até certo ponto, um codificador de caracteres agnóstico.
-O conteúdo dos objetos bolha (blob) são sequências de bytes não interpretadas. Não há uma tradução de codificação no nível do núcleo.
-Os nomes do caminho são codificados na forma de normalização UTF-8 C. Isso se aplica a objetos nas árvore, arquivos do índice, referência de nomes e nomes do caminho em argumentos da linha de comando, variáveis do ambiente e os arquivos de configuração (.git / config (consulte git-config[1]), gitignore[5], gitattributes[5] e gitmodules[5]).
Observe que o Git, em seu cerne, trata os nomes do caminho simplesmente como sequências de bytes não NUL; não há conversões de codificação do nome do caminho (exceto no Mac e no Windows). Portanto, o uso de nomes com caminho não ASCII funcionará, em geral, mesmo em plataformas e sistemas de arquivos que usam codificações ASCII estendidas legadas. No entanto, os repositórios criados nesses sistemas não funcionarão corretamente em sistemas baseados em UTF-8 (Linux, Mac, Windows por exemplo) e vice-versa. Além disso, muitas ferramentas com base no Git simplesmente assumem que os nomes de caminho são UTF-8 e não exibem outras codificações corretamente.
-As mensagens do registro log do commit geralmente são codificadas em UTF-8, porém há compatibilidade para outras codificações ASCII estendidas. Isso inclui ISO-8859-x, CP125x e muitos outros. Porém não há compatibilidade com codificações UTF-16/32, EBCDIC e CJK, codificações de vários bytes (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).
-Embora incentivemos que as mensagens do registro do commit sejam codificadas em UTF-8, tanto o núcleo quanto o Git porcelain foram projetados para não impor o UTF-8 nos projetos. Se todos os participantes de um determinado projeto acharem mais conveniente usar codificações herdadas, o Git não o proibirá. Entretanto, há alguns aspectos que devem ser levados em consideração.
-O comando git commit e o git commit-tree emitem um aviso se a mensagem de registro do commit fornecida a ele não se parecer com uma string UTF-8 válida, a menos que você diga explicitamente que o seu projeto usa uma codificação antiga. A maneira de definir isso é ter i18n.commitEncoding no arquivo .git/config, assim:
[i18n] - commitEncoding = ISO-8859-1-
Os objetos criados do commit com a configuração acima, registram o valor i18n.commitEncoding em seu cabeçalho encoding. Isso serve para ajudar as outras pessoas que forem examiná-las mais tarde. A ausência desse cabeçalho implica que a mensagem de registro do commit está codificada em UTF-8.
Os comandos git log, git show, git blame e outros, analisam o cabeçalho encoding de um objeto commit e tentam recodificar a mensagem de registro em UTF-8, a menos que outro seja especificado. Você pode especificar a codificação de saída desejada com i18n.logOutputEncoding no arquivo .git/config, da seguinte maneira:
[i18n] - logOutputEncoding = ISO-8859-1-
Caso não tenha essa variável de configuração, o valor de i18n.commitEncoding é utilizado em seu lugar.
Observe que decidimos deliberadamente não codificar novamente a mensagem do registro log do commit quando um commit for feito para forçar a codificação UTF-8 a nível do objeto commit, porque a re-codificação para UTF-8 não é necessariamente uma operação reversível.
-O editor usado para editar a mensagem do registro log do commit que será escolhido entre a variável de ambiente GIT_EDITOR, a variável de configuração core.editor, a variável de ambiente VISUAL ou a variável de ambiente EDITOR (nesta ordem). Para mais detalhes, consulte git-var[1].
Tudo acima desta linha nesta seção não está incluído na documentação git-config[1]. O conteúdo que segue é o mesmo que se encontra lá:
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Este comando pode executar os ganchos commit-msg, prepare-commit-msg, pre-commit, post-commit e post-rewrite. Para mais informações consulte githooks[5].
$GIT_DIR/COMMIT_EDITMSG Este arquivo contém a mensagem do commit de um commit em andamento. Caso o git commit encerre devido a um erro antes da criação do commit, qualquer mensagem do commit que tenha sido utilizada pelo usuário (por exemplo, numa sessão do editor) estará disponível neste arquivo, mas será substituída pela próxima invocação do comando git commit.
Parte do conjunto git[1]
-git config [<file-option>] [--type=<type>] [--fixed-value] [--show-origin] [--show-scope] [-z|--null] <name> [<value> [<value-pattern>]] -git config [<file-option>] [--type=<type>] --add <name> <value> -git config [<file-option>] [--type=<type>] [--fixed-value] --replace-all <name> <value> [<value-pattern>] -git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get <name> [<value-pattern>] -git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get-all <name> [<value-pattern>] -git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] [--name-only] --get-regexp <name-regex> [<value-pattern>] -git config [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch <name> <URL> -git config [<file-option>] [--fixed-value] --unset <name> [<value-pattern>] -git config [<file-option>] [--fixed-value] --unset-all <name> [<value-pattern>] -git config [<file-option>] --rename-section <old-name> <new-name> -git config [<file-option>] --remove-section <name> -git config [<file-option>] [--show-origin] [--show-scope] [-z|--null] [--name-only] -l | --list -git config [<file-option>] --get-color <name> [<default>] -git config [<file-option>] --get-colorbool <name> [<stdout-is-tty>] -git config [<file-option>] -e | --edit-
Sie können mit diesem Befehl Optionen abfragen/setzen/ersetzen/leeren. Der Name ist tatsächlich der Abschnitt und der Schlüssel, getrennt durch einen Punkt, und der Wert wird außer Acht gelassen.
-Multiple lines can be added to an option by using the --add option. If you want to update or unset an option which can occur on multiple lines, a value-pattern (which is an extended regular expression, unless the --fixed-value option is given) needs to be given. Only the existing values that match the pattern are updated or unset. If you want to handle the lines that do not match the pattern, just prepend a single exclamation mark in front (see also BEISPIELE), but note that this only works when the --fixed-value option is not in use.
Die Option --type=<Typ> veranlasst git config zu überprüfen, ob ein- und ausgehende Werte unter den angegebenen <Typ> zulässig sind. Wenn kein --type=<Typ> angegeben ist, wird keine Kanonisierung durchgeführt. Benutzer können einen bestehenden --type Bezeichner mit --no-type aufheben.
Standardmäßig werden die Werte aus den lokalen Konfigurationsdateien des Systems, der globalen Einstellung und der des Repositorys ausgelesen. Die Optionen --system, --global, --local, ---worktree und --file <Datei-Name> können verwendet werden, um dem Befehl anzuweisen, nur von diesem Speicherort zu lesen (siehe den Abschnitt [DATEIEN]).
Beim Schreiben wird der neue Wert standardmäßig in die lokale Konfigurationsdatei des Repositorys geschrieben, und die Optionen --system, --global, --worktree, --file <filename> können benutzt werden, um dem Befehl mitzuteilen, dass er dorthin schreiben soll (Sie können --local angeben, aber das ist schon die Voreinstellung).
Dieser Befehl schlägt bei einem Fehler mit einem Nicht-Null-Status fehl. Einige dieser Exit-Codes sind:
-Der Abschnitt oder Schlüssel ist ungültig (ret=1),
-weder Abschnitt noch Name wurde angegeben (ret=2),
-die Konfigurationsdatei ist falsch (ret=3),
-die Konfigurationsdatei kann nicht geschrieben werden (ret=4),
-Sie versuchen, eine nicht existierende Option aufzuheben (ret=5),
-Sie versuchen, eine Option rückgängig zu machen/einzustellen, für die mehrere Zeilen übereinstimmen (ret=5), oder
-Sie versuchen, einen ungültigen regulären Ausdruck (regexp) zu verwenden (ret=6).
-Bei erfolgreichem Abschluss gibt der Befehl den Exit-Code 0 zurück.
-A list of all available configuration variables can be obtained using the git help --config command.
Default behavior is to replace at most one line. This replaces all lines matching the key (and optionally the value-pattern).
Adds a new line to the option without altering any existing values. This is the same as providing ^$ as the value-pattern in --replace-all.
Liefert den Wert für einen angegebenen Schlüssel (optional gefiltert durch einen dem Wert entsprechenden Regex). Gibt Fehlercode 1 zurück, wenn der Schlüssel nicht gefunden wurde. Wenn mehrere Schlüsselwerte gefunden werden, wird der letzte Wert zurückgegeben.
-Entspricht --get, liefert aber alle Werte eines mehrwertigen Schlüssels zurück.
Wie --get-all, interpretiert den Namen aber als regulären Ausdruck und gibt die Schlüsselnamen aus. Der Abgleich mit regulären Ausdrücken unterscheidet derzeit zwischen Groß- und Kleinschreibung und erfolgt gegen eine kanonisierte Version des Schlüssels, in der die Namen von Abschnitt und Variablen kleingeschrieben werden, die Namen von Unterabschnitten jedoch nicht.
When given a two-part name section.key, the value for section.<URL>.key whose <URL> part matches the best to the given URL is returned (if no such key exists, the value for section.key is used as a fallback). When given just the section as name, do so for all the keys in the section and list them. Returns error code 1 if no value is found.
-Bei Schreib-Optionen: schreibt in die globale ~/.gitconfig Datei anstatt in die .git/config des Repositorys, schreibt in die $XDG_CONFIG_HOME/git/config Datei, wenn diese Datei existiert und die ~/.gitconfig Datei nicht.
Bei Lese-Optionen: Liest nur aus der globalen ~/.gitconfig und aus $XDG_CONFIG_HOME/git/config, statt aus allen verfügbaren Dateien.
Siehe auch [DATEIEN].
-Bei Schreib-Optionen: schreibt in die systemweite $(prefix)/etc/gitconfig Datei, anstatt im Repository auf .git/config.
Bei Lese-Optionen: nur aus systemweitem $(prefix)/etc/gitconfig lesen, nicht aus allen verfügbaren Dateien.
Siehe auch [DATEIEN].
-Bei Schreib-Optionen: Schreibt in die .git/config Datei des Repositorys. Dies entspricht dem Standardverhalten.
Bei Lese-Optionen: nur aus der Repository .git/config lesen, nicht aus allen verfügbaren Dateien.
Siehe auch [DATEIEN].
-Similar to --local except that $GIT_DIR/config.worktree is read from or written to if extensions.worktreeConfig is enabled. If not it’s the same as --local. Note that $GIT_DIR is equal to $GIT_COMMON_DIR for the main working tree, but is of the form $GIT_DIR/worktrees/<id>/ for other working trees. See git-worktree[1] to learn how to enable extensions.worktreeConfig.
For writing options: write to the specified file rather than the repository .git/config.
For reading options: read only from the specified file rather than from all available files.
-Siehe auch [DATEIEN].
-Analog zu --file, aber benutzt den genannten Blob anstelle einer Datei. Sie können z.B. master:.gitmodules verwenden, um Werte aus der Datei .gitmodules im Master-Branch zu lesen. Siehe den Abschnitt "REVISIONEN SPEZIFIZIEREN" in gitrevisions[7] für eine umfassende Liste von Schreibweisen für Blob-Namen.
Entfernt den angegebenen Abschnitt aus der Konfigurations-Datei.
-Umbenennen des betreffenden Abschnitts auf einen neuen Namen.
-Löscht die Zeile, auf die der Schlüssel passt, aus der Konfigurations-Datei.
-Löscht alle Zeilen, auf die der Schlüssel passt, aus der Konfigurations-Datei.
-Listet alle in der Konfigurations-Datei gesetzten Variablen mit ihren Werten auf.
-When used with the value-pattern argument, treat value-pattern as an exact string instead of a regular expression. This will restrict the name/value pairs that are matched to only those where the value is exactly equal to the value-pattern.
git config sorgt dafür, dass jede Eingabe oder Ausgabe unter der/den angegebenen Typ-Bedingung(en) gültig ist und wird ausgehende Werte in der zulässigen Form von `<Typ>`ausgeben.
-Zulässige Werte von <Typ> enthalten:
bool: die Werte entweder als „wahr“ (true) oder „falsch“ (false) deklarieren.
-int: die Werte als einfache Dezimalzahlen deklarieren. Ein optionales Suffix von k, m oder g bewirkt, dass der Wert der Eingabe mit 1024, 1048576 oder 1073741824 multipliziert wird.
-bool-or-int: entsprechend der obigen Beschreibung entweder nach bool oder int kanonisieren.
-path: kanonisieren durch Hinzufügen einer führenden ~ zum Wert von $HOME und ~user zum Home-Verzeichnis für den angegebenen Benutzer. Dieser Spezifizierer hat keine Auswirkung, wenn ein Wert gesetzt wird (aber Sie können git config section.variable ~/ von der Kommandozeile aus benutzen, um Ihre Shell die Erweiterung durchführen zu lassen)
expiry-date: kanonisieren durch Konvertieren von einem fixen oder relativen Datumsstring in einen Zeitstempel. Diese Angabe hat keine Auswirkung beim Setzen des Wertes.
-color: Wenn Sie einen Wert erhalten, kanonisieren Sie ihn, indem Sie ihn in eine ANSI-Farb-Escape-Sequenz konvertieren. Wenn ein Wert festgelegt wurde, so wird eine Überprüfung durchgeführt, um sicherzustellen, dass der angegebene Wert als ANSI-Farbe kanonisierbar ist, aber er wird so wie er ist ausgegeben.
-Historische Optionen zur Auswahl eines Typ-Bezeichners. Stattdessen sollte man besser --type wählen (siehe oben).
Setzt den zuvor eingestellten Typ-Bezeichner zurück, falls zuvor einer eingestellt war. Diese Option verlangt, dass git config die abgerufene Variable nicht kanonisiert. --no-type hat keine Wirkung ohne --type=<type> oder --<type>.
Für alle Optionen, die Werte und/oder Schlüssel ausgeben, immer die Werte mit einem Null-Zeichen beenden (anstatt eines Zeilenumbruchs). Stattdessen sollte ein Zeilenumbruch als Trennzeichen zwischen Schlüssel und Wert verwendet werden. Dies ermöglicht z.B. ein sicheres Parsen der Ausgabe, ohne durch in den Werten enthaltene Zeilenumbrüche verwirrt zu werden.
-Nur die Namen der Konfigurationsvariablen für --list oder --get-regexp ausgeben.
Die Ausgabe aller abgefragten Konfigurationsoptionen mit dem Origin-Typ (Datei, Standardeingabe, Blob, Kommandozeile) und dem aktuellen Original (Konfigurationsdateipfad, Ref oder Blob-ID, falls zutreffend) erweitern.
-Similar to --show-origin in that it augments the output of all queried config options with the scope of that value (worktree, local, global, system, command).
Find the color setting for <name> (e.g. color.diff) and output "true" or "false". <stdout-is-tty> should be either "true" or "false", and is taken into account when configuration says "auto". If <stdout-is-tty> is missing, then checks the standard output of the command itself, and exits with status 0 if color is to be used, or exits with status 1 otherwise. When the color setting for name is undefined, the command uses color.ui as fallback.
Findet für name die konfigurierte Farbe (z.B. color.diff.new) und gibt sie als ANSI-Farb-Escape-Sequenz für die Standardausgabe aus. Der optionale Parameter default wird stattdessen verwendet, wenn für name keine Farbe konfiguriert ist.
--type=color [--default=<Vorgabe>] wird gegenüber --get-color bevorzugt (bitte aber beachten, dass --get-color den durch --type=color angehängten Zeilenumbruch auslässt).
Öffnet einen Editor, um die angegebene Konfigurationsdatei zu ändern; entweder aus --system, --global, oder dem Repository (die Voreinstellung).
Berücksichtigt include.* Direktiven in Konfigurationsdateien, wenn Werte nachgeschlagen werden. Standardeinstellung ist off, wenn eine bestimmte Datei angegeben wird (z.B. mit --file, --global, usw.) und on, wenn alle Konfigurationsdateien durchsucht werden.
Wird mit --get benutzt. Wenn die angeforderte Variable nicht gefunden wird, dann wird <Wert> so eingesetzt als ob dieser der Variablen zugewiesen wurde.
pager.config wird nur bei der Auflistung der Konfiguration beachtet, d.h. bei der Verwendung von --list oder einem der --get-*, die mehrere Ergebnisse liefern können. Die Voreinstellung ist die Verwendung eines Pagers.
Wenn nicht explizit mit --file verändert, gibt es vier Dateien, in welchen git-config nach Optionen sucht:
Systemweite Konfigurationsdatei.
-Zweite benutzerspezifische Konfigurationsdatei. Wenn $XDG_CONFIG_HOME nicht gesetzt oder leer ist, wird $HOME/.config/git/config verwendet. Jede einwertige Variable, die in dieser Datei gesetzt ist, wird mit dem überschrieben, was in ~/.gitconfig steht. Es empfiehlt sich, diese Datei nicht zu erstellen, wenn manchmal ältere Versionen von Git verwendet werden, da diese Datei erst seit relativ kurzer Zeit unterstützt wird.
Benutzerspezifische Konfigurationsdatei. Auch „globale“ Konfigurationsdatei genannt.
-Spezifische Konfigurationsdatei für das Repository.
-Diese Angabe ist optional und wird nur durchsucht, wenn extensions.worktreeConfig in $GIT_DIR/config vorhanden ist.
Falls keine weiteren Optionen gegeben sind, werden alle Leseoperationen auf allen verfügbaren Dateien ausgeführt. Wenn die globale oder die systemweite Konfigurationsdateien fehlen, werden sie ignoriert. Falls die Konfigurationsdatei des Repositorys nicht verfügbar oder lesbar ist, wird git config mit einem Fehlercode, der nicht null ist, beendet. In beiden Fällen jedoch wird keine Fehlermeldung ausgegeben.
-Die Dateien werden in der oben angegebenen Reihenfolge gelesen, wobei der zuletzt gefundene Wert Vorrang vor früher gelesenen Werten hat. Werden mehrere Werte ermittelt, dann kommen alle Werte eines Schlüssels aus allen Dateien zum Einsatz.
-Einzelne Konfigurationsparameter können beim Ausführen eines git-Befehls mit der Option -c überschrieben werden. Siehe git[1] für weitere Details.
Alle Schreiboptionen schreiben standardmäßig in die Konfigurationsdatei des Repositorys. Beachten Sie, dass dies auch Optionen wie --replace-all und --unset betrifft. git config wird immer nur eine Datei zur gleichen Zeit ändern.
You can override these rules using the --global, --system, --local, --worktree, and --file command-line options; see OPTIONEN above.
Take the configuration from the given files instead from global or system-level configuration. See git[1] for details.
-Legt fest, ob die Leseeinstellungen aus der systemweiten Datei $(prefix)/etc/gitconfig übersprungen werden sollen. Siehe git[1] für Einzelheiten.
-Siehe auch [DATEIEN].
-If GIT_CONFIG_COUNT is set to a positive number, all environment pairs GIT_CONFIG_KEY_<n> and GIT_CONFIG_VALUE_<n> up to that number will be added to the process’s runtime configuration. The config pairs are zero-indexed. Any missing key or value is treated as an error. An empty GIT_CONFIG_COUNT is treated the same as GIT_CONFIG_COUNT=0, namely no pairs are processed. These environment variables will override values in configuration files, but will be overridden by any explicit options passed via git -c.
This is useful for cases where you want to spawn multiple git commands with a common configuration but cannot depend on a configuration file, for example when writing scripts.
-If no --file option is provided to git config, use the file given by GIT_CONFIG as if it were provided via --file. This variable has no effect on other Git commands, and is mostly for historical compatibility; there is generally no reason to use it instead of the --file option.
Angenommen wird folgende .git/config-Datei:
-# -# Dies ist die Konfigurationsdatei und -# ein '#' oder ein ';' stellt einen -# Kommentar dar. -# - -; Kernvariablen -[core] - ; den Dateimodi nicht vertrauen - filemode = false - -; Unser diff-Algorithmus -[diff] - external = /usr/local/bin/diff-wrapper - renames = true - -; Proxyeinstellungen -[core] - gitproxy="proxy-Befehl" für kernel.org - gitproxy=default-proxy ; für den Rest - -; HTTP -[http] - sslVerify -[http "https://weak.example.com"] - sslVerify = false - cookieFile = /tmp/cookie.txt-
Sie können den Dateimodus auf "true" setzen mit
-% git config core.filemode true-
Die hypothetischen Proxy-Befehlseinträge haben tatsächlich ein entsprechendes Anhängsel, um zu erkennen, auf welche URL sie sich beziehen. Hier erfahren Sie, wie Sie den Eintrag für kernel.org in "ssh" ändern können.
-% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'-
Dies stellt sicher, dass nur das Schlüssel/Wertpaar für kernel.org ersetzt wird.
-Um den Eintrag für Umbenennungen zu löschen, verwenden Sie
-% git config --unset diff.renames-
Falls Sie einen Eintrag für eine Multivar (Eine Variable mit mehreren Einträgen, wie core.gitproxy oben), löschen möchten, müssen Sie eine Regex für den Wert exakt einer Zeile angeben.
-Um den Wert für einen gegebenen Schlüssel abzufragen, benutzen Sie
-% git config --get core.filemode-
oder
-% git config core.filemode-
oder, um eine Multivar abzufragen:
-% git config --get core.gitproxy "for kernel.org$"-
Falls Sie alle Werte einer Multivar wissen möchten, verwenden Sie:
-% git config --get-all core.gitproxy-
Wenn Sie gerne gefährlich leben, können Sie alle core.gitproxy-Einträge durch einem neuen ersetzen mit
-% git config --replace-all core.gitproxy ssh-
Wenn Sie jedoch wirklich nur eine Zeile für den Standardproxy verändern möchten, beispielsweise diejenige ohne ein Anhängsel "for …", können Sie dies so tun:
-% git config core.gitproxy ssh '! for '-
Um tatsächlich nur Werte mit einem Ausrufezeichen abzugleichen, müssen Sie
-% git config section.key value '[!]'-
Um einen neuen Proxy hinzuzufügen, ohne einen der vorhandenen Proxys zu ändern, verwenden Sie
-% git config --add core.gitproxy '"proxy-command" for example.com'-
Ein Beispiel, um angepasste Farbe der Konfigurationsdatei in Ihrem Script zu verwenden:
-#!/bin/sh
-WS=$(git config --get-color color.diff.whitespace "blue reverse")
-RESET=$(git config --get-color "" "reset")
-echo "${WS}Ihre Leerzeichen-Farbe oder invertiertes Blau${RESET}"
-Für URLs in https://weak.example.com wird http.sslVerify auf false gesetzt, während es für alle anderen auf true gesetzt wird:
% git config --type=bool --get-urlmatch http.sslverify https://good.example.com -true -% git config --type=bool --get-urlmatch http.sslverify https://weak.example.com -false -% git config --get-urlmatch http https://weak.example.com -http.cookieFile /tmp/cookie.txt -http.sslverify false-
Die Git-Konfigurationsdatei enthält eine Reihe von Variablen, die das Verhalten der Git-Befehle beeinflussen. Die Dateien .git/config und optional config.worktree (siehe den Abschnitt „KONFIGURATIONSDATEI“ in git-worktree[1]) in jedem Repository werden verwendet, um die Konfiguration für dieses Repository zu speichern. Mit $HOME/.gitconfig wird außerdem pro Benutzer eine Konfiguration als Fallback-Werte für die Datei .git/config gespeichert. Die Datei /etc/gitconfig kann verwendet werden, um eine systemweite Standardkonfiguration zu sichern.
Die Konfigurationsvariablen werden sowohl von den "Plumbing"- als auch von den "Porcelain"-Befehlen verwendet. Die Variablen sind in Gruppen unterteilt, wobei der vollqualifizierte Variablenname das Segment nach dem letzten Punkt ist und der Gruppenname alles vor dem letzten Punkt. Die Variablennamen unterscheiden nicht zwischen Groß- und Kleinschreibung, erlauben nur alphanumerische Zeichen und - und müssen mit einem alphanumerischen Zeichen beginnen. Einige Variablen dürfen mehrmals vorkommen; wir sagen dann, die Variable ist mehrwertig.
-Die Syntax ist ziemlich flexibel und tolerant; Leerzeichen werden größtenteils ignoriert. Die Zeichen # und ; beginnen Kommentare bis zum Zeilenende, Leerzeilen werden ignoriert.
-Die Datei besteht aus Gruppen und Variablen. Eine Gruppe beginnt mit dem Gruppennamen in eckigen Klammern und geht bis zum nächsten Gruppenanfang. Gruppennamen unterscheiden keine Groß- und Kleinschreibung. Nur alphanumerische Zeichen, - und . sind in Gruppennamen erlaubt. Jede Variable muss zu einer Gruppe gehören, was bedeutet, dass eine Gruppenüberschrift vor der ersten Variablenzuweisung zwingend ist.
-Gruppen können weiter in Untergruppen unterteilt werden. Um eine Untergruppe zu beginnen, schreiben Sie ihren Namen in doppelten Anführungszeichen, durch ein Leerzeichen vom Gruppentitel getrennt, wie in folgendem Beispiel:
-[Gruppe "Untergruppe"]-
Subsection names are case sensitive and can contain any characters except newline and the null byte. Doublequote " and backslash can be included by escaping them as \" and \\, respectively. Backslashes preceding other characters are dropped when reading; for example, \t is read as t and \0 is read as 0. Section headers cannot span multiple lines. Variables may belong directly to a section or to a given subsection. You can have [section] if you have [section "subsection"], but you don’t need to.
Es gibt außerdem die veraltete [Gruppe.Untergruppe]-Syntax. Mit dieser Syntax wird der Untergruppenname in Kleinbuchstaben konvertiert und unterscheidet dann auch zwischen Groß- und Kleinschreibung. Diese Untergruppennamen folgen den gleichen Einschränkungen wie Gruppennamen.
-Alle anderen Zeilen (und der Rest der Zeile nach der Gruppenüberschrift) werden als Einstellungsvariablen erkannt, in der Form Name = Wert (oder nur Name, was bedeutet, der Wert der Variable ist "true"). Die Variablennamen unterscheiden zwischen Groß- und Kleinschreibung, dürfen nur alphanumerische Zeichen und - enthalten und müssen mit einem alphanumerischen Zeichen beginnen.
-A line that defines a value can be continued to the next line by ending it with a \; the backslash and the end-of-line are stripped. Leading whitespaces after name =, the remainder of the line after the first comment character # or ;, and trailing whitespaces of the line are discarded unless they are enclosed in double quotes. Internal whitespaces within the value are retained verbatim.
Zwischen doppelten Anführungszeichen müssen doppelte Anführungszeichen " und Rückwärtsschrägstriche \ escaped werden: \" für " und \\ für \.
-Die folgenden Escape-Sequenzen (neben \" und \\) werden erkannt: \n als Zeilenumbruch (NL), \t für Tab (HT, TAB) und \b für Backspace (BS). Andere Escape-Sequenzen (auch oktale Escape-Sequenzen) sind ungültig.
-Die Abschnitte include und includeIf erlauben es Ihnen, Konfigurationsanweisungen aus einer anderen Quelle einzubinden. Diese Abschnitte verhalten sich identisch zueinander mit der Ausnahme, dass die Abschnitte includeIf ignoriert werden können, wenn ihre Bedingung nicht als „true“ erkannt wird; siehe „Bedingte Includes“ weiter unten.
Sie können eine Konfigurationsdatei aus einer anderen Quelle einbinden, indem Sie die spezielle Variable include.path (oder includeIf.*.path) auf den Namen der einzubindenden Datei setzen. Die Variable nimmt einen Pfadnamen als Wert an und berücksichtigt die Tilde-Erweiterung. Diese Variablen können mehrfach angegeben werden.
Der Inhalt der eingebundenen Datei wird sofort eingefügt, so als ob er an der Stelle der Include-Anweisung gefunden worden wäre. Wenn der Wert der Variablen ein relativer Pfad ist, wird der Pfad als relativ zu der Konfigurationsdatei angesehen, in der die Include-Anweisung gefunden wurde. Siehe Beispiele weiter unten.
-Sie können eine Konfigurationsdatei aus einer anderen bedingt einbinden, indem Sie eine includeIf.<Bedingung>.path Variable auf den Namen der einzubindenden Datei setzen.
Die Bedingung beginnt mit einem Schlüsselwort, gefolgt von einem Doppelpunkt und einigen Daten, deren Format und Bedeutung vom Schlüsselwort abhängt. Gültige Schlüsselwörter sind:
-gitdir Die Daten, die dem Schlüsselwort gitdir: folgen, werden als Glob-Pattern verwendet. Wenn die Position des Verzeichnisses .git mit dem Pattern übereinstimmt, ist die Include-Bedingung erfüllt.
The .git location may be auto-discovered, or come from $GIT_DIR environment variable. If the repository is auto discovered via a .git file (e.g. from submodules, or a linked worktree), the .git location would be the final location where the .git directory is, not where the
-.git-Datei befindet.
Das Suchmuster kann Standard-Globbing-Platzhalter und zwei zusätzliche Platzhalter, **/ und /**, enthalten, die mit mehreren Pfadkomponenten übereinstimmen könnten. Bitte lesen Sie gitignore[5] für weitere Details. Der Einfachheit halber:
Beginnt das Pattern mit ~/, so wird das ~ durch den Inhalt der Umgebungsvariablen HOME ersetzt.
Beginnt das Pattern mit ./, so wird es durch das Verzeichnis ersetzt, das die aktuelle Konfigurationsdatei enthält.
Beginnt das Pattern weder mit ~/, ./ noch mit /, wird automatisch ein **/ vorangestellt. Zum Beispiel wird das Suchmuster foo/bar zu **/foo/bar und würde mit /irgendein/Pfad/zu/foo/bar übereinstimmen.
Endet das Pattern mit /, so wird automatisch ** hinzugefügt. Beispielsweise wird das Suchmuster foo/ zu foo/**. Mit anderen Worten, es stimmt rekursiv mit „foo“ und allem, was sich darin befindet, überein.
gitdir/i Das entspricht gitdir, außer dass der Abgleich ohne Berücksichtigung von Groß- und Kleinschreibung erfolgt (z.B. auf Dateisystemen ohne diese Unterscheidung)
onbranch Die Daten, die dem Schlüsselwort onbranch: folgen, werden als ein Pattern mit Standard-Globbing-Platzhaltern und zwei zusätzlichen Platzhaltern, **/ und /**, verstanden, die mit mehreren Pfadkomponenten übereinstimmen könnten. Wenn wir uns in einem Arbeitsbereich befinden, in dem der Name des Branches, der gerade ausgecheckt wird, mit dem Suchmuster übereinstimmt, ist die Include-Bedingung erfüllt.
Endet das Pattern mit /, wird automatisch ** hinzugefügt. Zum Beispiel wird das Muster foo/ zu foo/**. Mit anderen Worten, es passt auf alle Branches, die mit foo/ beginnen. Das ist dann hilfreich, wenn Ihre Branches hierarchisch organisiert sind und Sie eine Konfiguration auf alle Branches in dieser Hierarchie anwenden möchten.
Noch ein paar Anmerkungen zum Vergleichen über gitdir und gitdir/i:
Symlinks in $GIT_DIR werden vor dem Abgleich nicht ausgewertet.
Sowohl die Symlink- als auch die Realpfad-Versionen der Pfadangaben werden außerhalb von $GIT_DIR abgeglichen. Wenn z.B. ~/git ein Symlink zu /mnt/storage/git wäre, dann würden beide Versionen von gitdir:~/git und gitdir:/mnt/storage/git übereinstimmen.
Dies war bei der ursprünglichen Version dieses Features in v2.13.0 nicht der Fall, welche nur der realpath-Version entsprochen hat. Eine Konfiguration, die mit der ursprünglichen Version dieses Features kompatibel sein will, muss entweder nur die realpath-Version oder beide Versionen angeben.
-Beachten Sie, dass "../" nichts Besonderes ist und wortwörtlich übereinstimmen wird, was vermutlich nicht das ist, was Sie erreichen wollen.
-# Kernvariablen -[core] - ; Vertraue den Dateimodi nicht - filemode = false - -# Unser diff-Algorithmus -[diff] - external = /usr/local/bin/diff-wrapper - renames = true - -[branch "devel"] - remote = origin - merge = refs/heads/devel - -# Proxyeinstellungen -[core] - gitProxy="ssh" for kernel.org - gitProxy=default-proxy ; für den Rest - -[include] - path = /path/to/foo.inc ; über den absoluten Pfad einbinden - path = foo.inc ; finde "foo.inc" relativ zur aktuellen Datei - path = ~/foo.inc ; finde "foo.inc" im `$HOME` Verzeichnis - -; einbinden, falls $GIT_DIR /Pfad/zu/foo/.git ist -[includeIf "gitdir:/Pfad/zu/foo/.git"] - path = /Pfad/zu/foo.inc - -; alle Repositories innerhalb von /Pfad/zur/Gruppe einbinden -[includeIf "gitdir:/Pfad/zur/Gruppe"] - path = /Pfad/zu/foo.inc - -; einbinden, für alle Repositorys innerhalb von $HOME/zur/Gruppe -[includeIf "gitdir:~/zur/Gruppe/"] - path = /Pfad/zu/foo.inc - -; relative Pfade sind immer relativ zu der einschließenden -; Datei (wenn die Bedingung wahr ist); ihr Speicherort -; wird von der Bedingung nicht beeinflusst -[includeIf "gitdir:/Pfad/zur/Gruppe/"] - path = foo.inc - -; nur dann einbinden, wenn wir uns in einem Arbeitsbereich -; befinden, in dem foo-branch gerade ausgecheckt wird -[includeIf "onbranch:foo-branch"] - path = foo.inc-
Die Werte vieler Variablen werden als einfache Zeichenfolge behandelt, aber es gibt Variablen, die Werte bestimmter Typen annehmen und es gibt Richtlinien, wie sie zu formulieren sind.
-Wenn eine Variable einen Wahrheitswert annehmen soll, werden viele Synonyme für true oder false akzeptiert; Groß- und Kleinschreibung wird dabei nicht beachtet.
-Boolean true literals are yes, on, true, and 1. Also, a variable defined without = <value> is taken as true.
Boolean false literals are no, off, false, 0 and the empty string.
Bei der Konvertierung eines Wertes in seine kanonische Form unter Verwendung des --type=bool Typ-Bezeichners wird git config die Ausgabe "true" oder "false" (in Kleinbuchstaben geschrieben) ausgeben.
Der Wert für viele Variablen, die unterschiedliche Größen angeben, kann mit den Suffixen k, M, … versehen werden. Das bedeutet, dass die Zahl "mit 1024", "mit 1024x1024", … skaliert wird.
Der Wert für eine Variable, die eine Farbe darstellt, ist eine durch Leerzeichen getrennte Liste von Farben (maximal zwei, einmal Vordergrund und einmal Hintergrund) und von Attributen (unbegrenzt viele).
-The basic colors accepted are normal, black, red, green, yellow, blue, magenta, cyan, white and default. The first color given is the foreground; the second is the background. All the basic colors except normal and default have a bright variant that can be specified by prefixing the color with bright, like brightred.
The color normal makes no change to the color. It is the same as an empty string, but can be used as the foreground color when specifying a background color alone (for example, "normal red").
The color default explicitly resets the color to the terminal default, for example to specify a cleared background. Although it varies between terminals, this is usually not the same as setting to "white black".
Farben können auch als Zahlen zwischen 0 und 255 angegeben werden; diese verwenden den ANSI-256-Farbmodus (beachten Sie jedoch, dass dies möglicherweise nicht von allen Terminals unterstützt wird). Wenn Ihr Terminal dies unterstützt, können Sie auch 24-bit RGB-Werte als Hex-Wert angeben, wie z.B. #ff0ab3.
Die akzeptierten Attribute sind bold, dim, ul, blink, reverse, italic und strike (für durchgekreuzte oder durchgestrichene Zeichen). Die Position jeglicher Attribute in Bezug auf die Farben (vor, nach oder zwischen den Farben) spielt keine Rolle. Bestimmte Attribute können abgeschaltet werden, indem man ihnen no oder no- voranstellt (z.B. noreverse, no-ul, usw.).
The pseudo-attribute reset resets all colors and attributes before applying the specified coloring. For example, reset green will result in a green foreground and default background without any active attributes.
Ein leerer Farb-String erzeugt überhaupt keinen Farbeffekt. Damit kann das Einfärben bestimmter Elemente vermieden werden, ohne die Farbe vollständig zu deaktivieren.
-Für die vordefinierten Farbslots von Git sollen die Attribute am Anfang jedes Elements in der farbigen Ausgabe zurückgesetzt werden. Wenn Sie also color.decorate.branch auf black setzen, wird dieser Branch-Name in schlichtem „schwarz“ dargestellt, selbst wenn die vorherige Sache in der gleichen Ausgabezeile (z.B. öffnende Klammer vor der Liste der Branch-Namen in der log --decorate Ausgabe) mit bold oder einem anderen Attribut dargestellt wird. Benutzerdefinierte Protokollformate können jedoch eine kompliziertere und überlagerte Farbgebung bewirken, und die negierten Formen könnten dort nützlich sein.
Einer Variablen, die einen Pfadnamen-Wert annimmt, kann ein String übergeben werden, der mit "~/" oder "~user/" beginnt. Die übliche Tilde-Erweiterung kommt bei einem solchen String zur Anwendung: ~/ wird auf den Wert von $HOME erweitert, und ~user/ auf das Home-Verzeichnis des angegebenen Benutzers.
If a path starts with %(prefix)/, the remainder is interpreted as a path relative to Git’s "runtime prefix", i.e. relative to the location where Git itself was installed. For example, %(prefix)/bin/ refers to the directory in which the Git executable itself lives. If Git was compiled without runtime prefix support, the compiled-in prefix will be substituted instead. In the unlikely event that a literal path needs to be specified that should not be expanded, it needs to be prefixed by ./, like so: ./%(prefix)/bin.
Beachten Sie, dass diese Liste nicht ausführlich und nicht unbedingt vollständig ist. Für kommando-spezifische Variablen finden Sie eine ausführlichere Beschreibung in der entsprechenden Manpage.
-Andere Git-Tools können und werden ihre eigenen Variablen verwenden. Wenn Sie neue Variablen für die Verwendung in Ihrem eigenen Dienstprogramm entwickeln, stellen Sie sicher, dass deren Namen nicht in Konflikt mit denen stehen, die von Git selbst und anderen beliebten Hilfsprogrammen verwendet werden. Beschreiben Sie diese Variablen in Ihrer Dokumentation.
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Bei Verwendung der veralteten Syntax [section.subsection] führt die Änderung eines Wertes dazu, dass ein mehrzeiliger Schlüssel anstelle einer Änderung hinzugefügt wird, falls der Unterabschnitt mit mindestens einem Großbuchstaben angegeben wird. Wenn beispielsweise die Konfiguration wie folgt aussieht
[section.subsection] - key = value1-
und die Ausführung von git config section.Subsection.key value2 ergibt
[section.subsection] - key = value1 - key = value2-
Teil der git[1] Suite
-git config [<opção-do-arquivo>] [--type=<tipo>] [--fixed-value] [--show-origin] [--show-scope] [-z|--null] <nome> [<valor> [<value-pattern>]] -git config [<opção-do-arquivo>] [--type=<tipo>] --add <nome> <valor> -git config [<opção-do-arquivo>] [--type=<tipo>] [--fixed-value] --replace-all <nome> <valor> [<value-pattern>] -git config [<opção-do-arquivo>] [--type=<tipo>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get <nome> [<value-pattern>] -git config [<opção-do-arquivo>] [--type=<tipo>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get-all <nome> [<value-pattern>] -git config [<opção-do-arquivo>] [--type=<tipo>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] [--name-only] --get-regexp <nome_regex> [<value-pattern>] -git config [<opção-do-arquivo>] [--type=<tipo>] [-z|--null] --get-urlmatch <nome> <URL> -git config [<opção-do-arquivo>] [--fixed-value] --unset <nome> [<value-pattern>] -git config [<opção-do-arquivo>] [--fixed-value] --unset-all <nome> [<value-pattern>] -git config [<opção-do-arquivo>] --rename-section <nome_antigo> <novo_nome> -git config [<opção-do-arquivo>] --remove-section <nome> -git config [<opção-do-arquivo>] [--show-origin] [--show-scope] [-z|--null] [--name-only] -l | --list -git config [<opção-do-arquivo>] --get-color nome [<default>] -git config [<opção-do-arquivo>] --get-colorbool <nome> [<stdout-is-tty>] -git config [<opção-do-arquivo>] -e | --edit-
Você pode consultar, definir, substituir e remover opções com este comando. Na verdade o nome é a seção e a chave são separadas por um ponto, e seu valor será escapado.
-Várias linhas podem ser adicionadas a uma opção usando a opção --add. Caso queira atualizar ou cancelar uma opção que possa ocorrer em diversas linhas, será necessário fornecer um valor predefinido (que é uma expressão regular estendida, a menos que a opção --fixed-value seja usada). Somente os valores existentes que correspondem ao padrão são atualizados ou são desmarcados. Caso queira tratar as linhas que não correspondam ao padrão, basta acrescentar um único ponto de exclamação na frente (consulte também EXEMPLOS), mas observe que isso só funciona quando a opção --fixed-value não estiver em uso.
A opção --type=<tipo> instrui o comando git config para garantir que os valores de entrada e na saída sejam canonizados sob o <tipo> informado. Quando nenhum --type=<tipo> é informado, nenhuma canonização será executada. Aqueles que os invocarem podem cancelar a definição de um especificador --type já existente com a opção --no-type.
A leitura destes valores são lidos do sistema nos arquivos de configuração global local e do repositório, é predefinido que as opções --system, --global, --local, --worktree e --file possam ser utilizadas para dizer ao comando para ler somente deste local (consulte ARQUIVOS).
Durante a escrita, é predefinido que o novo valor é gravado no arquivo de configuração local do repositório e as opções --system, --global, --worktree, --file possam ser utilizadas para dizer ao comando para gravar nesse local (você pode dizer --local, porém esta é a predefinição).
Este comando falhará coma condição diferente de zero em caso de erro. Alguns códigos de encerramento são:
-A seção ou chave é inválida (ret=1),
nenhuma seção ou nome foi informado (ret=2),
o arquivo de configuração é inválido (ret=3),
o arquivo de configuração não pode ser gravado (ret=4),
você tenta desmarcar uma opção que não existe (ret=5),
você tenta desmarcar ou definir uma opção para a qual várias linhas coincidem (ret=5) ou
você tenta usar um regexp inválido (ret=6).
Em casos bem sucedidos o comando retorna o código 0.
-A lista todas as variáveis de configuração disponíveis pode ser obtida utilizando o comando git help --config.
O comportamento predefinido é substituir pelo menos uma linha. Isso substitui todas as linhas que coincidam com a chave (e opcionalmente ao value-pattern).
Adiciona uma nova linha à opção sem alterar os valores já existentes. Isso é o mesmo que usar ^$ como o value-pattern em --replace-all.
Obtenha o valor para uma determinada chave (opcionalmente filtrada por uma expressão regular que coincida com o valor). Retorna o código de erro 1 caso a chave não seja encontrada e o último valor caso vários valores da chave sejam encontrados.
-Como get, mas retorna todos os valores para uma chave com vários valores.
-Como --get-all, contudo, interpreta o nome como uma expressão regular e registra os nomes das chaves. Atualmente, a correspondência das expressões regulares diferencia maiúsculas de minúsculas sendo feita em relação a uma versão canonizada da chave onde os nomes das seções e das variáveis são minúsculos, mas os nomes de subseções não são.
Quando é usado um <nome> com duas partes como <seção>.<chave>, é retornado o valor <seção>.<URL>.<chave> cuja parte <URL> corresponda melhor ao URL fornecido (caso este valor não exista, o valor de <seção>.<chave> será usado como contingência). Quando receber apenas a <seção> como o nome, faça isso para todas as chaves na seção e liste-as. Retorna o código de erro 1 caso nenhum valor seja encontrado.
Para escrever opções: escreva para o arquivo global ~/.gitconfig em vez do repositório .git/config, escreva para o arquivo $XDG_CONFIG_HOME/git/config se este arquivo existir e o arquivo ~/.gitconfig não faz.
Para opções de leitura: leia somente do global ~/.gitconfig e de` $XDG_CONFIG_HOME/git/config` ao invés de todos os arquivos disponíveis.
Consulte também ARQUIVOS.
-Para opções de escrita: escreva para o $(prefix)/etc/gitconfig do sistema em vez do repositório .git/config.
Para opções de leitura: leia somente do $(prefix)/etc/gitconfig em todo o sistema, e não de todos os arquivos disponíveis.
Consulte também ARQUIVOS.
-Para opções de escrita: escreva no arquivo .git/config do repositório. Este é o comportamento predefinido.
Para as opções da leitura: leia somente no repositório .git/config em vez de todos os arquivos disponíveis.
Consulte também ARQUIVOS.
-Similar ao comando --local exceto quando o $GIT_DIR/config.worktree for lido ou escrito e se extensions.worktreeConfig estiver ativado. Se não estiver, é o mesmo que a opção --local. Observe que $GIT_DIR é igual a $GIT_COMMON_DIR para a árvore principal de trabalho, mas é da forma $GIT_DIR/worktrees/<id>/ nas outras árvores de trabalho. Consulte git-worktree[1] para aprender como ativar o extensions.worktreeConfig.
Para as opções de escrita: escreva no arquivo definido em vez do repositório .git/config.
Para as opções da leitura: leia somente no arquivo definido em vez de todos os arquivos disponíveis.
-Consulte também ARQUIVOS.
-É semelhante à opção --file, mas usa bolha informada em vez de um arquivo. Por exemplo, você pode usar master:.gitmodules para ler os valores do arquivo .gitmodules na ramificação "master". Consulte a seção "DEFININDO AS REVISÕES" do comando gitrevisions[7] para obter uma lista mais completa das diferentes maneiras de se escrever os nomes das bolhas.
Remova a seção dada do arquivo de configuração.
-Renomeie a seção dada para um novo nome.
-Remove do arquivo de configuração a linha correspondente à chave.
-Remove do arquivo de configuração todas as linhas que correspondam à chave.
-Lista todas as variáveis definidas no arquivo de configuração, junto com seus valores.
-Quando utilizado com o argumento value-pattern, trate o value-pattern como uma string exata em vez de uma expressão regular. Isto restringirá os pares nome e o valor que são coincididos apenas com aqueles onde o valor é exatamente igual ao value-pattern.
git config irá assegurar que qualquer entrada ou saída é válida sob a(s) restrição(ões) de tipo dada, e irá canonicalizar os valores de saída na forma canônica do <tipo>'s.
Os <tipo>'s válidos incluem:
bool: canoniza os valores como true ou false.
-int: canoniza os valores como números decimais simples. Um sufixo opcional com k, m ou g fará com que o valor seja multiplicado por 1024, 1048576 ou 1073741824 na entrada.
-bool-or-int: canoniza de acordo com bool ou int, como descrito acima.
-path: canonize ao adicionar um sinal ~ no começo para o valor $HOME e ~user no diretório home do usuário especificado. Este especificador não tem efeito durante a definição do valor (porém você pode utilizar o comando git config section.variable ~ / na linha de comando para permitir que o seu shell faça a expansão.)
data validade: canoniza convertendo a partir de uma cadeia com data fixa ou relativa a um registro de data e hora. Este especificador não tem efeito quando for definir o valor.
-color: Quando obtiver um valor, canonize através da conversão para uma sequência no padrão ANSI de cor. Ao definir um valor, uma verificação é realizada para garantir que o valor informado seja canonizável como uma cor ANSI, porém será escrito como estiver.
-Opções históricas para selecionar um especificador de tipo. Em vez disso, prefira opção --type (veja acima).
Desmarca o especificador de tipo definido anteriormente (caso tenha sido definido antes). Essa opção solicita que o comando git config não canonize a variável recuperada. --no-type não tem efeito sem a opção --type=<tipo> ou --<tipo>.
Para todas as opções que gerem valores e/ou chaves, sempre finalize os valores com o caractere nulo (em vez de uma nova linha). Utilize a nova linha como um delimitador entre chave e valor. Isso permite uma análise segura do que for gerado sem se confundir, por exemplo, através de valores que tenham quebras de linha.
-Gere apenas os nomes das variáveis de configuração para --list ou --get-regexp.
Aumente a geração de todas as opções de configuração consultadas com o tipo da origem (arquivo, entrada padrão, blob, linha de comando) e a origem real (o caminho do arquivo de configuração, da "ref" ou a ID da bolha, caso seja aplicável).
-Semelhante a opção --show-origin, na medida em que aumenta a saída de todas as opções de configuração consultadas com o escopo deste valor (worktree, local, global, system, command).
Localize a configuração de cor para <nome> (color.diff por exemplo) e mostre true ou false. <stdout-is-tty> deve ser true ou false sendo levado em consideração quando a configuração for auto. Se <stdout-is-tty> estiver ausente, a saída padrão do próprio comando será verificada e encerrará com a condição 0 se a cor for usada, ou caso contrário, encerrará com a condição 1. Quando a configuração de cor para name for indefinida, o comando usa color.ui como contingência.
Localize a cor configurada para name (color.diff.new por exemplo) e emita-a como a uma sequência de escape com cores ANSI na saída predefinida. O parâmetro opcional default é usado em seu lugar, caso não haja nenhuma cor configurada para name.
--type=color [--default=<default>] é preferível em vez de --get-color (porém repare que a opção --get-color omitirá a nova linha impressa por --type=color).
Abre um editor para alterar o arquivo de configuração informado; ou --system, --global ou repositório (predefinido).
Respeite as diretivas include.* nos arquivos de configuração ao procurar pelos valores. A predefinição retorna para off quando determinado arquivo seja informado (por exemplo, usando os comandos --file, --global, etc) e ao pesquisar por todos os arquivos de configuração.
Ao usar --get e a variável solicitada não for encontrada, comportar-se como se o <valor> fosse o valor atribuído à variável.
O pager.config só é respeitado ao listar a configuração, ou seja, ao usar --list ou qualquer um dos --get-* que podem retornar vários resultados. A predefinição é usar um pager.
É predefinido que o comado git config leia as opções de configuração a partir de diversos arquivos:
-Arquivo de configuração do sistema.
-Arquivos de configuração específicos do usuário. Quando a variável de ambiente XDG_CONFIG_HOME não estiver definida ou estiver vazia, $HOME/.config/ será usado como $XDG_CONFIG_HOME.
-Eles também são chamados de arquivos de configuração "globais". Caso ambos existam, eles serão lidos na ordem indicada acima.
-Arquivo de configuração específico do repositório.
-Isso é opcional e só é pesquisado quando o arquivo extensions.worktreeConfig está presente em $GIT_DIR/config.
Você também poderá fornecer parâmetros adicionais de configuração ao executar qualquer comando git usando a opção -c. Consulte git[1] para obter mais detalhes.
As opções serão lidas a partir de todos os arquivos disponíveis. Caso os arquivos de configuração global ou de todo o sistema estiverem ausentes ou ilegíveis, eles serão ignorados. Se o arquivo de configuração do repositório estiver ausente ou ilegível, o comando git config encerrará com um código de erro diferente de zero. Uma mensagem de erro será produzida caso o arquivo esteja ilegível, mas não se estiver ausente.
-Os arquivos são lidos na ordem indicada acima, com o último valor encontrado tendo precedência sobre os valores lidos anteriormente. Quando vários valores são obtidos, serão usados todos os valores de uma chave de todos os arquivos.
-É predefinido que as opções sejam gravadas apenas no arquivo específico de configuração do repositório. Observe que isso também afeta opções como --replace-all e --unset. O comando git config só alterará um arquivo por vez.
Você pode limitar quais fontes de configuração são lidas ou quais serão gravadas ao definir o caminho de um arquivo com a opção --file ou especificando um escopo de configuração com a opção --system, --global, --local ou --worktree. Para mais informações, consulte OPÇÕES acima.
Cada fonte de configuração está dentro de um escopo de configuração. Os escopos são:
-$(prefix)/etc/gitconfig
-$XDG_CONFIG_HOME/git/config
-~/.gitconfig
-$GIT_DIR/config
-$GIT_DIR/config.worktree
-GIT_CONFIG_{COUNT,KEY,VALUE} variáveis de ambiente (consulte VARIÁVEIS DO AMBIENTE abaixo)
-a opção -c
Com exceção do command, cada escopo corresponde a uma opção da linha de comando: --system, --global, --local, --worktree.
Ao ler as opções, ao especificar um escopo lerá apenas as opções dos arquivos que estejam dentro deste escopo. Ao gravar as opções, ao especificar um escopo ele será gravado nos arquivos dentro deste escopo (em vez do arquivo de configuração específico do repositório). Consulte OPÇÕES acima para obter uma descrição completa.
-Independentemente da definição do escopo, a maioria das opções de configuração são respeitadas, porém, algumas opções são respeitadas apenas em determinados escopos. Consulte a documentação da respectiva opção para obter mais informações.
-A configuração protegida refere-se aos escopos system, global e command. Por motivos de segurança, determinadas opções são respeitadas somente quando são especificadas numa configuração protegida, caso contrário são ignoradas.
-O Git trata estes escopos como se fossem controlados pelo usuário ou por um administrador confiável. Isso ocorre porque um invasor que controla esses escopos pode causar danos substanciais sem usar o Git, portanto, presume-se que o ambiente do usuário proteja estes escopos contra invasores.
-Obtenha a configuração dos arquivos informados em vez da configuração global ou no nível do sistema. Para mais detalhes, consulte git[1].
-Independente se você vai ignorar as configurações de leitura do arquivo $(prefix)/etc/gitconfig do sistema. Para mais detalhes, consulte git[1].
Consulte também ARQUIVOS.
-Caso GIT_CONFIG_COUNT seja definido como um número positivo, todos os pares do ambiente GIT_CONFIG_KEY_<n> e GIT_CONFIG_VALUE_<n> até esse número serão adicionados à configuração durante a execução do processo. Os pares de configuração são indexados por zero. Qualquer chave ou valor ausente são tratados como erro. Um GIT_CONFIG_COUNT vazio é tratado da mesma maneira que GIT_CONFIG_COUNT=0, ou seja, nenhum par é processado. Estas variáveis de ambiente substituirão os valores nos arquivos de configuração, mas serão substituídas por quaisquer opções explícitas passadas através do comando git -c.
É útil para os casos onde você queira gerar vários comandos git com uma configuração comum, porém não pode depender de um arquivo de configuração, ao escrever scripts por exemplo.
-Caso nenhuma opção --file seja usada com git config, utilize o arquivo fornecido por GIT_CONFIG como se ele fosse fornecido através da opção --file. Esta variável não tem efeito nos outros comandos Git e é principalmente utilizado por questão de compatibilidade histórica; geralmente não há motivo para utilizá-lo no lugar da opção ‘--file’.
Dado um .git/config como este:
-# -# Este é o arquivo de configuração e -# um caractere '#' ou ';' serve como -# um comentário -# - -; variáveis principais -[core] - ; Não confie nos modos dos arquivos - filemode = false - -; Nosso próprio algorítimo diff -[diff] - external = /usr/local/bin/diff-wrapper - renames = true - -; Configurações de proxy -[core] - gitproxy=proxy-command for kernel.org - gitproxy=default-proxy ; for all the rest - -; HTTP -[http] - sslVerify -[http "https://weak.example.com"] - sslVerify = false - cookieFile = /tmp/cookie.txt-
você pode definir o filemode como true com
% git config core.filemode true-
As hipotéticas entradas de comando do proxy realmente têm um postfix para discernir a qual URL elas se aplicam. Aqui um exemplo de como alterar a entrada do kernel.org para "ssh".
-% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'-
Isso garante que apenas o par de chave/valor do kernel.org seja substituído.
-Para excluir a entrada para renomear, faça
-% git config --unset diff.renames-
Caso queira excluir uma entrada para um "multivar" (como core.gitproxy acima), é necessário fornecer um regex que coincida com o valor exato de uma linha.
Para consultar o valor para uma determinada chave, faça
-% git config --get core.filemode-
ou
-% git config core.filemode-
ou, para consultar um multivar:
% git config --get core.gitproxy "for kernel.org$"-
Caso queira conhecer todos os valores de um multivar, faça:
% git config --get-all core.gitproxy-
Caso queira viver perigosamente, é possível substituir all core.gitproxy por um novo com
% git config --replace-all core.gitproxy ssh-
No entanto, caso queira realmente substituir apenas a linha pelo proxy predefinido, ou seja, aquele sem um "for …" postfix, faça algo assim:
% git config core.gitproxy ssh '! for '-
Para que haja a real coincidência apenas com os valores de um ponto de exclamação, é necessário
-% git config section.key value '[!]'-
Para adicionar um novo proxy, sem alterar qualquer outro já existente, utilize
-% git config --add core.gitproxy '"proxy-command" for example.com'-
Um exemplo para usar cores personalizadas da configuração em seu script:
-#!/bin/sh
-WS=$(git config --get-color color.diff.whitespace "blue reverse")
-RESET=$(git config --get-color "" "reset")
-echo "${WS}your whitespace color or blue reverse${RESET}"
-Para URLSs em https://weak.example.com, http.sslVerify está definido como false, enquanto está definido para true para todos os outros:
% git config --type=bool --get-urlmatch http.sslverify https://good.example.com -true -% git config --type=bool --get-urlmatch http.sslverify https://weak.example.com -false -% git config --get-urlmatch http https://weak.example.com -http.cookieFile /tmp/cookie.txt -http.sslverify false-
O arquivo de configuração do Git contém várias variáveis que afetam o comportamento dos comandos do Git. Os arquivos .git/config e opcionalmente config.worktree (consulte a seção "ARQUIVO DE CONFIGURAÇÃO" do git-worktree[1]) em cada repositório são utilizados para armazenar a configuração para aquele repositório e o $HOME/.gitconfig é utilizado para armazenar uma configuração por usuário como valores alternativos para o arquivo .git/config. O arquivo /etc/gitconfig pode ser utilizado para armazenar a predefinição de uma configuração em todo o sistema.
As variáveis de configuração são usadas pelos comandos Git plumbing e porcelain. As variáveis são divididas em seções, sendo que o nome na variável totalmente qualificada da própria variável é o último segmento separado por pontos e o nome da seção é tudo o que vem antes do último ponto. Os nomes das variáveis não diferenciam maiúsculas de minúsculas, permitem apenas caracteres alfanuméricos e -, devem começar com um caractere alfabético. Algumas variáveis podem aparecer diversas vezes; dizemos então que a variável é multivalorada.
The syntax is fairly flexible and permissive. Whitespace characters, which in this context are the space character (SP) and the horizontal tabulation (HT), are mostly ignored. The # and ; characters begin comments to the end of line. Blank lines are ignored.
-O arquivo consiste em seções e variáveis. Uma seção começa com o nome da seção entre colchetes e continua até o início da próxima seção. Os nomes das seções não diferenciam maiúsculas de minúsculas. Apenas caracteres alfanuméricos, - e . são permitidos nos nomes das seções. Cana variável deve pertencer a alguma seção, o que significa que deve haver um cabeçalho da seção antes da primeira configuração de uma variável.
As seções podem ser divididas em subseções. Para iniciar uma subseção, coloque seu nome entre aspas duplas, separado pelo espaço do nome da seção no cabeçalho da seção, como mostra o exemplo abaixo:
-[seção "subseção"]-
Os nomes da subseção diferem maiúsculas de minúsculas e podem conter qualquer caractere, exceto o caracter de nova linha e byte nulo. Aspas duplas " e a barra invertida podem ser incluídas escapando-as como \\" e \\, respectivamente. As barras invertidas que precedam outros caracteres, são eliminadas durante a leitura; por exemplo, t e \0 são lidos como 0. Os cabeçalhos da seção não podem abranger diversas linhas. As variáveis podem pertencer diretamente a uma seção ou a uma determinada subseção. Você pode ter [seção] se tiver [seção "subseção"], mas não é necessário.
Também existe uma sintaxe obsoleta [section.subsection]. Com esta sintaxe o nome da subseção é convertido em minúsculas e também é comparado com distinção entre maiúsculas e minúsculas. Estes nomes de subseções seguem as mesmas restrições que os nomes de seção.
Todas as outras linhas (e o restante da linha após o cabeçalho da seção) são reconhecidas como variáveis de definição, no formulário name = valor (ou apenas name, que é um atalho para dizer que a variável é um booleano "true"). Os nomes das variáveis não diferenciam maiúsculas de minúsculas, permitem apenas caracteres alfanuméricos e -, devem começar com um caractere alfabético.
Whitespace characters surrounding name, = and value are discarded. Internal whitespace characters within value are retained verbatim. Comments starting with either # or ; and extending to the end of line are discarded. A line that defines a value can be continued to the next line by ending it with a backslash (\); the backslash and the end-of-line characters are discarded.
If value needs to contain leading or trailing whitespace characters, it must be enclosed in double quotation marks ("). Inside double quotation marks, double quote (") and backslash (\) characters must be escaped: use \" for " and \\ for \.
As seguintes sequências com caracteres de escape (além de \" e \\) são reconhecidas: \n para caractere de nova linha (NL), \t para tabulação horizontal (HT, TAB) e \b para backspace (BS). Outras seqüências com caracteres de escape (incluindo sequências de fuga octal) são inválidas.
As seções include e includeIf permitem que você inclua diretivas da configuração de outra fonte. Estas seções se comportam de forma idêntica, com exceção das seções includeIf que podem ser ignorados se a sua condição não for avaliada como verdadeira; consulte "Inclusão condicional" abaixo.
Você pode incluir um arquivo da configuração de outro configurando a variável especial include.path (ou includeIf.*.path) como o nome do arquivo a ser incluído. A variável assume um nome do caminho como seu valor e está sujeita à expansão do til. Estas variáveis podem ser utilizadas várias vezes.
O conteúdo do arquivo incluído é inserido imediatamente como se tivessem sido encontrados no local da diretiva incluir. Se o valor na variável for um caminho relativo, o caminho será considerado relativo ao arquivo de configuração onde a diretiva include foi encontrada. Veja os exemplos abaixo.
-Você pode condicionalmente incluir um arquivo da configuração de um outro condicionalmente definindo uma variável includeIf.<condição>.path para o nome do arquivo que será incluído.
A condição começa com uma palavra-chave seguida de dois pontos e alguns dados cujo formato e significado dependem da palavra-chave. As palavras-chave compatíveis são:
-gitdir Os dados que seguem a palavra-chave gitdir: são utilizados como um padrão de agrupamento. Caso o local do diretório .git coincida com o padrão, a condição de inclusão será atendida.
O local .git pode ser descoberto automaticamente ou vir da variável de ambiente $GIT_DIR. Caso o repositório seja descoberto automaticamente por meio de um arquivo .git (de submódulos ou uma árvore de trabalho vinculada por exemplo), o local .git será o local final onde está o diretório .git, e não onde o arquivo git está.
O padrão pode conter curingas de mascaramento padrão e dois adicionais, **/ e /**, que podem coincidir com diversos componentes do caminho. Para mais detalhes, consulte o gitignore[5] para detalhes. Por conveniência:
Caso o padrão comece com ~/, ~ será substituído com o conteúdo da variável de ambiente HOME.
Caso o padrão comece com ./, é substituído com o diretório contendo o arquivo da configuração atual.
Caso o padrão não comece com com nenhum ~/, ./ ou /, **/ será anexado automaticamente. O padrão foo/bar se torna **/foo/bar e coincidirá com /qualquer/caminho/para/foo/bar por exemplo.
Caso o padrão termine com /, ** será adicionado automaticamente. O padrão foo/ se torna foo/** por exemplo. Em outras palavras, ele combina "foo" e tudo dentro, recursivamente.
gitdir/i É o mesmo que gitdir exceto que a coincidência é feita sem distinguir as maiúsculas das minusculas (em sistemas onde seja indiferente o sistema de arquivos não se importa com maiúsculas de minusculas)
onbranch Os dados que seguem a palavra-chave onbranch: são considerados um padrão com curingas de agrupamento padrão e dois curingas adicionais, **/ e /**, que podem corresponder a vários componentes de caminho. Se estivermos numa árvore de trabalho onde o nome do ramo que está sendo verificado no momento corresponda ao padrão, a condição de inclusão será atendida.
Caso o padrão termine com /, ** será adicionado automaticamente. O padrão foo/ se torna foo/** por exemplo. Em outras palavras, ele coincide com todos os ramos que começam com foo/. Isso é útil pois caso as suas ramificações estejam organizadas hierarquicamente e você queira aplicar uma configuração em todas as ramificações nesta hierarquia.
hasconfig:remote.*.url: Os dados que seguem esta palavra-chave são tomados como um padrão com curingas e dois adicionais, **/ e /**, que podem corresponder com vários componentes. A primeira vez que esta palavra-chave for vista, o resto dos arquivos de configuração serão verificados com as URLs remotas (sem aplicar nenhum valor). Se existir pelo menos uma URL remota que corresponda a este padrão, a condição de inclusão será satisfeita.
Os arquivos inclusos por esta opção (direta ou indiretamente) não podem conter URLs remotas.
-Note que, ao contrário de outras condições, resolver essa condição depende de informações que ainda não são conhecidas no momento da leitura da condição. Um caso de uso típico é que essa opção está presente como uma configuração a nível de sistema ou uma configuração de global, a URL remota está em uma configuração de nível local; daí a necessidade de digitalizar à frente ao resolver essa condição. A fim de evitar conflitos onde os arquivos incluídos podem afetar se tais arquivos estão potencialmente inclusos, o Git quebra o ciclo, proibindo estes arquivos de afetar a resolução destas condições (assim, proibindo-os de declarar URLs remotas).
-Quanto a nomenclatura dessa palavra-chave, ela é compatível com um esquema de nomenclatura compatível com mais condições de inclusão com base em variáveis, mas, atualmente o Git suporta apenas a palavra-chave exata descrita acima.
-Algumas poucas anotações sobre coincidir através de gitdir e gitdir/i:
Os "symlinks" (links simbólicos) em $GIT_DIR não são resolvidos antes que sejam coincididos.
Ambas as versões do "symlink" (links simbólico) e do "realpath" (caminho real) dos caminhos serão coincididos fora do $GIT_DIR. Por exemplo, caso ~/git seja um link simbólico para /mnt/storage/git, ambos os gitdir:~/git e gitdir:/mnt/storage/git coincidirão.
Este não foi o caso no lançamento inicial desse recurso na versão v2.13.0, que coincidia apenas à versão do caminho real. A configuração que queira ser compatível com o lançamento inicial deste recurso precisa definir apenas a versão do caminho real ou das duas versões.
-Note que "../" não é especial e não irá coincidir literalmente, o que não é o que você quer.
-# Principais variáveis -[core] - ; Não confie nos modos dos arquivos - filemode = false - -# Nosso algoritmo diff -[diff] - external = /usr/local/bin/diff-wrapper - renames = true - -[ramo "devel"] - remote = origin - merge = refs/heads/devel - -# Configurações de proxy -[core] - gitProxy="ssh" for "kernel.org" - gitProxy=default-proxy ; for the rest - -[include] - path = /path/to/foo.inc ; incluído através de um caminho absoluto - path = foo.inc ; find "foo.inc" relativo ao arquivo atual - path = ~/foo.inc ; find "foo.inc" no seu diretório `$HOME` - -; inclua caso $GIT_DIR seja /path/to/foo/.git -[includeIf "gitdir:/path/to/foo/.git"] - path = /path/to/foo.inc - -; inclua em todos os repositórios dentro do /path/to/group -[includeIf "gitdir:/path/to/group/"] - path = /path/to/foo.inc - -; inclua em todos os repositórios dentro do $HOME/to/group -[includeIf "gitdir:~/to/group/"] - path = /path/to/foo.inc - -; os caminhos relativos são sempre relativos à inclusão -; do arquivo (caso a condição seja verdadeira); a sua localização não é -; afetada pela condição -[includeIf "gitdir:/path/to/group/"] - path = foo.inc - -; inclua apenas caso estejamos em uma árvore de trabalho -; onde "foo-branch" seja verificado -[includeIf "onbranch:foo-branch"] - path = foo.inc - -; inclua apenas caso exista um ramo remoto com a URL fornecida (observe -; que tal URL pode ser fornecida posteriormente num arquivo ou num -; arquivo lido após este arquivo ser lido, como visto neste exemplo) -[includeIf "hasconfig:remote.*.url:https://example.com/**"] - path = foo.inc -[remote "origin"] - url = https://example.com/git-
Os Valores das várias variáveis são tratadas como uma cadeia de caracteres simples, porém existem variáveis que pegam os valores de tipos específicos e existem regras de como soletrá-los.
-Quando uma variável pega um valor booleano, muitos sinônimos são aceitos para true e false, estes são todos insensíveis as mudanças de maiúsculas e minusculas.
-Os valores válidos para verdadeiro num literal booleano são yes, on, true e 1. Além disso, uma variável definida sem um valor = <valor> é considerado como verdadeiro.
Os falsos literais booleanos são no, off, false, 0 e a string vazia.
Quando converter um valor para a sua forma canônica utilizando o --type=bool, tipo de especificação git config se assegurará que a saída seja true ou false (em minusculas).
O valor das muitas variáveis que determinam os vários tamanhos podem ter como sufixo k, M,… que significa "escale o número por 1024", "por 1024x1024", etc.
O valor de uma variável que pega uma cor de uma lista de cores (ao menos duas, uma para o primeiro plano e outra para o plano de fundo) e os atributos (quantos queira), separados por espaços.
-São aceitas as seguintes cores básicas normal, black, red, green, yellow, blue, magenta, cyan, white e default. A primeira cor informada é o primeiro plano; a segunda é o plano de fundo. Todas as cores básicas, exceto normal e default, têm uma variação brilhante que pode ser especificada prefixando a cor com bright, como brightred.
A cor normal não faz qualquer alteração na cor. É o mesmo que uma string vazia mas pode ser usada como a cor do primeiro plano ao definir apenas uma cor de fundo ("normal red" por exemplo).
A cor default repõe explicitamente a cor predefinida do terminal, por exemplo, para definir um fundo sem cor. Embora varie entre os terminais, isso normalmente não é o mesmo que definir para "white black" (branco preto).
Colors may also be given as numbers between 0 and 255; these use ANSI 256-color mode (but note that not all terminals may support this). If your terminal supports it, you may also specify 24-bit RGB values as hex, like #ff0ab3, or 12-bit RGB values like #f1b, which is equivalent to the 24-bit color #ff11bb.
Os atributos aceitos são bold, dim, ul, blink, reverse, italic e strike (para letras tachadas ou "strikethrough"). É indiferente a posição de qualquer atributo com relação às cores (antes, depois ou no meio). Atributos específicos podem ser desativados prefixando-os com no ou no- (por exemplo, noreverse, no-ul etc.).
O pseudo-atributo reset redefine todas as cores e os atributos antes de aplicar a cor definida. Por exemplo, o reset green resultará em um primeiro plano verde e o fundo padrão sem qualquer atributo ativo.
Uma sequência de cores vazias não produz nenhum efeito de cor. Isso pode ser utilizado para evitar colorir elementos específicos sem desabilitar totalmente a cor.
-Para os espaços de cor predefinidos do git, os atributos devem ser redefinidos no início de cada item da saída colorida. Portanto, a configuração de color.decorate.branch como black pintará o nome da ramificação como black, mesmo que o item anterior na mesma linha de saída (abrir parênteses antes da lista de nomes de ramificações na saída log --decorate por exemplo) esteja configurado para ser pintado com bold ou algum outro atributo. No entanto, os formatos de registro personalizados podem fazer uma coloração mais complicada e em camadas, nesse caso, as formas negadas podem ser úteis.
Uma variável que recebe um valor para o nome do caminho pode receber uma cadeia de caracteres que começa com "~/" ou "~user/", a expansão usual do til acontece com essa cadeia de caracteres: ~/ é expandida para o valor $HOME, e ~user/ para o diretório inicial do usuário que foi definido.
Caso um caminho comece com %(prefixo)/, o restante será interpretado como um caminho em relação ao "prefixo de tempo de execução" do Git, ou seja, em relação ao local onde o próprio Git foi instalado. Por exemplo, %(prefixo)/bin/ refere-se ao diretório onde o próprio executável Git está. Se o Git for compilado sem suporte ao "runtime prefix support" (prefixo de tempo de execução), o prefixo compilado será substituído. No caso improvável de que um caminho literal precise ser especificado e que não_ deva_ser expandido, ele precisa ser prefixado por ./, assim: ./%(prefixo)/bin.
Observe que essa lista não é abrangente e não está necessariamente completa. Para variáveis específicas de comando, você encontrará uma descrição mais detalhada na página apropriada do manual.
-Outras ferramentas relacionadas ao git podem usar e usam as suas próprias variáveis. Ao inventar novas variáveis para uso em sua própria ferramenta, certifique-se que seus nomes não entrem em conflito com aqueles usados pelo próprio Git e por outras ferramentas populares, descreva-os em sua própria documentação.
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Ao utilizar a sintaxe já obsoleta [section.subsection], alterando um valor, resultará na adição de uma chave com várias linhas em vez de uma alteração apenas, caso a subseção seja informada com pelo menos um caractere em maiúsculo. Por exemplo, quando a configuração se parece
[section.subsection] - key = value1-
e executando git config section.Subsection.key value2 resultará em
[section.subsection] - key = valor1 - key = valor2-
Parte do conjunto git[1]
-Git verfügt über eine interne Schnittstelle zum Speichern und Abrufen von Zugangsdaten, die von systemeigenen Assistenten bereitgestellt werden. Darüber hinaus wird der Benutzer zur Eingabe von Benutzernamen und Passwörtern aufgefordert. Der Befehl git-credential macht diese Schnittstelle für Skripte zugänglich, die Anmeldedaten auf die gleiche Weise wie Git abrufen, speichern oder zur Eingabe von Anmeldedaten auffordern möchten. Das Design dieser skriptfähigen Schnittstelle modelliert die interne C-API; siehe credential.h für weitere Hintergrundinformationen zu den Konzepten.
-git-credential benutzt eine „Funktions“-Option auf der Kommandozeile (entweder fill, approve oder reject) und findet eine Credential-Beschreibung auf stdin (siehe INPUT/OUTPUT FORMAT).
Falls die Funktion fill ist, wird git-credential versuchen, der Beschreibung die Attribute „username“ und „password“ hinzuzufügen, indem es die Konfigurationsdateien ausliest, die Hilfsprogramme der konfigurierten Credentials kontaktiert oder den Benutzer abfragt. Die Attribute „username“ und „password“ der Credential-Information werden dann zusammen mit den bereits vorhandenen Attributen nach stdout ausgegeben.
Falls die Funktion approve (genehmigt) ist, wird git-credential die Beschreibung an alle konfigurierten Credential-Hilfsprogramme senden, die das Credential zur späteren Wiederverwendung abspeichern können.
Wenn die Aktion reject (ablehnen) ist, dann übermittelt git-credential die Information an alle konfigurierten Credential-Hilfsprogramme, die jedes der gespeicherten Credentials, die der Beschreibung entsprechen wieder löschen können.
Falls die Operation approve oder reject ist, sollte keine Meldung ausgegeben werden.
Eine Anwendung, die git-credential nutzt, wird typischerweise git credential, wie in den folgenden Schritten beschrieben, verwenden:
Eine kontextabhängige Credential-Beschreibung erstellen.
-Wenn wir z.B. ein Passwort für https://example.com/foo.git benötigen, könnten wir die folgende Credential-Beschreibung erstellen (vergessen Sie nicht die Leerzeile am Ende; sie teilt git credential mit, dass die Eingabe der Informationen abgeschlossen ist):
protocol=https -host=example.com -path=foo.git-
Fordern Sie git-credential auf, dieser Beschreibung einen Benutzernamen und ein Passwort zuzuordnen. Dafür wird git-credential fill ausgeführt, wobei die Beschreibung aus Schritt (1) in die Standardeingabe übernommen wird. Die vollständige Beschreibung des Credentials (einschließlich des Credentials an sich, d.h. des Benutzernamens und des Passwortes) wird wie bei der Standardausgabe erzeugt:
protocol=https -host=example.com -username=bob -password=secr3t-
Meistens bedeutet dies, dass die in der Eingabe angegebenen Attribute in der Ausgabe wiederholt werden, aber Git kann auch die Beschreibung des Credentials modifizieren, z.B. durch Entfernen des path-Attributs, wenn das Protokoll HTTP(s) ist und credential.useHttpPath auf „false“ gesetzt ist.
Falls git credential das Passwort kannte, hat der Anwender in diesem Schritt möglicherweise kein Passwort eingegeben (der User kann stattdessen ein Passwort eingegeben haben, um die Keychain zu entsperren oder es wurde keine Benutzerinteraktion durchgeführt, wenn der Schlüsselbund bereits entsperrt war), bevor er password=secr3t zurückgab.
Rufen Sie mit dem Zugangscode (z.B. mit dem Benutzernamen und dem Passwort aus Schritt (2)) die URL auf und prüfen Sie, ob sie akzeptiert wird.
-Meldet den Erfolg oder Misserfolg des Passworts. Wenn der Zugangscode den erfolgreichen Abschluss der Operation erlaubt hat, kann er mit dem Vermerk „approve“ versehen werden, um git credential mitzuteilen, dass er bei seinem nächsten Aufruf wieder verwendet werden soll. Falls die Zugangsberechtigung während der Operation zurückgewiesen wurde, verwenden Sie die Option „reject“, so dass git credential bei dem nächsten Aufruf nach einem neuen Passwort fragt. In beiden Fällen sollte git credential mit der in Schritt (2) erhaltenen Beschreibung der Anmeldeinformationen (die auch die in Schritt (1) angegebenen enthalten) versehen werden.
git credential liest und/oder schreibt (abhängig von der verwendeten Aktion) Credential-Informationen in seine Standard-Ein-/Ausgabe. Diese Informationen können entweder den Schlüsseln entsprechen, für welche die git credential die Zugangsdaten erhalten soll (z.B. Host, Protokoll, Pfad) oder den tatsächlich zu erhaltenden Zugangsdaten (Benutzername/Passwort).
Der Zugangscode wird in ein Set von festgelegten Attributen aufgeteilt, ein Attribut pro Zeile. Jedes Attribut wird durch ein Schlüssel-Wert-Paar angegeben, getrennt durch ein = (Gleichheitszeichen), gefolgt von einem Zeilenumbruch.
Der Schlüssel kann beliebige Bytes außer =, Zeilenumbruch oder NUL enthalten. Der Wert kann beliebige Bytes außer Zeilenumbruch oder NUL enthalten.
Attributes with keys that end with C-style array brackets [] can have multiple values. Each instance of a multi-valued attribute forms an ordered list of values - the order of the repeated attributes defines the order of the values. An empty multi-valued attribute (key[]=\n) acts to clear any previous entries and reset the list.
In all cases, all bytes are treated as-is (i.e., there is no quoting, and one cannot transmit a value with newline or NUL in it). The list of attributes is terminated by a blank line or end-of-file.
-Git beherrscht die folgenden Attribute:
-protocol Das Protokoll, für das die Anmeldeinformationen verwendet werden sollen (z.B. https).
host Der Remote-Hostname für eine Netzwerkanmeldung. Dazu gehört auch die Port-Nummer, falls eine festgelegt wurde (z.B. „example.com:8088“).
-path Der Pfad, mit dem das Credential verwendet wird. Wenn Sie z.B. auf ein entferntes https-Repository zugreifen, ist dies der Pfad des Repositorys auf dem Server.
-username Der Benutzername der Zugangsberechtigung, falls wir bereits einen haben (z.B. von einer URL, der Konfiguration, dem Benutzer oder von einem zuvor ausgeführten Helper).
-password Das Passwort für das Credential, falls wir es hinterlegen wollen.
-password_expiry_utc Generated passwords such as an OAuth access token may have an expiry date. When reading credentials from helpers, git credential fill ignores expired passwords. Represented as Unix time UTC, seconds since 1970.
oauth_refresh_token An OAuth refresh token may accompany a password that is an OAuth access token. Helpers must treat this attribute as confidential like the password attribute. Git itself has no special behaviour for this attribute.
-url Wenn dieses spezielle Attribut von git credential ausgewertet wird, dann wird der Wert als URL geparst und so behandelt, als ob seine Bestandteile ausgelesen würden (z.B. wird sich url=https://example.com so verhalten, als ob protocol=https und host=example.com bereitgestellt sind). Auf diese Weise können Aufrufer vermeiden, URLs selbst zu parsen.
Beachten Sie, dass die Angabe eines Protokolls obligatorisch ist, und wenn die URL keinen Hostnamen angibt (z. B. "cert:////pfad/zur/Datei"), enthält der Zugangscode ein Hostname-Attribut, dessen Wert eine leere Zeichenfolge ist.
-Komponenten, die in der URL fehlen (z.B. gibt es im obigen Beispiel keinen Benutzernamen), werden nicht gesetzt.
-wwwauth[] When an HTTP response is received by Git that includes one or more WWW-Authenticate authentication headers, these will be passed by Git to credential helpers.
-Each WWW-Authenticate header value is passed as a multi-valued attribute wwwauth[], where the order of the attributes is the same as they appear in the HTTP response. This attribute is one-way from Git to pass additional information to credential helpers.
-Unrecognised attributes are silently discarded.
-Teil der git[1] Suite
-O Git possui uma interface interna para armazenar e recuperar as credenciais dos ajudantes específicos do sistema, além de solicitar ao usuário os nomes dos usuários e as suas respectivas senhas. O comando git-credential expõe essa interface a scripts que podem recuperar, armazenar ou solicitar credenciais da mesma maneira que o Git. O design dessa interface programável modela ao API C interno; consulte o credential.h para obter mais informações sobre os conceitos.
O git-credential usa uma "ação" como opção na linha de comando (uma das opções fill, aprove ou reject) e lê uma descrição da credencial no "stdin" (consulte INPUT/OUTPUT FORMAT).
Caso a ação seja fill, git-credential tentará adicionar os atributos "username" e "password" à descrição lendo os arquivos de configuração ao contactar qualquer auxiliar de credencial configurado ou solicitando ao usuário. Os atributos de nome de usuário e senha da descrição da credencial são impressos para "stdout" junto com os atributos já informados.
Caso a ação for approve (aprovar), o comando git-credential enviará a descrição a todos os auxiliares de credenciais configurados, que poderão armazenar a credencial para uso posterior.
Caso a ação seja reject, o comando git-credential enviará a descrição para qualquer auxiliar de credencial já configurado, o que poderá apagar quaisquer credenciais que coincidam com a descrição.
Caso a ação seja approve ou reject, nenhum alerta será emitido.
Um aplicativo que utilize o comando git-credential normalmente usa git credential seguindo estas etapas:
Gere um descritivo da credencial com base no contexto.
-Por exemplo, caso queira uma senha para https://example.com/foo.git, poderemos gerar o seguinte descritivo para a credencial (não se esqueça da linha em branco no final; informa git credential que o aplicativo terminou de encaminhar todas as informações que ele tinha):
protocol=https -host=exemplo.com.br -path=foo.git-
Peça à git-credential para nos fornecer um nome de usuário e senha para esta descrição. Isso é feito executando o comando git credential fill, alimentando a descrição da etapa (1) para a sua entrada predefinido. O descritivo completo da credencial (incluindo a credencial em si, ou seja, o login e a senha) será produzida como:
protocol=https -host=exemplo.com.br -username=bob -password=secr3t-
Na maioria dos casos, isso significa que os atributos informados na entrada serão repetidos na saída, mas o Git também poderá modificar a descrição da credencial, por exemplo, removendo o atributo path quando o protocolo for HTTP(s) e a variável credential.useHttpPath seja falsa.
Caso o comando git credential saiba sobre a senha, esta etapa pode não ter o envolvimento do usuário que esteja digitando esta senha (o usuário pode ter digitado uma senha para desbloquear o chaveiro ou nenhuma interação do usuário foi feita caso o chaveiro já tenha sido desbloqueado) antes de retornar password=secr3t.
Utilize a credencial (por exemplo, acesse a URL com o nome de usuário e a senha da etapa (2)) e verifique se ela é aceita.
-Relate o sucesso ou falha da senha. Caso a credencial permita que a operação seja concluída com sucesso, ela pode ser marcada com uma ação "approve" para passar ao git credential para ser reutilizada na próxima invocação. Caso a credencial seja rejeitada durante a operação, utilize a ação "reject" para que o comando git credential solicite uma nova senha na próxima invocação. Em qualquer um dos casos, o comando git credential deve ser alimentado com o descritivo da credencial obtida na etapa (2) (que também contém os campos informados na etapa (1)).
O git credential lê e/ou grava (dependendo da ação utilizada) informações das credenciais em sua entrada/saída predefinida. Estas informações podem corresponder às chaves para as quais o git credential obterá as informações de login (host, protocolo, caminho por exemplo) ou aos dados reais da credencial a serem obtidos (nome de usuário/senha).
A credencial é dividida em um conjunto de atributos informados, com um atributo por linha. Cada atributo é especificado por um par de valores-chave, separado por um sinal de = (igual), seguido por uma nova linha.
A chave pode conter quaisquer bytes, exceto =, nova linha ou NUL. O valor pode conter quaisquer bytes, exceto uma nova linha ou NUL.
Os atributos com chaves que terminam com colchetes de matriz no estilo C [] podem ter diversos valores. Cada instância de um atributo com diversos valores forma uma lista ordenada de valores - a ordem dos atributos repetidos define a ordem dos valores. Um atributo multivalorado vazio (key[]=\n) atua para limpar quaisquer entradas anteriores e redefinir a lista.
Em todos os casos, todos os bytes são tratados como estão (ou seja, não há aspas e não é possível transmitir um valor com nova linha ou NUL nela). A lista de atributos é finalizada por uma linha em branco ou no final do arquivo.
-O Git entende os seguintes atributos:
-protocol O protocolo sobre o qual a credencial será utilizada (por exemplo, https).
host O nome do host remoto para uma credencial de rede. Isso inclui o número da porta, caso tenha sido especificado ("example.com:8088" por exemplo).
-path O caminho com o qual a credencial será utilizada. Por exemplo, para acessar um repositório https remoto, este será o caminho do repositório no servidor.
-username O nome de usuário da credencial, caso já tenhamos um (por exemplo, de uma URL, da configuração do usuário ou de um auxiliar executado anteriormente).
-password A senha da credencial, caso estejamos solicitando o seu armazenamento.
-password_expiry_utc As senhas geradas, como um token de acesso OAuth, podem ter uma data de validade. Ao ler as credenciais dos auxiliares, o comando git credential fill ignora as senhas expiradas. Representado como hora segundos UTC do Unix, desde 1970.
oauth_refresh_token Um token de atualização do OAuth pode acompanhar uma senha que é um token de acesso do OAuth. Os assistentes devem tratar este atributo como confidencial, assim como os atributos de senha. O próprio Git não possui nenhum comportamento especial para este atributo.
-url Quando esse atributo especial é lido através do git credential, o valor é analisado como uma URL e tratado como se as suas partes constituintes fossem lidas (por exemplo, url=https://example.com se comportaria como se o protocol = https e host=example.com tenham sido fornecidos). Isso pode ajudar quem chama a evitar a análise das URLs eles mesmos.
Observe que a definição de um protocolo é obrigatório e caso a URL não informe o nome do host ("cert:///caminho/para/o/arquivo") o conteúdo da credencial terá o atributo do nome do host cujo valor seja vazio.
-Os componentes ausentes na URL (não há um nome de usuário no exemplo acima por exemplo) serão deixados por sem uma definição.
-wwwauth[] Quando o Git receber uma resposta HTTP que inclua um ou mais cabeçalhos de autenticação "WWW-Authenticate", o Git passará estes cabeçalhos para os assistentes de credenciais.
-Cada valor do cabeçalho "WWW-Authenticate" é passado em forma de i, atributo com vários valores "wwwauth[]", onde a ordem dos atributos é a mesma que aparece na resposta HTTP. Esse atributo do Git é "unidirecional" para passar informações adicionais aos assistentes de credenciais.
-Todos os atributos não reconhecidos são descartados silenciosamente.
-Parte do conjunto git[1]
-git diff [<options>] [<commit>] [--] [<path>…] -git diff [<options>] --cached [<commit>] [--] [<path>…] -git diff [<options>] <commit> [<commit>…] <commit> [--] [<path>…] -git diff [<options>] <commit>…<commit> [--] [<path>…] -git diff [<options>] <blob> <blob> -git diff [<options>] --no-index [--] <path> <path>-
Show changes between the working tree and the index or a tree, changes between the index and a tree, changes between two trees, changes resulting from a merge, changes between two blob objects, or changes between two files on disk.
-Mit dieser Befehlssyntax können die Änderungen angezeigt werden, die Sie relativ zum Index vorgenommen haben (Staging-Area für den nächsten Commit). Mit anderen Worten, die Unterschiede sind das, was Sie Git mitteilen könnten, um es später zum Index hinzuzufügen, aber Sie haben es immer noch nicht getan. Sie können diese Änderungen mit git-add[1] bereitstellen (stagen).
-Diese Form dient dem Vergleich der beiden angegebenen Pfade auf dem Dateisystem. Sie können die Option --no-index weglassen, wenn Sie den Befehl in einem von Git kontrollierten Arbeitsbereich ausführen und mindestens einer der Pfade außerhalb des Arbeitsbereichs liegt oder wenn Sie den Befehl außerhalb eines von Git kontrollierten Arbeitsbereichs ausführen. Diese Form impliziert die Option --exit-code.
Auf diese Art können Sie sich die Änderungen ansehen, die Sie für den nächsten Commit, relativ zu dem angegebenen <Commit>, vorgenommen haben. Normalerweise werden Sie einen Vergleich mit dem letzten Commit sehen wollen. Wenn Sie also den <Commit> nicht angeben, wird standardmäßig HEAD verwendet. Wenn HEAD nicht existiert (z.B. wegen noch nicht erstelltem Branch) und <Commit> nicht angegeben wird, zeigt dies alle Änderungen in der Staging-Area an. --staged ist ein Synonym für --cached.
-Zeigt die Unterschiede zwischen dem Arbeitsbereich und dem angegebenen <Commit> an. Sie können HEAD verwenden, um ihn mit dem letzten Commit zu vergleichen oder den Namen eines Branchs, um ihn mit der Spitze eines anderen Branchs zu vergleichen.
-Zeigt die Änderungen zwischen zwei beliebigen <Commit>s an.
-In dieser Form können Sie die Ergebnisse eines Merge Commits betrachten. Der erste aufgelistete <Commit> muss der Merge selbst sein; die restlichen zwei oder mehr Commits sollten seine Eltern sein. Ein praktischer Weg, den gewünschten Satz von Revisionen zu erzeugen, ist die Verwendung des Suffixs ^@. Wenn z.B. master einen Merge-Commit benennt, ergibt git diff master master^@ das gleiche kombinierte Diff wie git show master.
This is synonymous to the earlier form (without the "..") for viewing the changes between two arbitrary <commit>. If <commit> on one side is omitted, it will have the same effect as using HEAD instead.
-Dieser Befehl zeigt die Änderungen auf dem Branch an, der den zweiten <Commit> enthält, beginnend mit einem gemeinsamen Vorfahren beider <Commit>s, bis zum zweiten <Commit>. "git diff A...B" ist äquivalent zu "git diff $(git merge-base A B) B". Sie können einen der beiden <Commit>s weglassen, wodurch stattdessen HEAD eingesetzt wird.
-Für alle exotischen Anwendungsfälle, weisen wir darauf hin, dass alle <Commit>s in den vorstehenden Beschreibungen, mit Ausnahme der letzten beiden Varianten, welche die "…"-Notationen verwenden, beliebige <„Verzeichnis-Bäume“> sein können.
-Eine ausführlichere Liste, wie <commit> spezifiziert werden kann, findet sich in gitrevisions[7] im Abschnitt „REVISIONEN SPEZIFIZIEREN“. Allerdings vergleicht "diff" immer zwei Versionen (Endpunkte) miteinander und keine Bereiche. Die Bereichsnotationen ("<commit>…<commit>" und "<commit>...<commit>") bezeichnen hier also keinen Bereich (Range) wie es im Abschnitt "BEREICHE FESTLEGEN" in gitrevisions[7] beschrieben ist.
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Vergleicht den Arbeitsbereich mit der "Basis"-Version (base, Stufe #1), „unserer Branch“ (ours, Stufe #2) oder „deren Branch“ (theirs, Stufe #3). Der Index enthält diese Stufen nur für nicht gemergte Einträge, d.h. bei der Auflösung von Konflikten. Siehe dazu git-read-tree[1] Abschnitt „3-Wege-Merge“ für weitere Informationen.
-Lässt die Diff-Ausgabe für nicht gemergte Beiträge weg und zeigt nur "Unmerged" an. Kann nur verwendet werden, wenn der Arbeitsbereich mit dem Index verglichen wird.
-Die <Pfad>-Parameter, sofern angegeben, werden verwendet, um das diff auf die benannten Pfade zu beschränken (auch Verzeichnisnamen können angegeben werden, um ein diff für alle Dateien darin zu erhalten).
-Die rohen Ausgabeformate von "git-diff-index", "git-diff-tree", "git-diff-files" und "git diff --raw" sind sehr ähnlich.
-Die Befehle vergleichen alle zwei Sätze von Dingen; was verglichen wird, unterscheidet sich:
-vergleicht <baumartig> mit den Dateien auf dem Dateisystem.
-vergleicht <baumartig> mit dem Index.
-vergleicht die Verzeichnis-Bäume, die durch die beiden Argumente bestimmt wurden.
-vergleicht den Index mit den Dateien auf dem Dateisystem.
-Der "git-diff-tree"-Befehl beginnt seine Ausgabe mit dem Ausgeben des Hashes von dem, was verglichen wird. Danach geben alle Befehle eine Ausgabezeile pro geänderter Datei aus.
-Eine Ausgabezeile ist so formatiert:
-direkt-bearbeiten :100644 100644 bcd1234 0123456 M Datei0 -kopieren-bearbeiten :100644 100644 abcd123 1234567 C68 Datei1 Datei2 -umbenennen-bearbeiten :100644 100644 abcd123 1234567 R86 Datei1 Datei3 -erstellen :000000 100644 0000000 1234567 A Datei4 -löschen :100644 000000 1234567 0000000 D Datei5 -nicht gemergt :000000 000000 0000000 0000000 U Datei6-
Das Folgende bedeutet (von links nach rechts):
-ein Doppelpunkt.
-Modus für "src"; 000000 falls erstellt oder nicht gemergt.
-ein Leerzeichen.
-Modus für "dst"; 000000, falls gelöscht oder nicht gemergt.
-ein Leerzeichen.
-SHA1-Hash für "src"; 0{40} falls erstellt oder nicht gemergt.
-ein Leerzeichen.
-sha1 for "dst"; 0{40} if deletion, unmerged or "work tree out of sync with the index".
-ein Leerzeichen.
-Status, gefolgt von optionaler "score"-Nummer.
-ein Tab oder ein NUL, wenn die -z-Option benutzt wird.
Pfad für "src"
-ein Tab oder ein NUL, wenn die -z-Option benutzt wird; existiert nur für C oder R.
Pfad für "dst"; existiert nur für C oder R.
-ein LF oder ein NUL, wenn die -z-Option benutzt wird, um den Datensatz zu beenden.
Mögliche Status-Buchstaben sind:
-A: Hinzufügen einer Datei
-C: Kopieren einer Datei in eine neue
-D: Löschung einer Datei
-M: Modifikation des Inhalts oder Modus einer Datei
-R: Umbenennen einer Datei
-T: change in the type of the file (regular file, symbolic link or submodule)
-U: Datei ist nicht zusammengeführt (du musst die Zusammenführung abschließen, bevor es commited werden kann)
-X: "unbekannt" Änderungstyp (höchstwahrscheinlich ein Bug, bitte melde ihn)
-Die Status-Buchstaben C und R werden immer von einer Punktzahl gefolgt (die den Prozentsatz der Ähnlichkeit zwischen Quelle und Ziel des Verschiebens oder des Kopierens angibt). Auf den Status-Buchstaben M kann eine Punktzahl (die den Prozentsatz der Unähnlichkeit angibt) für das Umschreiben von Dateien folgen.
-The sha1 for "dst" is shown as all 0’s if a file on the filesystem is out of sync with the index.
-Beispiel:
-:100644 100644 5be4a4a 0000000 M Datei.c-
Ohne die Option -z werden Pfadnamen mit „ungewöhnlichen“ Zeichen in Anführungszeichen gesetzt, wie für die Konfigurationsvariable core.quotePath erklärt (siehe git-config[1]). Mit -z wird der Dateiname wortwörtlich ausgegeben und die Zeile mit einem NUL-Byte abgeschlossen.
„git-diff-tree“, „git-diff-files“ und „git-diff --raw“ können die Option -c oder --cc benutzen, um Diff-Ausgaben auch für Merge-Commits zu erzeugen. Die Ausgabe unterscheidet sich von dem oben beschriebenen Format in der folgenden Weise:
für jedes Elternteil ist ein Doppelpunkt vorhanden
-Es gibt weitere „src“-Modi und „src“-SHA1-Hashes
-Für jedes Elternteil ist der Status als verkettete Statuszeichen dargestellt
-Es gibt keine optionale „Score“-Zahl
-Pfadnamen der Datei werden durch Tabulatoren getrennt
-For -c and --cc, only the destination or final path is shown even if the file was renamed on any side of history. With --combined-all-paths, the name of the path in each parent is shown followed by the name of the path in the merge commit.
Examples for -c and --cc without --combined-all-paths:
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c -::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM bar.sh -::100644 100644 100644 e07d6c5 9042e82 ee91881 RR phooey.c-
Examples when --combined-all-paths added to either -c or --cc:
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c desc.c desc.c -::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM foo.sh bar.sh bar.sh -::100644 100644 100644 e07d6c5 9042e82 ee91881 RR fooey.c fuey.c phooey.c-
Beachten Sie bitte, dass combined diff nur Dateien auflistet, die von allen Elternteilen modifiziert wurden.
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Die Option --summary beschreibt neu hinzugefügte, gelöschte, umbenannte und kopierte Dateien. Die Option --stat fügt ein diffstat(1)-Diagramm zur Ausgabe hinzu. Diese Optionen können mit anderen Optionen, wie z.B. -p, kombiniert werden und sind für den Gebrauch durch Personen gedacht.
Wenn eine Änderung angezeigt wird, die eine Umbenennung oder eine Kopie beinhaltet, formatiert --stat die Pfadnamen kompakt, indem es gemeinsame Präfixe und Suffixe der Pfadnamen vereint. Zum Beispiel wird eine Änderung, die arch/i386/Makefile nach arch/x86/Makefile verschiebt, wobei noch 4 Zeilen modifiziert werden, wie folgt dargestellt:
arch/{i386 => x86}/Makefile | 4 +--
-Die Option --numstat liefert die diffstat(1)-Informationen, ist aber hauptsächlich die maschinelle Verarbeitung gedacht. Ein solcher Einsatz in der --numstat-Ausgabe sieht wie folgt aus:
1 2 README
-3 1 arch/{i386 => x86}/Makefile
-Das Folgende bedeutet (von links nach rechts):
-die Anzahl der eingefügten Zeilen;
-ein Tabulator;
-die Anzahl der gelöschten Zeilen;
-ein Tabulator;
-Pfadname (eventuell mit Informationen zum Umbenennen/Kopieren);
-eine neue Zeile.
-Wenn die Ausgabeoption -z aktiv ist, wird die Ausgabe so formatiert:
1 2 README NUL -3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL-
Das bedeutet:
-die Anzahl der eingefügten Zeilen;
-ein Tabulator;
-die Anzahl der gelöschten Zeilen;
-ein Tabulator;
-ein NUL (nur dann, falls umbenannt oder kopiert);
-Pfadname im Pre-Image;
-ein NUL (nur dann, falls umbenannt oder kopiert);
-Pfadname im Post-Image (existiert nur, falls umbenannt oder kopiert);
-ein NUL.
-Die zusätzliche NUL vor dem Pre-Image-Pfad (falls eine Umbenennung vorliegt) soll es auslesenden Skripten ermöglichen zu erkennen, ob bei dem aktuell gelesenen Datensatz ein Single-Path-Datensatz oder ein Datensatz zum Umbenennen/Kopieren vorliegt, ohne ihn vorab lesen zu müssen. Nach dem Lesen von hinzugefügten und gelöschten Zeilen würde das Lesen bis zur NUL den Pfadnamen ergeben, wenn aber dieser NUL ist, zeigt der Datensatz zwei Pfade an.
$ git diff (1) -$ git diff --cached (2) -$ git diff HEAD (3)-
Änderungen im Arbeitsbereich, die noch nicht im Index für den nächsten Commit vorbereitet wurden.
-Änderungen zwischen dem Index und dem letzten Commit. Die Daten, die Sie committen würden, wenn Sie git commit ohne die Option -a ausführen.
Änderungen zwischen dem Index und dem letzten Commit. Das würden Sie committen, wenn Sie "git commit -a" ausführen
-$ git diff test (1) -$ git diff HEAD -- ./test (2) -$ git diff HEAD^ HEAD (3)-
Statt die neuesten Version des aktuellen Branchs zu verwenden, wird die neueste Version der Branch „test“ verglichen.
-Anstatt mit der neuesten Version der Branch „test“ zu vergleichen, wird mit der neuesten Version (HEAD) der aktuellen Branch verglichen, allerdings ist der Vergleich auf die bezeichnete Datei (./test) beschränkt.
-Vergleicht die Version vor dem letzten Commit mit dem letzten Commit.
-$ git diff topic master (1) -$ git diff topic..master (2) -$ git diff topic...master (3)-
Vergleich zwischen den neuesten Versionen der topic und der master Branch.
-Wie oben.
-Änderungen, die am Branch master seit Start des Branch topic vorgenommen wurden.
-$ git diff --diff-filter=MRC (1) -$ git diff --name-status (2) -$ git diff arch/i386 include/asm-i386 (3)-
Zeigt nur die Änderung, Umbenennung und Kopie, aber keine Löschung oder Hinzufügung.
-Zeigt nur Namen und die Art der Änderung, nicht aber die tatsächliche Ausgabe von diff.
-Schränkt den Vergleich auf das benannte Unterverzeichnis ein.
-$ git diff --find-copies-harder -B -C (1) -$ git diff -R (2)-
Führt weitere Iterationen durch um Umbenennungen, Kopien und komplett neugeschriebene Teile zu finden (sehr zeitaufwendig!).
-Ausgabe in umgekehrter Reihenfolge.
-diff(1), git-difftool[1], git-log[1], gitdiffcore[7], git-format-patch[1], git-apply[1], git-show[1]
-Teil der git[1] Suite
-git diff [<options>] [<commit>] [--] [<caminho>…] -git diff [<options>] --cached [--merge-base] [<commit>] [--] [<caminho>…] -git diff [<options>] [--merge-base] <commit> [<commit>…] <commit> [--] [<caminho>…] -git diff [<options>] <commit>…<commit> [--] [<caminho>…] -git diff [<options>] <blob> <blob> -git diff [<options>] --no-index [--] <caminho> <caminho>-
Exibe as alterações entre a árvore de trabalho, o índice ou uma árvore, as alterações entre o índice e uma árvore, as alterações entre as duas árvores, nas alterações resultantes de uma mesclagem, nas alterações entre dois objetos bolha ou nas alterações entre dois arquivos no disco.
-Este formulário serve para exibir as alterações feitas em relação ao índice (área de preparação para o próximo commit). Em outras palavras, as diferenças são as que você pode informar ao Git para adicionar ao índice, mas ainda não o fez. Você pode preparar essas alterações utilizando git-add[1].
-Este formulário serve para comparar os dois caminhos utilizados no sistema de arquivos. Você pode omitir a opção --no-index durante a execução do comando em uma árvore de trabalho controlado pelo Git e pelo menos um dos pontos dos caminhos fora da árvore de trabalho ou ao executar o comando fora de uma árvore de trabalho que é controlado pelo Git. Este formulário implica no uso da opção --exit-code.
Este formulário serve para exibir as alterações feitas em relação ao próximo commit relativo ao <commit> informado. Geralmente você vai querer uma comparação com o commit mais recente, portanto, se não fizer o <commit> a predefinição retorna para HEAD. Caso HEAD não exista (por exemplo, os galhos que ainda vão aparecer) e um <commit> não tenha sido feito, exibe todas as alterações em etapas. --staged é um sinônimo da opção --cached.
Caso a opção --merge-base seja usada, em vez de usar <commit>, use a base mesclada do <commit> e HEAD. git diff --cached --merge-base A é o mesmo que git diff --cached $(git merge-base A HEAD).
Este formulário exibe as modificações feitas por você na sua árvore de trabalho relativo ao nome do <commit>. É possível utilizar o HEAD para compará-lo com o commit mais recente ou para comparar com o cume de um ramo diferente.
Caso a opção --merge-base seja usada, em vez de usar <commit>, use a base mesclada do <commit> e HEAD. git diff --merge-base A é o mesmo que git diff $(git merge-base A HEAD).
Isso é para exibir as alterações entre os dois <commits> arbitrários.
Caso a opção --merge-base seja usada, use a base mesclada dos dois commits do lado "anterior". O comando git diff --merge-base A B é o mesmo que git diff $(git merge-base A B) B.
Este formulário serve para visualizar os resultados da mesclagem de um commit. O primeiro <commit> listado deve ser a própria mesclagem; os dois ou mais commits restantes devem ser os seus principais. Outras maneiras convenientes de produzir o conjunto desejado das revisões é usar os sufixos ^@ e ^!. Caso A seja um commit mesclado, então git diff A A^@, git diff A^! e git show A todos retornam a mesma combinação do diff.
-Isso é um sinônimo do formulário anterior (sem o ..) para visualizar as alterações entre dois <commit> arbitrários. Caso o <commitir> de um lado seja omitido, ele terá o mesmo efeito que usar HEAD.
Este formulário é para exibir as alterações no ramo que contenha até o segundo <commit>, iniciando com um ancestral comum de ambos os <commit>. git diff A...B é o equivalente a um git diff $(git merge-base A B) B. Você pode omitir qualquer um dos <commit> que tem o mesmo efeito que usar HEAD.
Caso esteja fazendo algo exótico, é bom que seja observado que todos os <commits> na descrição acima, exceto no caso da opção --merge-base e nas duas últimas formas que usam notações .. e pode ser qualquer <árvore>. Uma árvore de interesse é aquela apontada pela referência nominada AUTO_MERGE, que é escrita pela estratégia de mesclagem ort ao atingir conflitos de mesclagem (consulte git-merge[1]). A comparação da árvore de trabalho com AUTO_MERGE mostra as alterações que você fez até o momento para resolver conflitos textuais (veja os exemplos abaixo).
Para obter uma lista mais completa de maneiras de soletrar um <commit>, consulte a seção "DEFININDO AS REVISÕES" em gitrevisions[7]. No entanto, diff é sobre comparar dois endpoints, e não os intervalos, as notações de intervalo (<commit>..<commit> e <commit>...<commit>) não significam um intervalo definido na seção "DEFININDO AS REVISÕES" em gitrevisions[7].
Gerar patch (consulte Gerando a correção em um formato texto com a opção -p).
-Esta é a predefinição.
Suprime toda a saída do mecanismo, diff. É útil para comandos como git show que, por padrão, mostram o patch para abafar a sua saída, ou para cancelar o efeito de opções como --patch, --stat anteriormente na linha de comando num alias.
Gere diffs com uma quantidade de <n> linhas de contexto em vez das três usuais.
-Implica no uso da opção --patch.
Escreve o arquivo para um determinado arquivo em vez de stdout.
-Informe o caractere que será utilizado para indicar as linhas novas, antigas ou do contexto no patch que foi gerado. Normalmente eles são +, - e ' ' respectivamente.
-Gere o diff no formato bruto (raw).
-É um sinônimo para -p --raw.
Ativa a heurística que altera os limites dos pedaços diferentes para facilitar a leitura dos patches. Esta é a predefinição.
-Desative a heurística de recuo.
-Expenda um tempo extra para garantir que o menor diferencial possível seja produzido.
-Gere um diff utilizando o algoritmo "patience diff" (ou diff de paciência).
-Gere um diff utilizando o algoritmo "histogram diff" (ou diff de histograma).
-Gere um diff utilizando o algoritmo "anchored diff" (ou diff ancorado).
-Esta opção pode ser usada mais de uma vez.
-Caso uma linha exista na origem e no destino, exista apenas uma vez e comece com este texto, este algoritmo tenta impedir que apareça como uma exclusão ou adição na saída. O algoritmo "patience diff" é utilizado internamente.
-Escolha um algoritmo diff. As variantes são as seguintes:
-default, myers O algoritmo diff ganancioso básico. Atualmente, este é o valor predefinido.
-minimal Expenda um tempo extra para garantir que o menor diferencial possível seja produzido.
-patience Utilize o algoritmo "patience diff" (ou diff de paciência) ao gerar os patches.
-histogram Este algoritmo estende o algoritmo "patience" (paciência) para "se compatível com os elementos comuns com baixa ocorrência".
-Caso tenha configurado uma variável diff.algorithm para um valor sem predefinição e quer utilizar a variável predefinida por exemplo, então utilize a opção --diff-algorithm=default.
Gera um diffstat. É predefinido que o espaço necessário será utilizado para a parte do nome do arquivo e o restante para a parte do grafo. A largura máxima tem como padrão a largura do terminal ou 80 colunas caso não esteja conectado num terminal, e pode ser substituído por <largura>. A largura da parte do nome do arquivo pode ser limitado ao fornecer outra largura <largura-do-nome> após uma vírgula ou definindo com diff.statNameWidth=<width>. A largura da parte do gráfico pode ser limitada pelo uso de --stat-graph-width=<largura> ou pela configuração de diff.statGraphWidth=<largura>. A utilização de --stat ou --stat-graph-width afeta todos os comandos que geram um gráfico estatístico, enquanto a definição diff.statNameWidth ou diff.statGraphWidth não afeta o git format-patch. Ao fornecer um terceiro parâmetro <count>, você pode limitar a saída às primeiras <count> linhas, seguidas de ... caso haja mais.
Estes parâmetros também podem ser ajustados individualmente com --stat-width=<largura>, --stat-name-width=<largura-do-nome> e --stat-count=<count>.
A saída de um resumo condensado das informações do cabeçalho estendido como criações ou exclusões dos arquivos ("novo" ou "desaparecido", opcionalmente "+l" se for um link simbólico) e alterações do modo ("+x" ou "-x" para adicionar ou remover um bit executável, respectivamente) no diffstat. As informações são colocadas entre a parte do nome do arquivo e a parte do grafo. Implica no uso da opção --stat.
Semelhante ao --stat, exibe a quantidade de linhas adicionadas, excluídas, em notação decimal e o nome do caminho sem abreviação, para torná-lo mais amigável à máquina. Para arquivos binários, gera dois - em vez de 0 0.
Produz apenas a última linha do formato --stat contendo a quantidade total dos arquivos modificados, assim como a quantidade de linhas adicionadas e excluídas.
Produz a distribuição da quantidade relativa de alterações para cada subdiretório. O comportamento do --dirstat pode ser customizado passando uma lista de parâmetros separados por vírgula. As predefinições são controlados pela variável de configuração diff.dirstat (veja git-config[1]). Os seguintes parâmetros estão disponíveis:
changes Calcule os números "dirstat" contando as linhas que foram removidas da fonte ou adicionadas ao destino. Ignora a quantidade de movimentos de código puro num arquivo. Em outras palavras, reorganizar as linhas num arquivo não conta tanto quanto as outras alterações. Este é o comportamento predefinido quando nenhum parâmetro for utilizado.
-lines Calcule os números "dirstat" fazendo a análise diferencial com base nas linhas regulares e somando as contagens das linhas removidas / adicionadas. (Para os arquivos binários, conte em blocos de 64 bytes, pois os arquivos binários não têm um conceito natural de linhas). Este é um comportamento mais dispendioso do --dirstat do que o comportamento changes (alterações), conta as linhas reorganizadas num arquivo tanto quanto as outras alterações. A produção resultante é consistente com o que você obtém das outras opções --*stat.
files Calcule os números "dirstat" contando a quantidade de arquivos alterados. Cada arquivo alterado conta igualmente na análise do "dirstat". Este é o comportamento computacional mais barato do --dirstat, pois não precisa olhar o conteúdo do arquivo.
cumulative Conta as alterações num diretório herdeiro e também para o diretório de origem. Observe que, ao utilizar cumulative (cumulativo), a soma das porcentagens relatadas pode exceder os 100%. O comportamento predefinido (não cumulativo) pode ser especificado com o parâmetro noncumulative (não cumulativo).
Um parâmetro inteiro especifica uma porcentagem de corte (a predefinição retorna para 3%). Os diretórios que contribuem com menos que esta porcentagem nas alterações não são exibidos na saída.
-Exemplo: O seguinte contará os arquivos alterados, ignorando os diretórios com menos de 10% da quantidade total de arquivos alterados e acumulando as contagens dos diretórios filhos nos diretórios pais: --dirstat=files,10,cumulative.
É um sinônimo para --dirstat=cumulative
É um sinônimo para --dirstat=files,<parâmetro1>,<parâmetro2>…
-Produza um resumo condensado das informações estendidas do cabeçalho, como criações, renomeações e alterações do modo.
-É um sinônimo para -p --stat.
Quando --raw, --numstat, --name-only ou --name-status tenha sido
-utilizado, não una os nomes do caminho e utilize caracteres NUL como terminadores do campo de saída.
Sem esta opção, os nomes do caminho com caracteres "incomuns" são citados como explicado na variável de configuração core.quotePath (veja git-config[1]).
Show only the name of each changed file in the post-image tree. The file names are often encoded in UTF-8. For more information see the discussion about encoding in the git-log[1] manual page.
-Show only the name(s) and status of each changed file. See the description of the --diff-filter option on what the status letters mean. Just like --name-only the file names are often encoded in UTF-8.
Especifique como as diferenças nos submódulos são exibidos. Ao especificar --submodule=short, o formato short (curto) é utilizado. Este formato exibe apenas os nomes dos commits no início e no final do intervalo. Ao utilizar a opção --submodule ou --submodule=log, o formato log passa a ser utilizado. Este formato lista os commits no intervalo como o git-submodule[1] summary (resumo) faz. Ao utilizar a opção --submodule=diff, o formato diff passa a ser utilizado. Este formato exibe uma comparação nas linhas das alterações no conteúdo do submódulo entre o intervalo do commit. A predefinição retorna para a opção de configuração diff.submodule ou o formato short (curto) caso a opção da configuração estiver desativada.
Exibe o diff colorido. A opção --color (sem =<quando> por exemplo) é o mesmo que a opção --color=always. <quando> pode ser always (sempre), never (nunca), ou auto.
-Pode ser alterado pelas definições da configuração
-color.ui e color.diff.
Desativa o diff colorido.
-Pode ser utilizado para substituir a definição da configuração.
-É o mesmo que --color=never.
As linhas de código que foram movidas são coloridas de maneira diferente.
-Pode ser alterado através da pela definição da configuração diff.colorMoved.
-O <modo> retorna para a predefinição como no caso a opção não seja utilizada
-e para zebra caso a opção seja utilizada sem nenhum modo.
-O modo deve ser um dos seguintes:
As linhas movidas não são destacadas.
-É um sinônimo para zebra. Pode ser que isso mude para um modo mais sensível no futuro.
Qualquer linha adicionada num local e removida em outro será colorida com color.diff.newMoved. Da mesma forma, color.diff.oldMoved será utilizado para as linhas que forem removidas e que foram adicionadas em outro lugar no diff. Este modo seleciona qualquer linha movida, mas não é muito útil numa revisão para determinar se um bloco do código foi movido sem permutação.
-Os blocos de texto movidos com pelo menos 20 caracteres alfanuméricos são detectados de forma ávida. Os blocos detectados são pintados utilizando a cor color.diff.{old,new}Moved. Os blocos adjacentes não podem ser separados.
Os blocos de texto que foram movidos são detectados como no modo blocks (blocos). Os blocos são pintados utilizando a cor color.diff.{old,new}Moved ou color.diff.{old,new}MovedAlternative. A alteração entre as duas cores indica que um novo bloco foi detectado.
Semelhante ao zebra, porém é realizado o escurecimento adicional das partes desinteressantes do código que foi movido. As linhas limítrofes dos dois blocos adjacentes são considerados como interessantes, o resto como não interessante. dimmed_zebra é um sinônimo obsoleto.
Desativa a detecção de movimento. Pode ser utilizado para substituir a definição da configuração. É o mesmo que --color-moved=no.
Configura como o espaço é ignorado durante a execução da detecção do mover para --color-moved.
-Pode ser definido através da definição da variável de configuração diff.colorMovedWS.
-Estes modos podem ser utilizados como uma lista separada por vírgulas:
Não ignore os espaços quando realizar a detecção da ação de mover.
-Ignore as alterações no espaço na EOL (fim da linha).
-Ignore as alterações na quantidade do espaço. Ignora o espaço no final da linha e considera todas as outras sequências de um ou mais caracteres de espaço como equivalentes.
-Ignore o espaço durante a comparação das linhas. Ignore as diferenças mesmo que uma linha tenha espaços quando a outra linha não tiver nenhuma.
-Ignore inicialmente, qualquer espaço na detecção da ação de mover, em seguida, agrupe os blocos do código que foram movidos apenas num bloco caso a alteração no espaço seja a mesma em cada linha. Isto é incompatível com os outros modos.
-Não ignore os espaços quando realizar a detecção da ação de mover. Pode ser utilizado para substituir a definição da configuração. É o mesmo que --color-moved-ws=no.
Exiba umadiff entre as palavras, usando o <modo> para delimitar as palavras alteradas. É predefinido que as palavras sejam delimitadas por espaços; consulte --word-diff-regex abaixo. O <modo> retorna para a predefinição plain e deve ser um dos seguintes:
Destaque as palavras alteradas usando apenas as cores. Implica no uso da opção --color.
Exiba as palavras como [-removed-] (removido) e {+added+} (adicionado). Não faz nenhuma tentativa de escapar os delimitadores caso eles apareçam na entrada, portanto, a saída pode ser ambígua.
Use um formato especial orientado em linha destinado para a utilização com um script. As execuções adicionadas/removidas/inalteradas são impressas no formato diff unificado tradicional, começando com um caractere +/-/` ` no início da linha e estendendo-se até o final. As novas linhas na entrada são representadas por um til ~ numa linha própria.
Desative a palavra diff novamente.
-Observe que, apesar do nome do primeiro modo, a cor é utilizada para realçar as partes alteradas em todos os modos caso seja ativada.
-Utilize uma <expressão-regular> para decidir o que uma palavra é em vez de considerar as execuções dos espaços que não estejam vazios como uma palavra. Também implica no uso da opção --word-diff, a menos que já esteja ativo.
Toda a coincidência não sobreposta do <expressão-regular> é considerado como sendo uma palavra. Qualquer coisa entre estas coincidências é considerada um espaço e é ignorado(!) com o objetivo de encontrar as diferenças. Você pode anexar |[^[:space:]] à sua expressão regular para garantir que ela coincida com todos os caracteres que não sejam espaços. Uma coincidência que contenha uma nova linha é silenciosamente truncada(!) na nova linha.
A opção --word-diff-regex=. por exemplo, tratará cada caractere como uma palavra e coincidentemente, exibirá as diferenças caractere a caractere.
A expressão regular também pode ser definida através de um controlador do diff ou uma opção de configuração, consulte gitattributes[5] or git-config[1]. A concessão explícita substitui qualquer controle diff ou uma configuração. Os controles diff substituem as definições da configuração.
-Equivalente a --word-diff=color mais (caso um regex seja utilizado) --word-diff-regex=<expressão-regular>.
Desative a detecção da ação de renomear, mesmo quando o arquivo de configuração seja predefinido para tanto.
-Se usa ou não bolhas vazias como origem do nome.
-Avise caso as alterações introduzirem os marcadores de conflito ou os erros de espaço. A configuração core.whitespace define o que são considerados erros de espaço. É predefinido que os espaços à direita (incluindo as linhas que consistem apenas de espaços) e um caractere de espaço que seja imediatamente seguido por um caractere de tabulação dentro do recuo inicial da linha, são considerados erros de espaço. Encerra com uma condição diferente de zero caso problemas sejam encontrados. Não é compatível com --exit-code.
Destaque os erros de espaço nas linhas context (contexto), old (antigo) ou new (novo) do diff. Vários valores são separados por vírgula, none redefine os valores anteriores, default redefine a lista para new e all é uma abreviação para old,new,context. Quando esta opção não é utilizada e a variável de configuração diff.wsErrorHighlight não está definida, apenas os erros de espaço nas linhas novas são destacados. Os erros de espaço são coloridos com color.diff.whitespace.
Em vez do primeiro punhado de caracteres, exiba os nomes completos dos objetos bolha antes e depois da imagem na linha "index" ao produzir a saída no formato patch.
-Além de --full-index, gere um diff binário que possa ser aplicado com o comando git-apply.
-Implica no uso da opção --patch.
Em vez de exibir o nome completo do objeto hexadecimal com 40 bytes na produção do formato diff-raw e nas linhas do cabeçalho da árvore diff, exibe o prefixo mais curto que se refira de forma única ao objeto e que tenha até <n> hexdigits. No formato da produção da saída do diff-patch, a opção --full-index tem maior prioridade, ou seja, caso --full-index seja especificado o nome completo da bolha será exibido independente da opção --abbrev. A quantidade dos dígitos fora do preestabelecido pode ser especificado através da opção --abbrev=<n>.
Divida as alterações reescritas que foram completas em pares de exclusão e criação. Isso serve a dois propósitos:
-Afeta a maneira como uma mudança que equivale a uma reescrita total de um arquivo, não como uma série de exclusão e inserção combinadas com poucas linhas que coincidem textualmente com o contexto, e sim como uma única exclusão de tudo o que é antigo seguido por um inserção única de tudo que for novo, o número m controla este aspecto da opção -B (a predefinição retorna para 60%). -B / 70% determina que menos de 30% do original deve permanecer no resultado para que o Git considere-o como uma reescrita total (ou seja, caso contrário, o patch resultante será uma série de exclusões e inserções combinados com linhas de contexto).
Quando utilizado com a opção -M, um arquivo totalmente reescrito também é considerado a fonte de uma renomeação (O -M geralmente considera apenas um arquivo que desapareceu como a origem de uma renomeação), o número n controla esse aspecto da opção -B (a predefinição retorna para 50%). O -B20% determina que uma alteração com a adição e a exclusão em comparação com 20% ou mais do tamanho do arquivo é elegível para ser selecionada como uma possível fonte de renomeação para um outro arquivo.
Detecte as renomeações.
-Caso n seja utilizado, é a limítrofe do índice da similaridade
-(A quantidade de adições/exclusões comparado ao tamanho
-do arquivo). -M90% significa que o Git deve considerar uma ação do par de
-exclusão/adição para ser renomeado caso mais que 90% do arquivo
-não tenha sido alterado. Sem um sinal de %, a quantidade deve ser lida como
-uma fração, com um ponto decimal antes dele. -M5 se torna por exemplo
-0.5, portanto, é o mesmo que -M50%. Da mesma forma que -M05 é
-o mesmo que -M5%. Para limitar a detecção para renomeações exatas, utilize
--M100%. A predefinição para o índice de similaridade é 50%.
Detecte as cópias e também o que for renomeado. Consulte também --find-copies-harder. Caso n seja utilizado, ele terá o mesmo significado que -M<n>.
Por motivos de desempenho, a predefinição retorna para que a opção -C encontre as cópias apenas caso o arquivo original da cópia tenha sido modificado no mesmo conjunto de alterações. Essa flag faz com que o comando inspecione os arquivos que não modificados como candidatos à origem da cópia. Esta é uma operação muito dispendiosa em projetos grandes, portanto, utilize-a com cuidado. Tem o mesmo efeito caso a opção -C seja repetida.
Omita a imagem prévia que será excluída, ou seja, imprima apenas o cabeçalho, mas não a diferença entre a pré-imagem e /dev/null. O patch resultante não deve ser aplicado com com o comando patch ou git apply; é apenas para pessoas que desejam se concentrar em revisar o texto após a alteração. Além disso, a saída obviamente não possui informações suficientes para aplicar esse patch em sentido inverso, mesmo manualmente, daí o nome da opção.
Quando utilizado em conjunto com a opção -B, omita também a pré-imagem na parte da exclusão de um par excluir/criar.
As opções -M e -C precisa de algumas ações preliminares que podem detectar os subconjuntos das renomeações/cópias simples, seguidos por uma exaustiva porção de recursos que compara o resto de todos os destinos que ainda não foram reparados com todas as fontes relevantes. (Para as renomeações, apenas as fontes restantes que não foram pareadas são relevantes; nas cópias, todas as fontes originais são relevantes). Para N fontes e destinos, esta verificação exaustiva é O(N^2). Esta opção impede que a parte exaustiva da detecção de renomeamento/cópia seja executada caso a quantidade dos arquivos de origem/destino envolvidos exceda a quantidade definida. Caso contrário, retorna para o valor definido em diff.renameLimit. Observe que o valor 0 é tratado como ilimitado.
Selecione apenas os arquivos Adicionados (A), Copiados (C), Excluídos (D), Modificados (M), Renomeados (R) e que tenham o seu tipo (por exemplo, arquivo normal, link simbólico, o submódulo, …) alterado (T), não está mesclado (U), que seja desconhecido (X) ou que teve o seu emparelhamento quebrado (B). Qualquer combinação dos caracteres do filtro (incluindo none nenhum) pode ser utilizado. Quando * (Tudo ou nenhum) é adicionado à combinação, todos os caminhos são selecionados caso haja algum arquivo que coincida com outros critérios durante a comparação; caso não haja nenhum arquivo que coincida com outros critérios, nada será selecionado.
Além disso, estas letras maiúsculas podem ser transformadas em minúsculas para serem excluídas. O comando --diff-filter=ad exclui os caminhos adicionados e excluídos por exemplo.
Observe que nem todas as diferenças diff podem apresentar todos os tipos. Por exemplo, as entradas copiadas e renomeadas não podem aparecer caso a detecção para estes tipos estiverem desativados.
-Procure por diferenças que alterem a quantidade de ocorrências da cadeia de caracteres usada (ou seja, adição/exclusão) num arquivo. Destinado ao uso do scripter.
-Útil durante a produra por um bloco de código exato (como uma "struct"), e quera saber o histórico deste bloco desde que ele surgiu: utilize o recurso de forma iterativa para alimentar o bloco de interesse na pré-imagem de volta -S e continue até você obter a primeira versão do bloco.
Os arquivos binários também são pesquisados.
-Procure por diferenças cujo texto do patch contenha as linhas adicionadas/removidas que correspondam a um <expressão-regular>.
Para ilustrar a diferença entre -S<expressão-regular> --pickaxe-regex e -G<expressão-regular>, considere um commit com o seguinte diff no mesmo arquivo:
+ return frotz(nitfol, two->ptr, 1, 0); -... -- hit = frotz(nitfol, mf2.ptr, 1, 0);-
Enquanto o git log -G"frotz\(nitfol" exibirá este commit, já o git log -S"frotz\(nitfol" --pickaxe-regex não (porque a quantidade de ocorrências dessa cadeia de caracteres não foi alterada) .
A menos que --text seja utilizado, os patches dos arquivos binários sem um filtro "textconv" serão ignorados.
Para mais informações consulte a entrada pickaxe em gitdiffcore[7].
-Procure pelas diferenças que alteram a quantidade de ocorrências do objeto especificado. Similar ao -S, porém apenas o argumento é diferente pois ele não procura por uma sequência específica, mas por um ID específico do objeto.
O objeto pode ser uma bolha ou um commit do submódulo. Para também encontrar árvores, faça a utilização da opção -t também no git-log.
Quando a opção -S ou -G encontra uma alteração, exiba todas as alterações naquele conjunto de alterações e não apenas nos arquivos que contenham as alterações numa <texto>.
Trate o <texto> utilizado com o -S como uma expressão regular POSIX estendida para coincidir.
Controlar a ordem em que os arquivos aparecem na saída. Substitui a variável de configuração diff.orderFile (consulte git-config[1]). Para cancelar a variável diff.orderFile, utilize -O/dev/null.
A ordem da saída é determinada pela ordem dos padrões bolha na <ordem-do-arquivo>. São enviados primeiro todos os arquivos cujos nomes do caminho coincidam com o primeiro padrão, em seguida todos os arquivos cujos nomes do caminho coincidam com o segundo padrão (mas não ao primeiro) e assim por diante. São exibidos por último todos os arquivos cujos nomes do caminho não coincidam com nenhum padrão como se houvesse um padrão de coincidência total implícito no final do arquivo. Caso vários nomes do caminho tenham a mesma classificação (eles coincidem com o mesmo padrão, mas não com os padrões anteriores), a sua ordem na saída em relação à outra é a ordem normal.
-A <ordem-do-arquivo> é analisado da seguinte maneira:
-As linhas em branco são ignoradas para que possam ser utilizadas como separadores, facilitando a leitura.
-As linhas que começam com um hash ("#") são ignoradas para que possam ser utilizadas como comentários. Adicione uma barra invertida ("\") ao início do padrão caso ele comece com um hash.
Cada outra linha quem contenha um único padrão.
-Os padrões têm a mesma sintaxe e semântica que os padrões utilizados para fnmatch(3) sem a flag FNM_PATHNAME, exceto que um nome do caminho também coincida com um padrão caso a remoção de qualquer quantidade dos componentes finais do nome do caminho coincida com o padrão. O padrão "foo*bar" coincide com "fooasdfbar" e "foo/bar/baz/asdf" mas não com "foobarx" por exemplo.
Descarte os arquivos da saída antes do <arquivo> (ou seja, pule para), ou mova-os para o final da saída (ou seja, redirecione para). Estas opções foram inventadas para uso do comando git difftool e podem não ser muito úteis para outra coisa.
Troque as duas entradas; isto é, exiba as diferenças do índice ou do arquivo no disco para o conteúdo da árvore.
-Com esta opção, quando executado a partir de um subdiretório do projeto, pode-se dizer para excluir as alterações fora do diretório e exibir os nomes do caminho relativos a ele. Quando não estiver em um subdiretório (em um repositório simples por exemplo), é possível definir em qual subdiretório tornar a saída relativa, utilizando um <caminho> como argumento. A opção --no-relative pode ser utilizada para contrapor ambas as opções de configuração diff.relative e a anterior --relative.
Trate todos os arquivos como texto.
-Ignore o retorno do carro no final da linha durante uma comparação.
-Ignore as alterações no espaço na EOL (fim da linha).
-Ignore as alterações na quantidade do espaço. Ignora o espaço no final da linha e considera todas as outras sequências de um ou mais caracteres de espaço como equivalentes.
-Ignore o espaço durante a comparação das linhas. Ignore as diferenças mesmo que uma linha tenha espaços quando a outra linha não tiver nenhuma.
-Ignore as alterações cujas linhas estejam todas em branco.
-Ignore as alterações cujas linhas coincidam com a <expressão-regular>. Esta opção pode ser usada mais de uma vez.
-Exibe o contexto entre os blocos diff, até a quantidade de linhas usada, fundindo assim as que estão próximas umas das outras. A predefinição retorna para diff.interHunkContext ou 0 caso a opção de configuração não esteja definida.
Exibe toda a função como linhas de contexto para cada alteração. O nome da função é determinada da mesma maneira que o git diff lida com os pedaços do cabeçalhos do patch (consulte Definindo um cabeçalho personalizado do hunk em gitattributes[5]).
-Faça com que o programa encerre com códigos semelhantes ao diff(1). Ou seja, encerra com 1 caso haja diferenças ou 0 quando não houver.
-Disable all output of the program. Implies --exit-code. Disables execution of external diff helpers whose exit code is not trusted, i.e. their respective configuration option diff.trustExitCode or diff.<driver>.trustExitCode or environment variable GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE is false.
Permitir que um auxiliar diff externo seja executado. Caso um controlador diff externo seja definido com gitattributes[5], será necessário a utilização desta opção com git-log[1] e seus companheiros.
-Não permitir o uso de um controladores diff externo.
-Permita (ou não permita) a execução dos filtros externos para a conversão do texto durante a comparação dos arquivos binários. Para mais detalhes consulte gitattributes[5]. Como os filtros "textconv" são normalmente uma conversão unidirecional, o diff resultante é legível para as pessoas porém não pode ser aplicado. Por este motivo, é predefinido que os filtros "textconv" estejam ativos apenas para os comandos git-diff[1] e git-log[1], mas não para os comandos git-format-patch[1] ou comandos "diff" que possam ser redirecionados.
-Ignore as alterações nos submódulos durante a geração dos diffs. O <quando> pode ser "none" (nenhum), "untracked" (sem monitoramento/rastreamento), "dirty" (sujo) ou "all" (todos), que é a predefinição. O "none" considera o submódulo modificado quando houver arquivos não estejam rastreados, modificados ou o seu HEAD seja diferente do commit registrado no superprojeto, pode ser utilizado para substituir qualquer configuração da opção ignore (ignorar) em git-config[1] ou gitmodules[5]. Quando o "untracked" é utilizado, os submódulos não são considerados sujos quando houver apenas um conteúdo sem rastreamento (porém o monitoramento de alterações do seu conteúdo continua) O uso de "dirty" ignora todas as alterações na árvore de trabalho dos submódulos, apenas as alterações nos commits armazenados no superprojeto são exibidos (este era o comportamento anterior até a versão 1.7.0). O uso de "all" oculta todas as alterações nos submódulos.
Exiba o prefixo da origem utilizada em vez de "a/".
-Exiba o prefixo do destino utilizado em vez de "b/".
-Não exiba nenhum prefixo da origem ou destino.
-Use the default source and destination prefixes ("a/" and "b/"). This overrides configuration variables such as diff.noprefix, diff.srcPrefix, diff.dstPrefix, and diff.mnemonicPrefix (see git-config(1)).
Prefira um prefixo adicional em cada linha produzida.
-É predefinido que as entradas adicionadas através do comando "git add -N" apareçam como uma cadeia de caracteres vazia existente com o comando "git diff" e um novo arquivo com "git diff --cached". Esta opção faz com que a entrada apareça como um novo arquivo no "git diff" e inexistente no "git diff --cached". Esta opção pode ser revertida com --ita-visible-in-index. Ambas as opções são experimentais e podem ser removidas no futuro.
Para uma explicação mais detalhada sobre estas opções comuns, consulte também gitdiffcore[7].
-Compare a árvore de trabalho com a versão "base" (stage #1), "o nosso ramo" (stage #2) "o ramo deles" (stage #3). O índice contém estas etapas apenas para as entradas que não foram não mescladas enquanto estiver resolvendo os conflitos. Para obter informações mais detalhadas, consulte a seção "3-Way Merge" git-read-tree[1].
-Omita a saída diff para as entradas que não tenham sido mescladas e exiba "Unmergedd". Só pode ser utilizado quando comparamos a árvore de trabalho com o índice.
-Os parâmetros <paths>, quando utilizados, são para limitar o diff quanto aos nomes dos caminhos (você pode dar nomes de diretórios e obter um diff para todos os arquivos sob eles).
O formato bruto gerado com os comandos "git-diff-index", "git-diff-tree", "git-diff-files" e "git diff --raw" são muito parecidos.
-Todos estes comandos comparam dois conjuntos de coisas; o que é comparado difere de:
-compara a <árvore> e os arquivos no sistema de arquivos.
-compara a <árvore> e o índice.
-compara as árvores citadas pelos dois argumentos.
-compara o índice e os arquivos no sistema de arquivos.
-O comando "git-diff-tree" inicia a sua saída imprimindo o hash do que está sendo comparado. Depois disso, todos os comandos imprimem uma linha na saída por arquivo modificado.
-A linha na saída é formatada da seguinte maneira:
-edição no local :100644 100644 bcd1234 0123456 M arquivo0 -copiar editar :100644 100644 abcd123 1234567 C68 arquivo1 arquivo2 -renomear editar :100644 100644 abcd123 1234567 R86 arquivo1 arquivo3 -criar :000000 100644 0000000 1234567 A arquivo4 -excluir :100644 000000 1234567 0000000 D arquivo5 -não mesclado :000000 000000 0000000 0000000 U arquivo6-
Ou seja, da esquerda para a direita:
-dois pontos.
-Um modo para "src"; 000000 caso seja criado ou não mesclado.
-um espaço.
-O modo para "dst"; 000000 caso seja excluído ou não mesclado.
-um espaço.
-sha1 para "src"; 0{40} caso seja criado ou não mesclado.
-um espaço.
-sha1 para "dst"; 0{40} caso seja excluído, não mesclado ou "a árvore de trabalho sem sincronismo com o índice".
-um espaço.
-status, seguido pelo número "score" opcional.
-uma aba ou um NUL quando a opção -z é utilizada.
path para "src"
-uma aba ou um NUL quando a opção -z é utilizada; existe apenas para C ou R.
path para "dst"; existe apenas para C ou R.
-um LF ou um NUL quando a opção -z é utilizada para finalizar o registro.
As possíveis letras que exibem a condição são:
-A: a adição de um arquivo
-C: a cópia de um arquivo para um novo
-D: a exclusão de um arquivo
-M: a modificação do conteúdo ou do modo de um arquivo
-R: uma renomeação de um arquivo
-T: altera o tipo do arquivo (arquivo regular, link simbólico ou submódulo)
-U: o arquivo está sem mesclagem (você deve concluir a mesclagem antes que o commit possa ser feito)
-X: um tipo de alteração "desconhecida" (provavelmente um bug, por favor denuncie)
-As letras de condição C e R sempre são seguidas por uma pontuação (indicando a porcentagem da semelhança entre a origem e o destino da movimentação ou da cópia). A letra de condição M pode ser seguida por uma pontuação (denotando a porcentagem de dissimilaridade) para reescrever os arquivos.
-O sha1 para "dst" é exibido zerado caso um arquivo no sistema de arquivos esteja fora de sincronia com o índice.
-Exemplo:
-:100644 100644 5be4a4a 0000000 M file.c-
Sem a opção z, os pathnames com os caracteres "incomuns" são citados conforme explicado na variável de configuração core.quotePath (consulte git-config[1]). Utilizando a opção -z, o nome do arquivo é gerado literalmente e a linha é finalizada com um byte NUL.
Os comandos "git-diff-tree", "git-diff-files" e "git-diff --raw" podem utilizar as opções -c ou --cc para também gerar uma saída "diff" com os commits mesclados. A saída difere do formato descrito acima da seguinte maneira:
há dois pontos para cada origem
-existem mais modos "src" e "src" sha1
-a condição é concatenada como uma condição dos caracteres para cada origem
-sem um número "score" opcional
-os caminho(s) separado(s) por tabulações do arquivo
-Para as opções -c e --cc apenas o destino ou o caminho final é exibido ainda que o arquivo tenha sido renomeado em qualquer parte do histórico. Com a opção --combined-all-paths, o nome do caminho em cada origem é exibido seguido pelo nome do caminho durante a mesclagem do commit.
Exemplos para as opções -c e --cc sem utilizar a opção --combined-all-paths:
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c -::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM bar.sh -::100644 100644 100644 e07d6c5 9042e82 ee91881 RR phooey.c-
Exemplos quando a opção --combined-all-paths é adicionado entre -c ou --cc:
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c desc.c desc.c -::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM foo.sh bar.sh bar.sh -::100644 100644 100644 e07d6c5 9042e82 ee91881 RR fooey.c fuey.c phooey.c-
Note que o diff combinado lista apenas os arquivos que foram alterados em todas as origems.
--pExecutando git-diff[1], git-log[1], git-show[1], git-diff-index[1], git-diff-tree[1], ou git-diff-files[1] com a opção -p produz um patch em formato texto. É possível personalizar a criação do patch em um formato texto através das variáveis de ambiente GIT_EXTERNAL_DIFF, GIT_DIFF_OPTS (consulte git[1]) e o atributo diff (consulte gitattributes[5]).
What the -p option produces is slightly different from the traditional diff format:
Ele é precedido por um cabeçalho "git diff" que se parece com:
-diff --git a/arquivo1 b/arquivo2-
Os nomes dos arquivos a/ e b/ são os mesmos a menos que haja uma renomeação ou cópia. Especialmente para uma criação ou exclusão, /dev/null não é utilizado no lugar dos nomes do arquivo a/ ou b/.
Quando há um envolvimento no processo de renomear ou copiar, arquivo1 e arquivo2 exibem o nome do arquivo de origem da renomeação ou cópia e o nome do arquivo produzido pela renomeação ou copia respectivamente.
É seguido por uma ou mais linhas estendidas do cabeçalho:
-old mode <mode> -new mode <mode> -deleted file mode <mode> -new file mode <mode> -copy from <path> -copy to <path> -rename from <path> -rename to <path> -similarity index <number> -dissimilarity index <number> -index <hash>..<hash> <mode>
-File modes <mode> are printed as 6-digit octal numbers including the file type and file permission bits.
-Os nomes do caminho nos cabeçalhos estendidos não incluem os prefixos a/ e b/.
O índice de similaridade é a porcentagem das linhas inalteradas e o índice de dissimilaridade é a porcentagem das linhas alteradas. É um número inteiro arredondado, seguido por um sinal de porcentagem. O valor do índice de similaridade de 100% é reservado para dois arquivos iguais, enquanto a dissimilaridade de 100% significa que nenhuma linha do arquivo antigo chegou ao novo.
-The index line includes the blob object names before and after the change. The <mode> is included if the file mode does not change; otherwise, separate lines indicate the old and the new mode.
-Os nomes dos caminhos com caracteres "incomuns" são citados como já explicado na variável de configuração core.quotePath (consulte git-config[1]).
Todos os arquivos arquivo1 na saída se referem aos arquivos antes do commit e todos os arquivos arquivo2 se referem aos arquivos após o commit. É incorreto aplicar cada alteração em cada arquivo sequencialmente. Por exemplo, este patch irá substituir a e b:
diff --git a/a b/b -renomeie a partir de a -renomeie para b -diff --git a/b b/a -renomeie a partir do b -renomeie para a-
Os cabeçalhos "hunk" mencionam o nome da função à qual o "hunk" se aplica. Consulte "Definindo um cabeçalho personalizado do hunk" em gitattributes[5] para detalhes de como adaptar a isto e para linguagens específicas.
-Qualquer comando que gere um diff pode utilizar a opção -c ou`--cc` para produzir um diff combinado ao mostrar uma mesclagem. Este é o formato predefinido ao mostrar as mesclagens com git-diff[1] ou git-show[1]. Observe também que é possível usar a opção --diff-merges que é adequada para qualquer um destes comandos para impor a geração dos diffs num determinado formato.
Um formato "diff combinado" fica assim:
-diff --combined describe.c
-index fabadb8,cc95eb0..4866510
---- a/describe.c
-+++ b/describe.c
-@@@ -98,20 -98,12 +98,20 @@@
- return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
- }
-
-- static void describe(char *arg)
- -static void describe(struct commit *cmit, int last_one)
-++static void describe(char *arg, int last_one)
- {
- + unsigned char sha1[20];
- + struct commit *cmit;
- struct commit_list *list;
- static int initialized = 0;
- struct commit_name *n;
-
- + if (get_sha1(arg, sha1) < 0)
- + usage(describe_usage);
- + cmit = lookup_commit_reference(sha1);
- + if (!cmit)
- + usage(describe_usage);
- +
- if (!initialized) {
- initialized = 1;
- for_each_ref(get_name);
-Ele é precedido por um cabeçalho "git diff" parecido com este (quando a opção -c é utilizada):
diff --combined arquivo-
ou assim (quando a opção --cc é utilizada):
diff --cc arquivo-
Ele é seguido por uma ou mais linhas estendidas do cabeçalho (este exemplo exibe uma mesclagem com duas origens):
-index <hash>,<hash>..<hash>
-mode <mode>,<mode>..<mode>
-new file mode <mode>
-deleted file mode <mode>,<mode>
The mode <mode>,<mode>..<mode> line appears only if at least one of the <mode> is different from the rest. Extended headers with information about detected content movement (renames and copying detection) are designed to work with the diff of two <tree-ish> and are not used by combined diff format.
É seguido por duas linhas do cabeçalho do arquivo/para o arquivo:
---- a/arquivo -+++ b/arquivo-
Semelhante ao cabeçalho de duas linhas para o formato diff tradicional unificado, o /dev/null é utilizado para sinalizar os arquivos criados ou excluídos.
No entanto, caso a opção --combined-all-paths seja utilizada, em vez de duas linhas do arquivo/para o arquivo, será obtido um cabeçalho N+1 do cabeçalho do arquivo de "origem" para o arquivo de "destino" onde N é a quantidade de origens na mesclagem do commit:
--- a/arquivo ---- a/arquivo ---- a/arquivo -+++ b/arquivo-
Este formato estendido pode ser útil caso a detecção da renomeação ou cópia esteja ativa, permitindo que você veja o nome original do arquivo em diferentes origens.
-O formato do cabeçalho do pedaço é modificado para prevenir que as pessoas o alimentem acidentalmente com patch -p1. O formato diff combinado foi criado para revisar as alterações da mesclagem dos commits e não era para ser aplicado. A alteração é semelhante a alteração no cabeçalho estendido do índice:
@@@ <from-file-range> <from-file-range> <to-file-range> @@@-
Existem (a quantidade de origens + 1) caracteres @ no cabeçalho do bloco para o formato diff combinado.
Diferente do formato diff unificado tradicional que exiba os dois arquivos A e B com uma única coluna que possua o sinal de menos - (o sinal de menos — aparece em A mas é removido em B), + (o sinal de mais — ausente em A, mas adicionado em B), ou o prefixo " " (sem alteração — de espaço), este formato compara dois ou mais arquivos arquivo1, arquivo2, … com um arquivo X e exibe como X difere de cada arquivoN. Uma coluna para cada arquivoN é anexada à linha de saída para observar como a linha de X é diferente dela.
Um caractere - na coluna N significa que a linha aparece no "arquivoN", mas não aparece no resultado. Um caractere + na coluna N significa que a linha aparece no resultado e o arquivoN não possui essa linha (em outras palavras, a linha foi adicionada, do ponto de vista dessa origem).
Na saída do exemplo acima, a assinatura da função foi alterada nos dois arquivos (portanto, duas remoções - do arquivo1 e do arquivo2, mais ++ significa que uma linha que foi adicionada não aparece no arquivo1 ou no arquivo2). Assim como, outras oito linhas também são iguais no arquivo1, mas não aparecem no arquivo2 (portanto, prefixadas com +).
Quando exibido pelo comando git diff-tree -c, compara as origens de um commit mesclado com o resultado da mesclagem (ou seja, arquivo1..arquivoN são as origens). Quando exibido pelo comando git diff-files -c, as duas origens com as suas respectivas mesclagens não resolvidas com o arquivo da árvore de trabalho (ou seja, arquivo1 é o estágio 2, informado como "nossa versão", o arquivo2 é o estágio 3, informado como "a versão deles").
A opção --summary descreve os arquivos adicionados, excluídos, renomeados e copiados recentemente. A opção --stat adiciona o grafo diffstat(1) à saída. Estas opções podem ser combinadas com outras opções como -p, que são legíveis para nós.
Ao exibir uma alteração que envolva uma renomeação ou uma cópia, a saída do comando --stat formata os nomes do caminho de forma compacta combinando o prefixo e sufixo comum aos nomes do caminho. Uma alteração que mova arch/i386/Makefile para arch/x86/Makefile enquanto modifica as 4 linhas será exibido assim:
arch/{i386 => x86}/Makefile | 4 +--
-A opção --numstat fornece as informações diffstat(1), foi projetada para facilitar o consumo da máquina. Uma entrada na saída --numstat fica assim:
1 2 README
-3 1 arch/{i386 => x86}/Makefile
-Ou seja, da esquerda para a direita:
-a quantidade das linhas que foram adicionadas;
-um separador;
-a quantidade de linhas que foram excluídas;
-um separador;
-nome do caminho (possivelmente com informações para renomear ou copiar);
-uma nova linha.
-Quando a opção de saída -z está em vigor, a saída é formatada desta maneira:
1 2 README NUL -3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL-
Isso é:
-a quantidade das linhas que foram adicionadas;
-um separador;
-a quantidade de linhas que foram excluídas;
-um separador;
-um NUL (apenas existe caso seja renomeado ou copiado);
-nome do caminho na pré-imagem;
-um NUL (apenas existe caso seja renomeado ou copiado);
-nome do caminho na pós-imagem (só existe se for renomeado ou copiado);
-um NUL.
-O NUL extra antes do caminho da pré-imagem é renomeado para permitir que os scripts que leem a saída digam se o registro atual que está sendo lido é um registro do caminho único ou um nome para a renomeação ou cópia sem fazer a leitura adiante. Depois de ler as linhas adicionadas e excluídas, a leitura até o NUL produziria o nome do caminho, mas caso seja um NUL, o registro exibirá dois caminhos.
$ git diff (1) -$ git diff --cached (2) -$ git diff HEAD (3) -$ git diff AUTO_MERGE (4)-
As mudanças na árvore de trabalho ainda não preparadas para o próximo commit.
-As alterações entre o índice e o seu último commit; o que você estaria fazendo no commit caso você executasse o comando git commit sem a opção -a.
As alterações na árvore de trabalho desde o seu último commit; o que você estaria fazendo no commit caso executasse o comando git commit -a
As alterações na árvore de trabalho que você fez para resolver os conflitos textuais até o momento.
-$ git diff test (1) -$ git diff HEAD -- ./test (2) -$ git diff HEAD^ HEAD (3)-
Em vez de utilizar o cume do ramo atual, compare com o cume do ramo "teste".
-Em vez de comparar com o cume do ramo "teste", compare com o cume do ramo atual, limitando-se a comparação com o arquivo "teste".
-Compare a versão antes do último commit e o último commit.
-$ git diff topic master (1) -$ git diff topic..master (2) -$ git diff topic...master (3)-
As alterações entre as dicas do tópico e as ramificações principais.
-O mesmo que acima.
-As alterações que ocorreram na ramificação master (mestre) desde quando a ramificação do tópico foi iniciada.
-$ git diff --diff-filter=MRC (1) -$ git diff --name-status (2) -$ git diff arch/i386 include/asm-i386 (3)-
Exibe apenas as modificações, renomeações e cópias, mas não a adição ou exclusão.
-Exibe apenas os nomes e a natureza da alteração, mas não a saída diff real.
-Limite a saída diff aos nomes das subárvores.
-$ git diff --find-copies-harder -B -C (1) -$ git diff -R (2)-
Gaste alguns ciclos extras para encontrar renomeações, cópias e reescritas completas (muito custoso ao sistema).
-Saída do diff em reverso.
-Tudo abaixo desta linha nesta seção, está seletivamente incluído na documentação git-config[1]. O conteúdo é o mesmo que é encontrado ali:
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
diff(1), git-difftool[1], git-log[1], gitdiffcore[7], git-format-patch[1], git-apply[1], git-show[1]
-Parte do conjunto git[1]
-git grep [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp] - [-v | --invert-match] [-h|-H] [--full-name] - [-E | --extended-regexp] [-G | --basic-regexp] - [-P | --perl-regexp] - [-F | --fixed-strings] [-n | --line-number] [--column] - [-l | --files-with-matches] [-L | --files-without-match] - [(-O | --open-files-in-pager) [<pager>]] - [-z | --null] - [ -o | --only-matching ] [-c | --count] [--all-match] [-q | --quiet] - [--max-depth <depth>] [--[no-]recursive] - [--color[=<when>] | --no-color] - [--break] [--heading] [-p | --show-function] - [-A <post-context>] [-B <pre-context>] [-C <context>] - [-W | --function-context] - [(-m | --max-count) <num>] - [--threads <num>] - [-f <file>] [-e] <pattern> - [--and|--or|--not|(|)|-e <pattern>…] - [--recurse-submodules] [--parent-basename <basename>] - [ [--[no-]exclude-standard] [--cached | --no-index | --untracked] | <tree>…] - [--] [<pathspec>…]-
作業ツリー内の追跡されたファイルやインデックスファイルに登録された Blob、または指定されたツリーオブジェクト内の Blob で指定されたパターンを検索します。パターンは改行文字で区切られた 1つ以上の検索式のリストです。検索式として空の文字列を指定するとすべての行に一致します。
-作業ツリー内の追跡されたファイルを検索する代わりに、インデックスファイルに登録されている Blob を検索します。
-Git によって管理されていない現在のディレクトリ内のファイルを検索します。
-作業ツリー内の追跡されたファイルだけでなく、追跡されていないファイルも検索します。
-.gitignore メカニズムを無視して、無視されたファイル内も検索します。--untracked との併用で役立ちます。
.gitignore メカニズムで指定された無視されたファイルには注意を払いません。--no-index を使用して現在のディレクトリ内のファイルを検索する場合に役立ちます。
リポジトリ内でアクティブでチェックアウトされている各サブモジュールを再帰的に検索します。<tree> オプションと組み合わせて使用すると、すべてのサブモジュール出力のプレフィックスは親プロジェクトの <tree> オブジェクトの名前になります。--no-index が指定されている場合、このオプションは効果がありません。
バイナリファイルをテキストのように処理します。
-textconv フィルター設定を使用します。
-textconv フィルター設定を使用しません。これがデフォルトです。
-パターンとファイルの大文字と小文字の違いを無視します。
-バイナリファイル内のパターンを一致させない。
-コマンドラインで指定された各 <pathspec> について、最大 <depth> レベルのディレクトリまで降りていきます。値 -1 は制限がないことを意味します。このオプションは、<pathspec> にアクティブなワイルドカードが含まれている場合は無視されます。つまり、"a*" が "a*" という名前のディレクトリと一致する場合、"*" は文字通り一致するため、--max-depth は引き続き有効です。
---max-depth=-1 と同じです。これがデフォルトです。
--max-depth=0 と同じです。
パターンは単語境界でのみ一致します (行の先頭で始まるか、単語以外の文字が先行するか、行の末尾で終わるか、単語以外の文字が後に続きます)。
-一致しない行を選択します。
-デフォルトでは、コマンドは一致する各ファイル名を表示します。-h オプションは、この出力を抑制するために使用されます。-H は完全性のために存在し、コマンドラインで先に指定された -h を上書きする以外は何も行いません。
サブディレクトリから実行すると、コマンドは通常、現在のディレクトリを基準としたパスを出力します。このオプションは、パスがプロジェクトのトップディレクトリを基準として出力されるように強制します。
-パターンには POSIX 拡張/基本正規表現を使用します。デフォルトでは基本正規表現が使用されます。
-パターンには Perl 互換の正規表現を使用します。
-Support for these types of regular expressions is an optional compile-time dependency. If Git wasn’t compiled with support for them providing this option will cause it to die.
-パターンには固定文字列を使用します (パターンを正規表現として解釈しません)。
-一致する行の前に行番号を付けます。
-一致する行の先頭から最初の一致の 1 インデックス バイト オフセットをプレフィックスとして追加します。
-一致した行をすべて表示するのではなく、一致した行を含む (あるいは含まない) ファイル名のみを表示します。 git diff との互換性を高めるために、--name-only は --files-with-matches の同義語です。
Open the matching files in the pager (not the output of grep). If the pager happens to be "less" or "vi", and the user specified only one pattern, the first file is positioned at the first match automatically. The pager argument is optional; if specified, it must be stuck to the option without a space. If pager is unspecified, the default pager will be used (see core.pager in git-config[1]).
Use \0 as the delimiter for pathnames in the output, and print them verbatim. Without this option, pathnames with "unusual" characters are quoted as explained for the configuration variable core.quotePath (see git-config[1]).
-一致する行の一致した部分 (空でない部分) のみを、それぞれ別々の行に出力します。
-一致した行をすべて表示するのではなく、一致する行の数を表示します。
-一致内容を色付きで表示します。値は always (デフォルト)、never、または auto のいずれかである必要があります。
-設定ファイルでデフォルトでカラー出力が指定されている場合でも、一致の強調表示をオフにします。--color=never と同じです。
異なるファイルからの一致の間に空行を出力します。
-表示される各行の先頭ではなく、そのファイル内の一致の上にファイル名を表示します。
-一致する行が関数名自体でない限り、一致する関数名を含む前の行を表示します。名前は、git diff がパッチ ハンク ヘッダーを処理するのと同じ方法で決定されます (gitattributes[5] の「カスタム ハンク ヘッダーの定義」を参照)。
<num> 行の先頭と末尾を表示し、連続する一致グループの間に -- を含む行を配置します。
<num> 行末を表示し、連続する一致グループの間に -- を含む行を配置します。
<num> 行の先頭を表示し、連続する一致グループの間に -- を含む行を配置します。
関数名を含む前の行から次の関数名の前までの周囲のテキストを表示し、一致が見つかった関数全体を効果的に表示します。関数名は、git diff がパッチ ハンク ヘッダーを処理するのと同じ方法で決定されます (gitattributes[5] の「カスタム ハンク ヘッダーの定義」を参照)。
ファイルごとの一致件数を制限します。-v または --invert-match オプションを使用すると、指定した件数の不一致が検出されると検索が停止します。値 -1 を指定すると、無制限の結果が返されます (デフォルト)。値 0 を指定すると、ゼロ以外のステータスで直ちに終了します。
使用する grep ワーカー スレッドの数。詳細については、CONFIGURATION の grep.threads を参照してください。
<file> からパターンを 1 行に 1 つずつ読み取ります。
-Passing the pattern via <file> allows for providing a search pattern containing a \0.
-Not all pattern types support patterns containing \0. Git will error out if a given pattern type can’t support such a pattern. The --perl-regexp pattern type when compiled against the PCRE v2 backend has the widest support for these types of patterns.
In versions of Git before 2.23.0 patterns containing \0 would be silently considered fixed. This was never documented, there were also odd and undocumented interactions between e.g. non-ASCII patterns containing \0 and --ignore-case.
In future versions we may learn to support patterns containing \0 for more search backends, until then we’ll die when the pattern type in question doesn’t support them.
-The next parameter is the pattern. This option has to be used for patterns starting with - and should be used in scripts passing user input to grep. Multiple patterns are combined by or.
Specify how multiple patterns are combined using Boolean expressions. --or is the default operator. --and has higher precedence than --or. -e has to be used for all patterns.
When giving multiple pattern expressions combined with --or, this flag is specified to limit the match to files that have lines to match all of them.
Do not output matched lines; instead, exit with status 0 when there is a match and with non-zero status when there isn’t.
-Instead of searching tracked files in the working tree, search blobs in the given trees.
-Signals the end of options; the rest of the parameters are <pathspec> limiters.
-If given, limit the search to paths matching at least one pattern. Both leading paths match and glob(7) patterns are supported.
-<パススペック>構文の詳細については、gitglossary[7] の’パススペック’の項目を参照してください。
-git grep 'time_t' -- '*.[ch]' Looks for time_t in all tracked .c and .h files in the working directory and its subdirectories.
git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \) Looks for a line that has #define and either MAX_PATH or PATH_MAX.
git grep --all-match -e NODE -e Unexpected Looks for a line that has NODE or Unexpected in files that have lines that match both.
git grep solution -- :^Documentation Looks for solution, excluding files in Documentation.
The --threads option (and the grep.threads configuration) will be ignored when --open-files-in-pager is used, forcing a single-threaded execution.
When grepping the object store (with --cached or giving tree objects), running with multiple threads might perform slower than single threaded if --textconv is given and there are too many text conversions. So if you experience low performance in this case, it might be desirable to use --threads=1.
このセクションのこの行以下は、 git-config[1] のドキュメントから抜粋して含まれています。内容は同ドキュメントにあるものと同じです:
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Part of the git[1] suite
-git init-db [-q | --quiet] [--bare] [--template=<Template_Verzeichnis>] [--separate-git-dir <Git-Verzeichnis>] [--shared[=<Zugriffsrechte>]]-
Dies ist ein Synonym für git-init[1]. Bitte lesen Sie die Dokumentation dieses Kommandos.
-Teil der git[1] Suite
-git-init-db – Erstellt ein leeres Git-Repository oder initialisiert ein vorhandenes erneut
-git init [-q | --quiet] [--bare] [--template=<template-directory>] - [--separate-git-dir <git-dir>] [--object-format=<format>] - [-b <branch-name> | --initial-branch=<branch-name>] - [--shared[=<permissions>]] [<directory>]-
Dieser Befehl erzeugt ein leeres Git-Repository – im Grunde ein .git-Verzeichnis mit Unterverzeichnissen für objects, refs/heads, refs/tags und für die Template-Dateien. Eine initialer Branch ohne jegliche Commits wird erstellt (siehe die Option --initial-branch unten für dessen Namen).
Wenn die Umgebungsvariable $GIT_DIR gesetzt ist, dann gibt sie einen Pfad an, der anstelle von ./.git für die Basis des Repositorys verwendet werden soll.
If the object storage directory is specified via the $GIT_OBJECT_DIRECTORY environment variable then the sha1 directories are created underneath; otherwise, the default $GIT_DIR/objects directory is used.
Das Ausführen von git init in einem bestehenden Repository ist ungefährlich. Es wird nichts überschrieben, was dort bereits vorhanden ist. Der Hauptgrund für das erneute Ausführen von git init ist das Aufnehmen neu hinzugefügter Templates (oder das Verschieben des Repositorys an einen anderen Ort, wenn --separate-git-dir angegeben wird).
Nur Fehler- und Warnmeldungen ausgeben; alle anderen Meldungen werden ausgeblendet.
-Erstellt ein Bare-Repository. Wenn die Umgebungsvariable GIT_DIR nicht festgelegt ist, wird sie auf das aktuelle Arbeitsverzeichnis angewendet.
Spezifiziert das angegebene Objektformat (Hash-Algorithmus) für das Repository. Die gültigen Werte sind sha1 und, falls aktiviert, sha256. sha1 ist die Voreinstellung.
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Gib das Verzeichnis an, aus dem Templates verwendet werden sollen (Siehe unten den Abschnitt „TEMPLATE VERZEICHNIS“).
-Instead of initializing the repository as a directory to either $GIT_DIR or ./.git/, create a text file there containing the path to the actual repository. This file acts as a filesystem-agnostic Git symbolic link to the repository.
If this is a reinitialization, the repository will be moved to the specified path.
-Verwendet den angegebenen Namen für den initialen Branch im neu erstellten Repository. Falls nicht angegeben, wird auf den Standardnamen zurückgegriffen (derzeit master, aber dies kann sich in Zukunft ändern; der Name kann über die Konfigurationsvariable init.defaultBranch angepasst werden).
Bestimmt, dass das Git-Repository von mehreren Benutzern gemeinsam genutzt werden soll. Dadurch können Benutzer, die derselben Gruppe angehören, in dieses Repository pushen. Falls spezifiziert, wird die config-Variable "core.sharedRepository" so angelegt, dass Dateien und Verzeichnisse unter $GIT_DIR mit den angeforderten Berechtigungen erstellt werden. Wenn nichts angegeben ist, wird Git die von umask(2) gelieferten Berechtigungen verwenden.
Die Option kann die folgenden Werte annehmen, wobei group die Standardeinstellung ist, falls kein Wert angegeben wird:
-Verwendet die von umask(2) gelieferten Berechtigungen. Die Voreinstellung, falls --shared nicht angegeben ist.
Make the repository group-writable, (and g+sx, since the git group may not be the primary group of all users). This is used to loosen the permissions of an otherwise safe umask(2) value. Note that the umask still applies to the other permission bits (e.g. if umask is 0022, using group will not remove read privileges from other (non-group) users). See 0xxx for how to exactly specify the repository permissions.
-Das gleiche wie group, aber macht das Repository für alle Benutzer lesbar.
-<perm> is a 3-digit octal number prefixed with 0 and each file will have mode <perm>. <perm> will override users' umask(2) value (and not only loosen permissions as group and all do). 0640 will create a repository which is group-readable, but not group-writable or accessible to others. 0660 will create a repo that is readable and writable to the current user and group, but inaccessible to others (directories and executable files get their x bit from the r bit for corresponding classes of users).
Standardmäßig ist das Konfigurationsflag receive.denyNonFastForwards in gemeinsam genutzten Repositorys aktiviert, sodass Sie keinen „non-fast-forward“ Push erzwingen können.
Wenn Sie ein Directory (Verzeichnis) angeben, wird der Befehl innerhalb dieses Verzeichnisses ausgeführt. Wenn dieses Verzeichnis nicht existiert, wird es erstellt.
-Dateien und Verzeichnisse im Template-Verzeichnis, deren Name nicht mit einem Punkt beginnt, werden nach der Erstellung in das $GIT_DIR kopiert.
Das Template-Verzeichnis wird aus folgender Einstellung generiert (Reihenfolge nach Priorität):
-dem Argument, das mit der Option --template angegeben wurde;
dem Inhalt der Umgebungs-Variablen $GIT_TEMPLATE_DIR;
der Konfigurations-Variablen init.templateDir; oder
dem standardmäßigen Template-Verzeichnis: /usr/share/git-core/templates.
Das standardmäßige Template-Verzeichnis enthält eine gewisse Verzeichnisstruktur, vorgeschlagene „Ausschlussmuster“ (siehe gitignore[5]) und Beispiele für Hook-Dateien.
-Die Beispiel-Hooks sind automatisch alle deaktiviert. Diese Hooks können aktiviert werden, indem die Datei-Erweiterung .sample entfernt wird.
Siehe githooks[5] für generelle Informationen zur Hook-Anwendung.
-$ cd /Pfad/zu/meiner/Code-Basis -$ git init (1) -$ git add . (2) -$ git commit (3)-
Erstellt das Verzeichnis /Pfad/zu/meiner/Code-Basis/.git.
-Fügt alle vorhandenen Dateien zum Index hinzu.
-Zeichnet den Urzustand als ersten Commit im Verlauf des Repositorys auf.
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Teil der git[1] Suite
-git init [-q | --quiet] [--bare] [--template=<sniðmótaskrá>] - [--separate-git-dir <git-skrá>] [--object-format=<snið>] - [-b <nafn greinar> | --initial-branch=<nafn greinar>] - [--shared[=<leyfi>]] [directory]-
Þessi skipun býr til tóma Git hirslu - í raun .git skrá með undirskrám fyrir objects (viðföng), refs/heads (tilvísanir/hausar), refs/tags (tilvísanir/merki), og sniðmátsskjöl. Upphafsgrein án innleggja verður búin til (sjá --initial-branch valmöguleikann hér að neðan fyrir heiti hennar).
Ef $GIT_DIR umhverfisbreytan er uppgefin þá tilgreinir hún slóð til þess að nota í staðinn fyrir ./.git fyrir grunnbyggingu hirslunnar.
If the object storage directory is specified via the $GIT_OBJECT_DIRECTORY environment variable then the sha1 directories are created underneath; otherwise, the default $GIT_DIR/objects directory is used.
Að framkvæma git init í hirslu sem þegar er til er öruggt. Það mun ekki skrifa yfir það sem þegar er í hirslunni. Helsta ástæðan fyrir því að endurframkvæma git init er til þess að taka með sniðmát sem nýlega hefur verið bætt við (eða til þess að færa hirsluna á nýjan stað ef --separate-git-dir (aðskilinn git skrá) er gefið upp).
-Prenta einungis villu- og varnaðarboð; allt annað frálag er þaggað.
-Búa til nakta hirslu. Ef GIT_DIR(git skrá) umhverfisbreytan er ekki tilgreind er hirslan búin til í núgildandi vinnuskrá.
Gefa upp snið viðkomandi viðfangs (reikniforskrift mylnuskrár) fyrir hirsluna. Gild gildi eru sha1 og (ef virkt) sha256. Forstillingin er sha1.
-ÞESSI VALMÖGULEIKI ER Á TILRAUNASTIGI! SHA-256-stuðningur er á tilraunastigi og enn á frumstigi. Hirsla sem hefur SHA-256 er almennt ekki fær um að deila vinnu með "venjulegum" SHA-1-hirslum. Til dæmis ætti að gera ráð fyrir því að innviðaskjalasnið Git sem tengjast SHA-256 geti breyst þannig að þau verði ekki samhæfanleg aftur í tímann. Notaðu `--object-format=sha256`einungis í prófunum.
-Tilgreina skrána sem geymir þau sniðmót sem verða notuð. (Sjá "SNIÐMÁTASKRÁ" hlutann hér að neðan.)
-Instead of initializing the repository as a directory to either $GIT_DIR or ./.git/, create a text file there containing the path to the actual repository. This file acts as a filesystem-agnostic Git symbolic link to the repository.
If this is a reinitialization, the repository will be moved to the specified path.
-Notaðu tiltekið nafn fyrir upphafsgrein hinnar nýsköpuðu hirslu. Ef ekkert er tilgreint, nota sjálfgefið nafn (sem er master eins og er, en það gæti breyst í framtíðinni; hægt er að breyta sjálfgefnu nafni með stillingabreytunni init.defaultBranch).
Tilgreina að Git hirslunni muni verða deilt meðal fjölmargra notenda. Þetta leyfir notendum sem tilheyra sama hópi að ýta gögnum inn í þá hirslu. Þegar þessi tilgreining er til staðar er stillingabreytan "core.sharedRepository" (kjarni deild hirsla) stillt þannig að skjöl og skrár undir $GIT_DIR (git skrá) eru búnar til með umbeðnum leyfum. Þegar þessi tilgreining er ekki til staðar notar Git leyfi sem koma frá umask(2) (leyfasetningar skjala).
Valmöguleikinn getur haft eftirfarandi gildi, frumstilltur á group (hópur) ef engin gildi eru gefin:
-Nota leyfi frá umask(2) (leyfasetningar skjala). Þetta er frumstillingin þegar --shared (deildur) er ekki uppgefinn.
Make the repository group-writable, (and g+sx, since the git group may not be the primary group of all users). This is used to loosen the permissions of an otherwise safe umask(2) value. Note that the umask still applies to the other permission bits (e.g. if umask is 0022, using group will not remove read privileges from other (non-group) users). See 0xxx for how to exactly specify the repository permissions.
-Sama og group, en gerir hirsluna lesanlega fyrir alla notendur.
-<perm> is a 3-digit octal number prefixed with 0 and each file will have mode <perm>. <perm> will override users' umask(2) value (and not only loosen permissions as group and all do). 0640 will create a repository which is group-readable, but not group-writable or accessible to others. 0660 will create a repo that is readable and writable to the current user and group, but inaccessible to others (directories and executable files get their x bit from the r bit for corresponding classes of users).
Í deildum hirslum er stillingarvalmöguleikinn receive.denyNonFastForwards(viðtaka neita ekki framspóla) forstilltur sem gildur svo að þú getur ekki ýtt gögnum sem ekki framspóla inn í hana með þvingunum.
Ef þú gefur upp skrá, verður skipunin framkvæmd í henni. Ef skráin er ekki til verður hún búin til.
-Skjöl og skrár í sniðmótaskránni sem hafa ekki nafn sem byrjar á punkti verða afrituð yfir í $GIT_DIR(git skrá) eftir að hún er búin til.
Sniðmótaskráin verður eitt af eftirtöldu (í röð):
-breytan sem gefin er með --template (sniðmót) valmöguleikanum;
innihald $GIT_TEMPLATE_DIR(git sniðmót skrá) umhverfisbreytunnar;
stillingabreytan init.templateDir (frumstilla sniðmót skrá); eða
forstillta sniðmótaskráin: /usr/share/git-core/templates (notandi deila git-kjarni sniðmót).
Forstillta sniðmótaskráin hefur einhverjar undirskrár, tillögur um "exclude patterns" (hunsunarmynstur) (see gitignore[5] (hlekk-git git-hunsa), og dæmi um krækjuskjöl.
-Krækjudæmin eru öll forstillt sem óvirk. TIl þess að virkja eitt af krækjudæmunum þarf að endurnefna það með því að fjarlægja .sample (dæmi) viðskeytið.
Sjá githooks[5] (hlekk-git git-krækjur) fyrir frekari upplýsingar um það hvernig á að hrinda krækjum í framkvæmd.
-$ cd /slóð/til/míns/forskriftargrunns -$ git init (1) -$ git add . (2) -$ git commit (3)-
Býr til skrána /slóð/til/míns/forskriftargrunns/.git.
-Bæta öllum skrám sem eru til í atriðaskrána.
-Bóka ósnerta stöðu sem fyrsta innlegg í sögunni.
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Hluti af git[1] fylkingunni
-git init [-q | --quiet] [--bare] [--template=<テンプレートディレクトリ>] - [--separate-git-dir <gitディレクトリ>] [--object-format=<フォーマット>] - [--ref-format=<フォーマット>] - [-b <ブランチ名> | --initial-branch=<ブランチ名>] - [--shared[=<パーミッション>]] [<ディレクトリ>]-
このコマンドは、空の Git リポジトリを作成します。基本的には、.git ディレクトリに objects や refs/heads、 refs/tags、 テンプレートファイルなどのサブディレクトリを置くことになります。何もコミットされていない最初のブランチが作成されます (この名前は後述の --initial-branch オプションを参照)。
環境変数 $GIT_DIR が設定されている場合は、リポジトリのベースとして ./.git の代わりに使用するパスを指定します。
オブジェクトストレージのディレクトリが環境変数 $GIT_OBJECT_DIRECTORY で指定されている場合は、その下に sha1 ディレクトリが作成され、そうでない場合はデフォルトの $GIT_DIR/objects ディレクトリが使用されます。
既存のリポジトリで’git init’を実行しても安全です。すでにあるものを上書きすることはありません。再度 git init を実行する主な理由は、新しく追加されたテンプレートを取り込むためです (あるいは、--separate—git—dir が指定されている場合はリポジトリを別の場所に移動させるためです)。
-歴史的には、SHA-256リポジトリは、そのような相互運用性の機能を導入する際に、後方互換性のない変更が必要になるかもしれないと警告していました。しかし現在、互換性のある変更のみであると予期しています。さらに、そのような変更が必要であることが証明された場合、今日のGitで作成されたSHA-256リポジトリは、将来のGitバージョンでもデータ損失なしに使用可能であると予想されます。
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
テンプレートを使用するディレクトリを指定します。(後述の「TEMPLATE DIRECTORY」のセクションを参照)
-リポジトリを $GIT_DIR や ./.git/ のようなディレクトリとして初期化するのではなく、実際のリポジトリへのパスを含むテキストファイルをそこに作成します。このファイルは、ファイルシステムにとらわれない Git のリポジトリへのシンボリックリンクとして機能します。
再初期化の場合は、リポジトリは指定したパスに移動します。
-新しく作成されたリポジトリの最初のブランチに、指定された名前を使用します。指定されていない場合は、デフォルトの名前に戻ります (現在は master ですが、将来的には変更される可能性があります。名前は init.defaultBranch 設定変数でカスタマイズできます)。
Gitリポジトリを複数のユーザーで共有することを指定します。これにより、同じグループに属するユーザーがそのリポジトリにプッシュできるようになります。指定すると、コンフィグ変数 "core.sharedRepository" が設定され、$GIT_DIR 以下のファイルやディレクトリが要求されたパーミッションで作成されるようになります。指定されていない場合、Gitはumask(2)によって報告されたパーミッションを使用します。
このオプションには以下の値を指定できますが、値が指定されていない場合はデフォルトで「group」が設定されます。
-umask(2)で報告されたパーミッションを使用します。 --shared が指定されていない場合の初期設定です。
リポジトリをグループ書き込み可能にします (git グループがすべてのユーザーのプライマリグループではない場合があるので、g+sx も)。これは、安全なumask(2)の値のパーミッションを緩めるために使われます。ただし、umask は他のパーミッションビットにも適用されることに注意しましょう (たとえば umask が 0022 の場合、group を使っても他の (グループではない) ユーザーから読み取り権限を奪うことはできません)。リポジトリのパーミッションを正確に指定する方法については、'0xxx’を参照してください。
-'group’と同じですが、すべてのユーザーがリポジトリを読み取り可能にします。
-<パーミッション> は 0 の接頭辞が付いた3桁の8進数で、各ファイルは <パーミッション> のモードを持ちます。 <パーミッション> は、ユーザーのumask(2)の値を上書きします（group や all のようにパーミッションが緩くなるだけではありません）。0640 は、グループでの読み取りは可能ですが、グループでの書き込みや他の人からのアクセスはできないリポジトリを作成します。0660 は、現在のユーザーとグループは読み書き可能だが、他のユーザーにはアクセスできないリポジトリを作成します（ディレクトリと実行可能ファイルは対応するユーザークラスの r ビットから x ビットを取得します）。
デフォルトでは、共有リポジトリでは設定フラグの receive.denyNonFastForwards が有効になっており、高速転送ではないプッシュを強制できません。
ディレクトリ を指定した場合は、その中でコマンドが実行されます。このディレクトリが存在しない場合は、作成されます。
-テンプレートディレクトリ内のファイルやディレクトリのうち、名前がドットで始まらないものは、$GIT_DIR の作成後にコピーされます。
テンプレートディレクトリは、以下のいずれかになります（順番に）。
---template オプションで指定された引数。
$GIT_TEMPLATE_DIR 環境変数の内容。
init.templateDir 構成変数。
デフォルトのテンプレートディレクトリ: /usr/share/git-core/templates。
デフォルトのテンプレートディレクトリには、いくつかのディレクトリ構造、推奨される「除外パターン」（gitignore[5]を参照）、およびサンプルのフックファイルが含まれています。
-サンプルフックは、デフォルトではすべて無効になっています。サンプルフックを有効にするには、フックの名前を変更し、接尾辞 .sample を削除してください。
フックの実行についての一般的な情報は githooks[5] を参照してください。
-このセクションのこの行以下は、 git-config[1] のドキュメントから抜粋して含まれています。内容は同ドキュメントにあるものと同じです:
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Part of the git[1] suite
-git init [-q | --quiet] [--bare] [--template=<diretório-modelo>] - [--separate-git-dir <dir-git>] [--object-format=<formato>] - [--ref-format=<formato>] - [-b <nome-do-ramo> | --initial-branch=<nome-do-ramo>] - [--shared[=<permissões>]] [<diretório>]-
Este comando cria um repositório Git vazio, basicamente um diretório .git com subdiretórios para os arquivos objects, refs/heads, refs/tags e arquivos modelo. Também é criado um ramo inicial sem qualquer commit (consulte o nome da opção --initial-branch abaixo).
Caso a variável de ambiente $GIT_DIR esteja configurada, esta especificará um caminho a ser utilizado para a base dos repositórios em vez de ./.git.
Caso o diretório de armazenamento de objetos seja especificado através da variável de ambiente $GIT_OBJECT_DIRECTORY, então os diretórios "sha1" serão criados abaixo; caso contrário, será utilizado o diretório predefinido $GIT_DIR/objects.
É seguro executar o comando git init num repositório existente. O comando não substituirá as coisas que já estiverem lá. O principal motivo para executar novamente o comando git init é pegar os modelos adicionados recentemente (ou mover o repositório para um outro local caso --separate-git-dir seja utilizado).
Exiba apenas mensagens de erro e aviso; suprima todas as outras mensagens.
-Crie um repositório simples. Caso a variável de ambiente GIT_DIR não esteja definido, defina diretório de trabalho atual.
Defina o formato do objeto informado (algoritmo hash) para o repositório. Os valores válidos são sha1 e (se ativado) sha256. O valor predefinido é sha1.
-Observação: No momento, não há interoperabilidade entre os repositórios SHA-256 e os repositórios SHA-1.
-Alertamos no passado que os repositórios SHA-256 podem exigir alterações incompatíveis com versões anteriores quando implementamos estes recursos de interoperabilidade. Hoje, esperamos apenas alterações compatíveis. Além disso, se essas alterações forem necessárias, pode-se esperar que os repositórios SHA-256 criados com o Git atual possam ser usados por versões futuras do Git sem perda de dados.
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Especifique o diretório de onde os modelos serão utilizados. (Consulte a seção "DIRETÓRIO MODELO" abaixo.)
-Em vez de inicializar o repositório como um diretório para $GIT_DIR or ./.git/, crie um arquivo de texto contendo o caminho para o repositório real. Este arquivo atua como um link simbólico independente para o repositório do sistema de arquivos Git.
Caso seja uma reinicialização, o repositório será movido para um caminho determinado.
-Use o nome definido para o ramo inicial no repositório que foi recém-criado. Caso não seja especificado, retorne ao nome predefinido (atualmente master porém isso está para mudar no futuro; o nome pode ser personalizado através da variável de configuração init.defaultBranch.
Determina que o repositório Git deve ser compartilhado entre vários usuários. Isso permite que os usuários pertencentes ao mesmo grupo enviem para esse repositório. Quando definido, a variável de configuração core.sharedRepository é utilizada para que os arquivos e os diretórios definidos pela variável $GIT_DIR sejam criados com as permissões solicitadas. Quando não definido, o Git usará as permissões informadas pelo umask(2).
A opção pode ter os seguintes valores, predefinido como group caso nenhum valor seja informado:
-Utilize as permissões informadas por umask(2). É a predefinição quando --shared não é utilizado.
Torne o grupo do repositório com permissão de escrita (g+sx por exemplo, pois o grupo git pode não ser o grupo principal de todos os usuários). Isso é utilizado para afrouxar as permissões de um valor, a não ser que indique o contrário, umask(2) seguro. Observe que o umask ainda se aplica aos outros bits de permissão (por exemplo, caso o umask seja 0022 o uso de group não removerá os privilégios de leitura dos outros usuários (sem um grupo). Consulte 0xxx para saber como usar exatamente as permissões do repositório.
-O mesmo que group, mas torna o repositório legível por todos os usuários.
-<perm> é um número octal com 3 dígitos prefixado com 0 e cada arquivo terá o modo <perm>. <perm> substituirá o valor umask(2) dos usuários (e não apenas diminuirá as permissões como group e all). 0640 criará um repositório de apenas leitura por grupo, sem permissão escrita ou acessível a outros. 0660 criará um repositório com permissão de leitura e escrita ao usuário e ao grupo atual, porém, inacessível aos outros (os diretórios e os arquivos executáveis recebem seu bit x do bit r para as classes correspondentes dos usuários).
É predefinido que a flag da configuração receive.denyNonFastForwards seja ativado nos repositórios compartilhados para que você não possa impor um impulsionamento fast-forwarding para ele.
Caso utilize um diretório, o comando será executado dentro dele. E caso o diretório não exista, um será criado.
Os arquivos e diretórios no diretório modelo cujo nome não começa com um ponto serão copiados para o $GIT_DIR após a sua criação.
O diretório modelo será um dos seguintes (em ordem):
-o argumento utilizado com a opção --template;
o conteúdo da variável de ambiente $GIT_TEMPLATE_DIR;
a variável de configuração init.templateDir; ou
A predefinição do diretório modelo: /usr/share/git-core/templates.
A predefinição do diretório modelo inclui alguma estrutura de diretórios, "padrões de exclusão" sugeridos (consulte gitignore[5]) e os arquivos gancho de amostragem.
-Por predefinição os ganchos de amostragem estão todos desativados. Para ativar um dos ganchos de amostragem, renomeie-o removendo o sufixo .sample.
Para um apanhado geral sobre execução hook consulte githooks[5].
-$ cd /path/to/my/codebase -$ git init (1) -$ git add . (2) -$ git commit (3)-
Cria um diretório /path/to/my/codebase/.git.
-Adicione todos os arquivos existentes ao índice.
-Registre o estado intocado como o primeiro commit no histórico.
-Tudo abaixo desta linha nesta seção, está seletivamente incluído na documentação git-config[1]. O conteúdo é o mesmo que é encontrado ali:
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Parte do conjunto git[1]
-git init [-q | --quiet] [--bare] [--template=<template-directory>] - [--separate-git-dir <git-dir>] [--object-format=<format>] - [-b <branch-name> | --initial-branch=<branch-name>] - [--shared[=<permissions>]] [<directory>]-
Această comandă creează un depozit Git gol - practic un director .git cu subdirectoare pentru objects, refs/heads, refs/tags și fișiere șablon. Va fi creată o branșă inițială fără nici un angajament (a se vedea opțiunea --initial-branch de mai jos pentru numele acesteia).
Dacă variabila de mediu $GIT_DIR este setată, atunci aceasta specifică o cale care să fie utilizată în locul lui ./.git pentru baza depozitului.
If the object storage directory is specified via the $GIT_OBJECT_DIRECTORY environment variable then the sha1 directories are created underneath; otherwise, the default $GIT_DIR/objects directory is used.
Rularea git init într-un depozit existent este sigură. Nu va suprascrie lucruri care există deja. Motivul principal pentru care se reia "git init" este pentru a prelua șabloanele nou adăugate (sau pentru a muta depozitul în alt loc dacă se indică --separate-git-dir).
-Imprimă numai mesajele de eroare și de avertizare; toate celelalte mesaje de ieșire vor fi suprimate.
-Creați un depozit gol. Dacă mediul GIT_DIR nu este setat, acesta este setat la directorul de lucru curent.
Specifică formatul obiectului dat (algoritmul hash) pentru depozit. Valorile valide sunt "sha1" și (dacă este activat) "sha256". sha1 este valoarea implicită.
-ACEASTĂ OPȚIUNE ESTE EXPERIMENTALĂ! Suportul pentru SHA-256 este experimental și se află încă într-un stadiu incipient. Un depozit SHA-256 nu va putea, în general, să partajeze munca cu depozitele SHA-1 "obișnuite". Trebuie să se presupună că, de exemplu, formatele de fișiere interne Git în legătură cu depozitele SHA-256 se pot schimba în moduri incompatibile cu trecutul. Utilizați --object-format=sha256 numai în scopuri de testare.
Specificați directorul din care vor fi utilizate șabloanele. (A se vedea secțiunea "REPERTORIUL DE MODELE" de mai jos)
-Instead of initializing the repository as a directory to either $GIT_DIR or ./.git/, create a text file there containing the path to the actual repository. This file acts as a filesystem-agnostic Git symbolic link to the repository.
If this is a reinitialization, the repository will be moved to the specified path.
-Utilizați numele specificat pentru branșa inițială din depozitul nou creat. Dacă nu este specificat, se revine la numele implicit (în prezent master, dar acesta poate fi modificat în viitor; numele poate fi personalizat prin intermediul variabilei de configurare init.defaultBranch).
Specificați că depozitul Git trebuie partajat între mai mulți utilizatori. Acest lucru permite utilizatorilor care aparțin aceluiași grup să facă push în acest depozit. Atunci când este specificată, variabila de configurare "core.sharedRepository" este setată astfel încât fișierele și directoarele din $GIT_DIR să fie create cu permisiunile solicitate. Atunci când nu este specificată, Git va utiliza permisiunile raportate de umask(2).
Opțiunea poate avea următoarele valori, valoarea implicită fiind "group" în cazul în care nu se dă nicio valoare:
-Utilizați permisiunile raportate de umask(2). Valoarea implicită, atunci când nu este specificat --shared.
Make the repository group-writable, (and g+sx, since the git group may not be the primary group of all users). This is used to loosen the permissions of an otherwise safe umask(2) value. Note that the umask still applies to the other permission bits (e.g. if umask is 0022, using group will not remove read privileges from other (non-group) users). See 0xxx for how to exactly specify the repository permissions.
-La fel ca "group", dar face ca depozitul să poată fi citit de toți utilizatorii.
-<perm> is a 3-digit octal number prefixed with 0 and each file will have mode <perm>. <perm> will override users' umask(2) value (and not only loosen permissions as group and all do). 0640 will create a repository which is group-readable, but not group-writable or accessible to others. 0660 will create a repo that is readable and writable to the current user and group, but inaccessible to others (directories and executable files get their x bit from the r bit for corresponding classes of users).
În mod implicit, marcajul de configurație receive.denyNonFastForwards este activat în depozitele partajate, astfel încât să nu puteți forța un push care nu este de tip fast-forwarding în acestea.
Dacă furnizați un "director", comanda este executată în interiorul acestuia. Dacă acest director nu există, va fi creat.
-Fișierele și directoarele din directorul șablon al căror nume nu începe cu un punct vor fi copiate în $GIT_DIR după ce acesta este creat.
Directorul șablonului va fi unul dintre următoarele (în ordine):
-argumentul dat cu opțiunea --template;
conținutul variabilei de mediu $GIT_TEMPLATE_DIR;
variabila de configurare init.templateDir; sau
directorul de șabloane implicit: /usr/share/git-core/templates.
Directorul șablon implicit include o anumită structură de directoare, "modele de excludere" sugerate (a se vedea gitignore[5]) și exemple de fișiere hook.
-Probele de tip hook sunt toate dezactivate în mod implicit. Pentru a activa unul dintre cârligele de probă, redenumiți-l prin eliminarea sufixului .sample.
Consultați githooks[5] pentru mai multe informații generale despre executarea Consultați githooks[5] pentru mai multe informații generale despre executarea hook-urilor..
-$ cd /path/to/my/codebase -$ git init (1) -$ git add . (2) -$ git commit (3)-
Creați un director /path/to/my/codebase/.git.
-Adăugați toate fișierele existente la index.
-Înregistrează starea inițială ca prima confirmare în cursul depozitului.
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Parte a suitei git[1]
-git init [-q | --quiet] [--bare] [--template=<模板目錄>] - [--separate-git-dir <git 目錄>] [--object-format=<格式>] - [-b <分支名稱> | --initial-branch=<分支名稱>] - [--shared[=<權限>]] [目錄]-
這行指令會創建一個空的Git倉儲，基本上是一個名為`.git`的目錄，含有`objects`,refs/heads,`refs/tags`這幾個子目錄，其他模板檔案，跟一個指向`master`分支Head的初始`HEAD`檔案。
如果有設定環境變數`$GIT_DIR`，則會使用被指定的路徑，而不是`./.git`來建立倉儲的基礎檔案。
-如果object儲存路徑有經由環境變數`$GIT_OBJECT_DIRECTORY`所指定，則SHA-1的目錄將會被設置在其底下，否則會使用預設的`$GIT_DIR/objects`目錄。
-在現有的倉儲執行’git init’是很安全的。它並不會覆蓋掉已存在的檔案。重新執行’git init’最主要的原因，是去取得新增的模板檔案(或是加上 --separate-git-dir 將倉儲移到另一個位置)。
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
指定用於取得模板檔案的目錄(請參考下面的"模板檔案目錄"章節。)
-不使用`$GIT_DIR`或是`./.git/`作為初始化倉儲的路徑，而是創建一個儲存實際倉儲路徑的檔案。這個檔案會作為資料系統獨立的Git捷徑，連結到倉儲。
-如果重新初始化，倉儲則會被移到指定的路徑。
-為新創的倉儲指定初始分支的名稱。若沒有指定，就會退而使用預設名稱’master'。
-指定的Git倉儲可在多個使用者之間共享，這會允許屬於相同群組的使用者對這個倉儲推送。指定時，組態參數"core.sharedRepository"將會被設定，讓在`$GIT_DIR`底下的檔案和目錄使用指定的權限來創建。當沒有指定時，Git會使用umask(2)所回報的權限。
-這個選項可以加上下列數值，若不給值，則預設會使用’group'：
-使用umask(2)回報的權限。也是當沒有指定`--shared`時的預設值。
-讓倉儲變成群組可寫入(還有g+sx，因為git群組可能並非所有使用者的主群組)。這用於放寬原本較為安全的umask(2)權限。請注意，umask仍然會適用於其他權限(舉例來說， 當umask是'0022’時,使用’group’並不會移除其他使用者(non-group)的讀取權限。請參閱'0xxx’來知道如何精確指定倉庫的權限。
-跟’group’大致相同，但會使倉庫可被所有使用者讀取。
-0xxx 是個八進位數字，而各個檔案都會擁有權限'0xxx'。'0xxx’會覆蓋掉使用者的umask(2)值(而且並不像group跟all一樣會放寬權限)。'0640’會創建群組可讀，但群組不可寫，其他人也不可存取的倉儲。'0660’會創建當前使用者與群組可讀可寫，但是其他人無法存取的倉儲。
-在預設中，共享倉庫的設定旗標 receive.denyNonFastForwards是被啟用的，所以你無法強制使用非快進進行推送。
-如果你在指令中提供了’目錄'，而此目錄不存在的話，它則會被創建。
-並非以點作為名稱開頭的檔案和目錄將會在`$GIT_DIR`被創建後，被複製到其中。
-模板目錄將為下列其一（依照順序）：
-在選項`--template`中被給予的引數;
-環境變數`$GIT_TEMPLATE_DIR`中的內容;
-設定變數`init.templateDir`; 或是
-預設模板目錄：/usr/share/git-core/templates。
The default template directory includes some directory structure, suggested "exclude patterns" (see gitignore[5]), and sample hook files.
-The sample hooks are all disabled by default. To enable one of the sample hooks rename it by removing its .sample suffix.
See githooks[5] for more general info on hook execution.
-$ cd /path/to/my/codebase -$ git init (1) -$ git add . (2) -$ git commit (3)-
Create a /path/to/my/codebase/.git directory.
-Add all existing files to the index.
-Record the pristine state as the first commit in the history.
-Part of the git[1] suite
-git-mv - Eine Datei, ein Verzeichnis oder einen Symlink verschieben oder umbenennen
-Eine Datei, ein Verzeichnis oder einen Symlink verschieben oder umbenennen
-git mv [-v] [-f] [-n] [-k] <Quelle> <Ziel> -git mv [-v] [-f] [-n] [-k] <Quelle> ... <Zielverzeichnis>-
In der ersten Form wird <Quelle> umbenannt, welches bereits vorhanden sein muss und entwedet eine Datei, ein Symlink oder ein Verzeichnis sein muss zu <Ziel>. In der zweiten Form muss das letzte Argument ein vorhandenes Verzeichnis sein; die gegebenen Quellen werden in dieses Verzeichnis verschoben.
-Die Bereitstellung wird nach erfolgreichem Beenden aktualisiert, die Änderung muss aber dennoch eingetragen werden.
-Erzwinge Umbenennen oder Verschieben einer Datei, selbst wenn das Ziel bereits existiert
-Überspringe Verschiebe- oder Umbenennungsaktionen, die zu einem Fehler führen würden. Ein Fehler geschieht, wenn die Quelle weder vorhanden ist, noch von Git kontrolliert wird oder wenn eine bereits vorhandene Datei überschrieben werden würde, außer wenn die Option -f gegeben wurde.
-Führe nichts wirklich aus, zeige nur an, was geschehen würde
-Report the names of files as they are moved.
-Moving a submodule using a gitfile (which means they were cloned with a Git version 1.7.8 or newer) will update the gitfile and core.worktree setting to make the submodule work in the new location. It also will attempt to update the submodule.<name>.path setting in the gitmodules[5] file and stage that file (unless -n is used).
-Each time a superproject update moves a populated submodule (e.g. when switching between commits before and after the move) a stale submodule checkout will remain in the old location and an empty directory will appear in the new location. To populate the submodule again in the new location the user will have to run "git submodule update" afterwards. Removing the old directory is only safe when it uses a gitfile, as otherwise the history of the submodule will be deleted too. Both steps will be obsolete when recursive submodule update has been implemented.
-Teil der git[1] Suite
-git notes [list [<object>]] -git notes add [-f] [--allow-empty] [--[no-]separator | --separator=<paragraph-break>] [--[no-]stripspace] [-F <file> | -m <msg> | (-c | -C) <object>] [-e] [<object>] -git notes copy [-f] ( --stdin | <from-object> [<to-object>] ) -git notes append [--allow-empty] [--[no-]separator | --separator=<paragraph-break>] [--[no-]stripspace] [-F <file> | -m <msg> | (-c | -C) <object>] [-e] [<object>] -git notes edit [--allow-empty] [<object>] [--[no-]stripspace] -git notes show [<object>] -git notes merge [-v | -q] [-s <strategy> ] <notes-ref> -git notes merge --commit [-v | -q] -git notes merge --abort [-v | -q] -git notes remove [--ignore-missing] [--stdin] [<object>…] -git notes prune [-n] [-v] -git notes get-ref-
Adiciona, remove ou lê as anotações anexadas aos objetos, sem tocar nos próprios objetos.
-É predefinido que as anotações sejam salvas e lidas do refs/notes/commits, mas esta predefinição pode ser substituída. Consulte as seções OPÇÕES, CONFIGURAÇÃO e AMBIENTE abaixo. Caso esta referência não exista, ela será criada de forma silenciosa quando for necessário armazenar uma nota pela primeira vez.
Uma utilização típica das anotações é complementar uma mensagem de um commit sem alterar o próprio commit. As anotações podem ser exibidas com o comando git log junto com a mensagem do commit original. Para distinguir entre estas anotações da mensagem armazenada no commit do objeto, as anotações são recuadas como a mensagem, após uma linha não recolocada dizendo "Notes (<refname>):" (ou "Notes:" para refs/notes/commits) .
As anotações também podem ser adicionadas aos patches preparados com o comando git format-patch utilizando a opção --notes. Tais anotações são adicionadas como um comentário de um patch após uma linha separadora com três traços.
Para alterar quais as anotações são exibidas através do comando git log, consulte a configuração "notes.displayRef" em CONFIGURAÇÃO.
-Consulte a configuração "notes.rewrite.<comando>" para conhecer uma maneira de transportar as anotações através dos comandos que reescrevem os commits.
-Liste as anotações do objeto para um determinado objeto. Caso nenhum objeto seja informado, exiba uma lista com todas as anotações dos objetos e os objetos que eles anotam (no formato "<nota do objeto> <objeto anotado>"). Este é o subcomando predefinido caso nenhum subcomando seja utilizado.
-Add notes for a given object (defaults to HEAD). Abort if the object already has notes (use -f to overwrite existing notes). However, if you’re using add interactively (using an editor to supply the notes contents), then - instead of aborting - the existing notes will be opened in the editor (like the edit subcommand). If you specify multiple -m and -F, a blank line will be inserted between the messages. Use the --separator option to insert other delimiters. You can use -e to edit and fine-tune the message(s) supplied from -m and -F options interactively (using an editor) before adding the note.
Copie as anotações para o primeiro objeto no segundo (a predefinição retorna para HEAD). Interrompa caso o segundo objeto já tenha as anotações ou caso o primeiro objeto não tiver nenhuma (utilize -f para substituir as anotações existentes no segundo objeto). Este subcomando se equivale a: git notes add [-f] -C $(git notes list <do-objeto>) <para-o-objeto>
No modo --stdin, pegue as linhas no formato
<do-objeto> SP <para-o-objeto> [ SP <rest> ] LF-
na entrada padrão e copie as anotações de cada <do-objeto> para o seu <para-o-objeto> correspondente. (O <rest> opcional é ignorado para que o comando possa ler a entrada informada ao gancho post-rewrite.)
Append new message(s) given by -m or -F options to an existing note, or add them as a new note if one does not exist, for the object (defaults to HEAD). When appending to an existing note, a blank line is added before each new message as an inter-paragraph separator. The separator can be customized with the --separator option. Edit the notes to be appended given by -m and -F options with -e interactively (using an editor) before appending the note.
Edite as anotações para um determinado objeto (a predefinição retorna para HEAD).
Mostrar as anotações para um determinado objeto (a predefinição retorna para HEAD).
Mescle as anotações "ref" informadas nas anotações "ref" atuais. Será feita uma tentativa para mesclar as alterações feitas através das anotações "ref" informada (chamadas "remotas") desde a base de mesclagem (caso haja) nas anotações "ref" atuais (chamadas "locais").
-Caso surjam conflitos e uma estratégia para resolver automaticamente as notas conflitantes (consulte a seção "OBSERVAÇÕES SOBRE AS ESTRATÉGIAS DE MESCLAGEM") não sejam utilizadas, o resolvedor "manual" será utilizado. Este resolvedor verifica se as notas conflitantes numa árvore de trabalho especial (.git/NOTES_MERGE_WORKTREE) instrui o usuário a resolver manualmente os conflitos lá. Quando for concluído, o usuário pode finalizar a mesclagem com o comando git notes merge --commit ou interromper a mesclagem com o comando git notes merge --abort.
Remova as anotações para determinados objetos (a predefinição retorna para HEAD). Ao atribuir zero ou um objeto a partir da linha de comando, isso equivale a informar uma mensagem com anotação vazia para o subcomando edit.
Remova todas as anotações dos objetos inexistentes/inacessíveis.
-Exiba as anotações "ref" atuais. Fornece uma maneira fácil de recuperar as anotações "ref" atuais (dos scripts por exemplo).
-Ao adicionar as anotações num objeto que já possa anotações, substitua as anotações existentes (em vez de abortar).
-Use a mensagem fornecida da anotação (em vez de solicitar). Se forem fornecidas várias opções -m, os seus valores serão concatenados como parágrafos separados. Serão removidas as linhas que começam com # e as linhas vazias que não sejam uma única linha entre parágrafos; se você quiser mantê-las textualmente, use a opção --no-stripspace.
Obtém a mensagem de anotação a partir de um determinado arquivo. Use - para ler a mensagem da anotação na entrada padrão. As linhas que começam com # e as linhas vazias que não sejam uma única linha entre os parágrafos serão removidas; se você quiser mantê-las textualmente, use a opção --no-stripspace.
Tome o objeto bolha fornecido (por exemplo, outra anotação) como a mensagem da anotação. (Em vez disso, use git notes copy <objeto> para copiar anotações entre os objetos). Por padrão, a mensagem será copiada literalmente, mas caso queira remover as linhas que começam com # e as linhas vazias que não sejam uma única linha entre parágrafos, use a opção --stripspace.
Assim como -C, porém com -c o editor é invocado para que o usuário possa editar mais a mensagem da nota.
Permita que uma anotação vazia do objeto seja armazenado. O comportamento predefinido é remover automaticamente as anotações que estiverem vazias.
-Especifique uma string usada como separador personalizado entre os parágrafos (uma nova linha é adicionada ao final, conforme seja necessário). caso a opção --no-separator seja usada, nenhum separador entre os parágrafos será adicionado. A predefinição é uma linha em branco.
Retire os espaços em branco iniciais e finais da mensagem de anotação. Remova também as linhas vazias que não sejam uma única linha entre os parágrafos. As linhas que começam com # serão removidas em casos não relacionados ao editor, como -m, -F e -C, mas não em casos relacionados ao editor, como git notes edit, -c, etc.
Manipule as anotações da árvore na <ref>. Sobrescreve o GIT_NOTES_REF e a configuração "core.notesRef". A "ref" determina o nome completo quando começa com refs/notes/; quando começa com notes/, refs/ e caso contrário refs/notes/ é prefixado para formar um nome completo da "ref".
Não considere um erro ao solicitar a remoção das anotações de um objeto que não possua anotações anexadas.
-Leia também os nomes dos objetos para remover anotações da entrada padrão (não há motivo para não combinar isso com os nomes dos objetos na linha de comando).
-Não remova nada; apenas relate os nomes dos objetos cujas anotações seriam removidas.
-Ao mesclar as anotações, resolva os conflitos das anotações utilizando uma determinada estratégia. As seguintes estratégias são reconhecidas: "manual" (predefinido), "ours" (nosso), "theirs" (deles), "union" (união) e "cat_sort_uniq". Esta opção substitui a configuração "notes.mergeStrategy". Consulte a seção "OBSERVAÇÕES SOBRE AS ESTRATÉGIAS DE MESCLAGEM" abaixo para obter mais informações sobre a estratégia de mesclagem de cada nota.
-Finalize um git notes merge em andamento. Utilize esta opção quando tiver resolvido os conflitos que o comando git notes merge armazenou em .git/NOTES_MERGE_WORKTREE. Isso altera o commit parcial da mesclagem criado pelo comando git notes merge (armazenado em .git/NOTES_MERGE_PARTIAL) adicionando as anotações em .git/NOTES_MERGE_WORKTREE. As notas "ref" armazenadas no symref .git/NOTES_MERGE_REF são atualizadas no commit resultante.
Interrompa/redefina um comando git notes merge em andamento, ou seja, mesmo com conflitos, uma anotação será mesclada. Simplesmente remove todos os arquivos relacionados as anotações da mesclagem.
-Quando mesclar as anotações, opere em silêncio.
-Quando mesclar as anotações, seja loquaz. Quando remover as anotações, relate todos os nomes dos objetos cujas notas foram removidas.
-As anotações dos commits são bolhas que contêm informações extras sobre um objeto (geralmente informações para complementar a mensagem de um commit). Estas bolhas são retiradas das anotações refs. Uma anotação "ref" geralmente é um ramo que contém "arquivos" cujos caminhos são os nomes dos objetos que o descrevem, com alguns separadores do diretório incluídos por motivos de desempenho, nota de rodapé: [Os nomes dos caminhos permitidos têm o formato 'bf'/'fe'/'30'/'...'/'680d5a...': uma sequência com os nomes dos diretórios com dois dígitos hexadecimais cada um, seguido por um nome do arquivo com o resto do ID do objeto.].
Cada modificação nas anotações cria um novo commit nas anotações "ref" usadas. Portanto, você pode inspecionar o histórico das notas invocando por exemplo o comando git log -p notes/commits. Atualmente, a mensagem do commit registra apenas qual a operação acionou a atualização, já a autoria da confirmação é determinada de acordo com as regras usuais (consulte git-commit[1]). Estes detalhes podem mudar no futuro.
Também é permitido que uma anotação da "ref" aponte diretamente para um objeto na árvore, caso onde o histórico das anotações podem ser lidos com git log -p -g <refname>.
The default notes merge strategy is "manual", which checks out conflicting notes in a special work tree for resolving notes conflicts (.git/NOTES_MERGE_WORKTREE), and instructs the user to resolve the conflicts in that work tree. Quando for concluído, o usuário pode finalizar a mesclagem com o comando git notes merge --commit ou interromper a mesclagem com o comando git notes merge --abort.
Os usuários podem selecionar uma estratégia de mesclagem automatizada dentre as opções a seguir, utilizando a opção -s/--strategy ou configurando a opção notes.mergeStrategy de acordo:
O "ours" (nosso) resolve automaticamente as anotações conflitantes em favor da versão local (ou seja, as anotações "ref" atuais).
-O "deles" resolve automaticamente os conflitos das anotações em favor da versão remota (ou seja, as anotações dadas ao "ref" são mescladas nas anotações atuais da "ref").
-O "union" resolve automaticamente os conflitos das anotações concatenando as versões locais e remotas.
-O "cat_sort_uniq" é semelhante ao "union", porém, além de concatenar as versões locais e remotas, essa estratégia também classifica as linhas resultantes e remove as linhas que estiverem no resultado. Isso é equivalente ao aplicação do pipeline shell "cat | sort | uniq" nas versões locais e remotos. Essa estratégia é útil caso as notas sigam um formato com base nas linhas, onde se deseja evitar as linhas duplicadas no resultado da mesclagem. Observe que, caso a versão local ou remota tiver linhas duplicadas antes da mesclagem, elas também serão removidas por esta anotação estratégica de mesclagem.
-Você pode utilizar notas para adicionar anotações com as informação do que não estava disponível no momento em que o commit foi feito.
-$ git notes add -m 'Testado-por: Johannes Sixt <j6t@kdbg.org>' 72a144e2 -$ git show -s 72a144e -[...] - Assinado-por: Junio C Hamano <gitster@pobox.com> - -Anotações: - Testado-por: Johannes Sixt <j6t@kdbg.org>-
Em princípio, uma anotação é uma bolha Git comum e qualquer outro tipo de formato (não) é aceito. Você pode criar com segurança as anotações binárias a partir de arquivos arbitrários utilizando o comando git hash-object:
-$ cc *.c -$ blob=$(git hash-object -w a.out) -$ git notes --ref=built add --allow-empty -C "$blob" HEAD-
(Você não pode simplesmente utilizar o comando git notes --ref=built add -F a.out HEAD porque isso não é seguro para os arquivos binários.) É claro que não faz muito sentido exibir as anotações que não foram formatadas com git log, portanto, caso utilize estas anotações, provavelmente precisará escrever algumas ferramentas com um propósito especial para fazer algo útil com elas.
Tudo acima desta linha nesta seção não está incluído na documentação git-config[1]. O conteúdo que segue é o mesmo que se encontra lá:
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
GIT_NOTES_REF De qual "ref" manipular as anotações, em vez do refs/notes/commits. Sobrescreve a configuração core.notesRef.
GIT_NOTES_DISPLAY_REF Uma lista delimitada por dois pontos das refs ou "globs" indicando quais as refs, além da predefinição do core.notesRef ou` GIT_NOTES_REF`, para ler as anotações ao exibir as mensagens dos commits. Sobrescreve a configuração notes.displayRef.
Um aviso será emitido para as refs que não existam, porém um agrupamento "glob" que não corresponda a nenhuma referência é ignorada em silêncio.
-GIT_NOTES_REWRITE_MODE Ao copiar as anotações durante uma reescrita, o que fazer caso o commit de destino já tiver uma anotação. Deve ser uma das opção overwrite,` concatenate`, cat_sort_uniq ou` ignore`. Sobrescreve a configuração core.rewriteMode.
GIT_NOTES_REWRITE_REF Ao reescrever os commits, as anotações que serão copiadas do original para o commit que será reescrito. Deve ser uma lista delimitada por dois pontos das refs ou globs.
-Caso não esteja definido no ambiente, a lista das anotações que serão copiadas irá depender das configurações notes.rewrite.<comando> e notes.rewriteRef.
Parte do conjunto git[1]
-git-parse-remote - Rotinas para ajudar na análise dos parâmetros de acesso ao repositório remoto
-Este script está incluso em vários scripts para fornecer rotinas para realizar a análise dos arquivos no $GIT_DIR/remotes/ e $GIT_DIR/branches/ e nas variáveis de configuração relacionadas à busca (fetch), captura (pull) e impulsionamento (pull).
Parte do conjunto git[1]
-git-parse-remote - Подпрограммы для помощи разбора параметров доступа внешнего репозитория
-Этот сценарий добавлен в коллекцию сценариев, дабы предоставить подпрограммы для разбора файлов, хранящихся в каталогах $GIT_DIR/remotes/ и $GIT_DIR/branches/, а также некоторых настроечных переменных, связанных с извлечением (fetch), получением (pull) и отправкой (push) изменений.
-Является частью пакета git[1]
-git restore [<Optionen>] [--source=<Tree>] [--staged] [--worktree] [--] <Pfadspezifikation>… -git restore [<Optionen>] [--source=<Tree>] [--staged] [--worktree] --pathspec-from-file=<Datei> [--pathspec-file-nul] -git restore (-p|--patch) [<Optionen>] [--source=<Tree>] [--staged] [--worktree] [--] [<Pfadspezifikation>…]-
Stellt spezifizierte Pfade im Arbeitsbereich mit Inhalt aus einer Wiederherstellungsquelle wieder her. Wenn ein Pfad überwacht wird, aber in der Wiederherstellungsquelle nicht vorhanden ist, wird er entfernt, damit er mit der Quelle übereinstimmt.
-Der Befehl kann auch verwendet werden, um den Inhalt im Index mit --staged wiederherzustellen oder um sowohl den Arbeitsbereich (working tree) als auch den Index mit --staged --worktree wiederherzustellen.
By default, if --staged is given, the contents are restored from HEAD, otherwise from the index. Use --source to restore from a different commit.
Siehe „Reset, restore und revert“ in git[1] für die unterschiedlichen Eigenschaften der drei Befehle.
-DIESER BEFEHL IST EXPERIMENTELL. MÖGLICHERWEISE KANN SICH DAS VERHALTEN ÄNDERN.
-Wiederherstellen der Dateien des Arbeitsbereichs mit dem Inhalt aus dem angegebenen Daten-Baum. Es ist üblich, den Quellbaum durch Angabe eines assoziierten Commit-, Branch- oder Tag-Namens zu bestimmen.
-If not specified, the contents are restored from HEAD if --staged is given, otherwise from the index.
As a special case, you may use "A...B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD.
Wählt interaktiv abweichende Abschnitte in der Wiederherstellungsquelle und dem Wiederherstellungsort aus. Siehe den Abschnitt "Interaktiver Modus" in git-add[1], um zu erfahren, wie der --patch-Modus anzuwenden ist.
Note that --patch can accept no pathspec and will prompt to restore all modified paths.
Bestimmt den Wiederherstellungsort. Wenn keine der beiden Optionen angegeben wurde, stellt das System standardmäßig den Arbeitsbereich wieder her. Mit der Angabe von --staged wird nur den Index wieder hergestellt. Die Angabe beider Optionen stellt beides wieder her.
Quiet, suppress feedback messages. Implies --no-progress.
Der Fortschritt wird standardmäßig auf der Standardfehlerausgabe angezeigt, wenn diese an ein Terminal angebunden ist, außer wenn --quiet angegeben ist. Dieses Flag erlaubt die Fortschrittsanzeige auch ohne Terminalanbindung, ohne --quiet zu berücksichtigen.
When restoring files in the working tree from the index, use stage #2 (ours) or #3 (theirs) for unmerged paths. This option cannot be used when checking out paths from a tree-ish (i.e. with the --source option).
Hinweis: Während eines git rebase und eines git pull --rebase können ours und theirs vertauscht erscheinen. Siehe die Beschreibung der gleichen Optionen in git-checkout[1] für weitere Details.
When restoring files on the working tree from the index, recreate the conflicted merge in the unmerged paths. This option cannot be used when checking out paths from a tree-ish (i.e. with the --source option).
The same as --merge option above, but changes the way the conflicting hunks are presented, overriding the merge.conflictStyle configuration variable. Possible values are "merge" (default), "diff3", and "zdiff3".
Wenn Dateien im Arbeitsbereich aus dem Index wiederhergestellt werden, sollte diese Operation nicht abgebrochen werden, wenn es nicht gemergte Einträge gibt und weder --ours, --theirs, --merge noch --conflict angegeben ist. Nicht verschmolzene Pfade auf dem Arbeitsbereich werden ignoriert.
In sparse checkout mode, the default is to only update entries matched by <pathspec> and sparse patterns in $GIT_DIR/info/sparse-checkout. This option ignores the sparse patterns and unconditionally restores any files in <pathspec>.
If <pathspec> names an active submodule and the restore location includes the working tree, the submodule will only be updated if this option is given, in which case its working tree will be restored to the commit recorded in the superproject, and any local modifications overwritten. If nothing (or --no-recurse-submodules) is used, submodules working trees will not be updated. Just like git-checkout[1], this will detach HEAD of the submodule.
Im Overlay-Modus werden mit diesem Befehl niemals Dateien beim Wiederherstellen entfernt. Im No-Overlay-Modus werden getrackte Dateien, die nicht im --source-Tree vorkommen, entfernt, damit sie genau mit <Tree> übereinstimmen. Die Standardeinstellung ist der No-Overlay-Modus.
Die Pfadangabe wird in <Datei> statt über Befehlszeilen-Argumente übergeben. Wenn <Datei> genau - ist, wird die Standardeingabe verwendet. Pfadspezifische Elemente werden durch LF oder CR/LF getrennt. Pathspec-Elemente können in Anführungszeichen gesetzt werden, wie für die Konfigurations-Variable core.quotePath beschrieben (siehe git-config[1]). Siehe auch --pathspec-file-nul und global --literal-pathspecs.
Nur sinnvoll mit --pathspec-from-file. Pfadspezifische Elemente werden mit dem Steuerzeichen-Code NULL getrennt und alle anderen Zeichen werden unverändert übernommen (einschließlich der Zeilenumbrüche und Anführungszeichen).
Diese Option kann dazu verwendet werden, Befehlszeilenoptionen von der Liste von Dateien zu trennen. Dies ist sinnvoll, wenn Dateinamen mit Befehlszeilenoptionen verwechselt werden könnten.
-Legt die von der Operation betroffenen Pfade fest.
-Mehr Details finden Sie im pathspec-Eintrag in gitglossary[7].
-Das folgende Listing wechselt in den Branch master, setzt das Makefile um zwei Revisionsstände zurück, dann wird hello.c irrtümlich gelöscht, um danach wieder aus dem Index zurückgeholt zu werden.
$ git switch master -$ git restore --source master~2 Makefile (1) -$ rm -f hello.c -$ git restore hello.c (2)-
Lade eine Datei aus einem anderen Commit
-Wiederherstellen von hello.c aus dem Index
-Falls alle C-Quelldateien wieder hergestellt werden sollen, damit sie mit der Version im Index übereinstimmen, kann man folgendes eingeben
-$ git restore '*.c'-
Note the quotes around *.c. The file hello.c will also be restored, even though it is no longer in the working tree, because the file globbing is used to match entries in the index (not in the working tree by the shell).
So kann man alle Dateien im aktuellen Verzeichnis wieder herstellen
-$ git restore .-
or to restore all working tree files with top pathspec magic (see gitglossary[7])
-$ git restore :/-
Eine Datei im Index so wiederherstellen, dass sie mit der Version in HEAD übereinstimmt (das entspricht dem Vorgehen wie mit git-reset[1])
$ git restore --staged hello.c-
or you can restore both the index and the working tree (this is the same as using git-checkout[1])
-$ git restore --source=HEAD --staged --worktree hello.c-
die Kurzform ist praktischer aber nicht so gut lesbar:
-$ git restore -s@ -SW hello.c-
Teil der git[1] Suite
-git restore [<opções>] [--source=<árvore>] [--staged] [--worktree] [--] <pathspec>… -git restore [<opções>] [--source=<árvore>] [--staged] [--worktree] --pathspec-from-file=<arquivo> [--pathspec-file-nul] -git restore (-p|--patch) [<opções>] [--source=<árvore>] [--staged] [--worktree] [--] [<pathspec>…]-
Restaure os caminhos definidos na árvore de trabalho com algum conteúdo de uma fonte de restauração. Se um caminho for monitorado, porém não existir na fonte de restauração, ele será removido para coincidir com a fonte.
-O comando também pode ser usado para restaurar o conteúdo no índice com a opção --staged, ou para restaurar a árvore de trabalho e o índice com --staged --worktree.
É predefinido que caso --staged seja utilizado, o conteúdo será restaurado a partir do HEAD, caso contrário, a partir do índice. Utilize a opção --source para restaurar a partir de um commit diferente.
Para as diferenças entre os três comandos consulte "Redefinir, restaurar e reverter" em git[1].
-ESTE COMANDO É EXPERIMENTAL. O SEU COMPORTAMENTO PODE MUDAR.
-Restaure arquivos da árvore de trabalho com o conteúdo da árvore informada. É comum especificar a árvore de origem nomeando um commit, ramo ou tag associado com ela.
-Caso não seja definido, o conteúdo será restaurado a partir de HEAD caso --staged seja informado, caso contrário, a restauração será a partir do índice.
Como um caso especial, é possível utilizar "A...B" como um atalho como uma base para a mesclagem de A e B caso exista exatamente uma base de merge. Você pode deixar de fora, no máximo, um de A e` B`, caso onde a predefinição retorna para HEAD.
Selecione a diferença entre os blocos interativamente entre a origem da restauração e o local da restauração. Consulte a seção “Modo Interativo” do git-add[1] para aprender como operar o modo --patch.
Note que o comando --patch pode não aceitar nenhum pathspec e solicitará a restauração de todos os caminhos modificados.
Especifica o local da restauração. É predefinido que caso nenhuma opção seja utilizada a árvore de trabalho será restaurada. Ao usar a opção --staged apenas a índice será restaurado. A utilização de ambas as opções faz a restauração de ambos.
Silencioso, suprima as mensagens de feedback. Implies --no-progress.
A condição do progresso é relatado no fluxo de erro predefinido ao estar conectado num terminal, a menos que as opções --quiet seja utilizados. Esta opção ativa os relatórios de progresso, mesmo que não estejam anexados a um terminal, independentemente da opção --quiet.
Ao restaurar os arquivos no índice da árvore de trabalho, utilize o estágio #2 (nosso) ou #3 (deles) para os caminhos que não foram mesclados. Esta opção não pode ser usada ao verificar caminhos de uma árvore (ou seja, com a opção --source).
Note que durante o git rebase e o git pull --rebase, o nosso e o deles podem aparecer trocados. Para mais detalhes, consulte a explicação das mesmas opções em git-checkout[1].
Ao restaurar os arquivos no índice da árvore de trabalho, recrie a mesclagem conflitante nos caminhos que ainda não foram mesclados. Esta opção não pode ser usada ao verificar caminhos de uma árvore (ou seja, com a opção --source).
O mesmo que a opção --merge acima, porém altera a maneira como os blocos conflitantes são apresentados, ao substituir a variável de configuração merge.conflictStyle. Os valores possíveis são merge (predefinido), "diff3" e "zdiff3".
Não aborte a operação ao restaurar os arquivos no índice da árvore de trabalho caso existam entradas que não foram mescladas e tão pouco as opções --ours, --theirs, --merge ou --conflict tenham sido utilizadas. Nada acontece com os caminhos das árvores de trabalho caso eles não tenham sido mesclados.
É predefinido que no modo de averiguação esparsa, apenas atualize as entradas que coincidam com <pathspec> e os padrões esparsos no $GIT_DIR/info/sparse-checkout. Esta opção ignora os padrões esparsos e restaura incondicionalmente todos os arquivos que estejam no <pathspec>.
Caso o <pathspec> nomeie um submódulo ativo e o local da restauração incluir a árvore de trabalho, o submódulo será atualizado apenas caso esta opção seja utilizada. Neste caso, a sua árvore de trabalho será restaurada para o commit registrado no superprojeto e quaisquer alterações locais serão substituídas. Caso nada (ou a opção --no-recurse-submodules) seja utilizado, os submódulos que trabalham nas árvores não serão atualizados. Assim como git-checkout[1], isso faz com que o HEAD seja desanexando do submódulo.
No modo de sobreposição, o comando nunca remove os arquivos durante a restauração. No modo sem sobreposição, os arquivos rastreados que não aparecem na árvore --source são removidos para fazê-los coincidir exatamente com a <árvore>. A predefinição é sem sobreposição.
O "pathspec" é passado com <arquivo> em vez dos argumentos da linha de comando. Caso o <arquivo> seja exatamente -, a entrada padrão será utilizada. Os elementos do "pathspec" são separados por caracteres de término de linha LF ou CR/LF. Os elementos do "pathspec" podem ser citados conforme explicado na variável de configuração core.quotePath (consulte git-config[1]). Consulte também opção --pathspec-file-nul e o global --literal-pathspecs.
Só faz algum sentido caso seja utilizado junto com a opção --pathspec-from-file. Os elementos "pathspec" são separados com caracteres NUL e todos os outros caracteres são considerados de forma literal (incluindo as novas linhas e as citações).
Não interprete mais argumentos como opções.
-Limita os caminhos afetados pela operação.
-Para mais detalhes sobre a sintaxe, consulte a entrada pathspec em gitglossary[7].
-A sequência a seguir muda para o ramo master, reverte o` Makefile` para duas revisões anteriores, apaga o hello.c por engano e o recupera do índice.
$ git switch master -$ git restore --source master~2 Makefile (1) -$ rm -f hello.c -$ git restore hello.c (2)-
tirar um arquivo de um outro commit
-restaurar o hello.c do índice
-Caso queira restaurar TODOS os arquivos do código fonte C para que coincidam com a versão do índice, você pode usar
-$ git restore '*.c'-
Observe as aspas em torno de *.c. O arquivo hello.c também será restaurado, mesmo que não esteja mais na árvore de trabalho, porque o agrupamento do arquivo é usado para corresponder às entradas no índice (não na árvore de trabalho pelo shell).
Para restaurar todos os arquivos no diretório atual
-$ git restore .-
ou para restaurar todos os arquivos do cume da árvore de trabalho com a mágica do "pathspec" (consulte gitglossary[7])
-$ git restore :/-
Para restaurar um arquivo no índice que coincida com a versão em HEAD (é o mesmo que usar git-reset[1])
$ git restore --staged hello.c-
ou você pode restaurar o índice e a árvore de trabalho (é o mesmo que usar git-checkout[1])
-$ git restore --source=HEAD --staged --worktree hello.c-
ou a forma abreviada que é mais prática, mas menos legível:
-$ git restore -s@ -SW hello.c-
Parte do conjunto git[1]
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
rev-list is a very essential Git command, since it provides the ability to build and traverse commit ancestry graphs. For this reason, it has a lot of different options that enables it to be used by commands as different as git bisect and git repack.
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Teil der git[1] Suite
-Liste les commits qui sont accessibles en suivant les liens parents du ou des commits donnés, mais exclut les commits qui sont accessibles depuis le ou les commits donnés avec un ^ devant eux. La sortie est donnée dans l’ordre chronologique inverse par défaut.
Vous pouvez considérer cela comme une opération sur un ensemble. Les commits accessibles à partir de n’importe lequel des commits donnés sur la ligne de commande forment un ensemble, puis les commits accessibles à partir de n’importe lequel de ceux donnés avec ^ devant sont soustraits de cet ensemble. Les commits restants sont ceux qui apparaissent dans la sortie de la commande. Diverses autres options et paramètres de chemins peuvent être utilisés pour limiter davantage le résultat.
-Ainsi, la commande suivante :
-$ git rev-list foo bar ^baz-
signifie "liste tous les commits qui sont accessibles depuis foo ou bar, mais pas depuis baz".
-Une notation spéciale "<commit1>..<commit2>" peut être utilisée comme raccourci pour "^<commit1> <commit2>". Par exemple, l’un ou l’autre des éléments suivants peut être utilisé de manière interchangeable :
-$ git rev-list origin..HEAD -$ git rev-list HEAD ^origin-
Une autre notation spéciale est "<commit1>…<commit2>" qui est utile pour les fusions. L’ensemble de commits résultant est la différence symétrique entre les deux opérandes. Les deux commandes suivantes sont équivalentes :
-$ git rev-list A B --not $(git merge-base --all A B) -$ git rev-list A...B-
rev-list is a very essential Git command, since it provides the ability to build and traverse commit ancestry graphs. For this reason, it has a lot of different options that enables it to be used by commands as different as git bisect and git repack.
-En plus de spécifier une plage de commits qui doivent être listés en utilisant les notations spéciales expliquées dans la description, des limitations supplémentaires de commits peuvent être appliquées.
-L’utilisation d’un plus grand nombre d’options filtre généralement plus la sortie (par exemple --since=<date1> limite aux commits plus récents que <date1>, et son utilisation avec --grep=<motif> limite aux commits dont le message de journal a une ligne qui correspond <motif>), sauf indication contraire.
Notez que celles-ci sont appliquées avant les options de classement et de formatage des commits, telles que --reverse.
Limite le nombre de commits dans la sortie.
-Sauter’nombre' commits avant de commencer à afficher la sortie de journal.
-Afficher les commits plus récents qu’une date spécifique.
-Afficher tous les commits plus récents qu’une date spécifique. Cela visite tous les commits dans la plage, plutôt que de s’arrêter au premier commit qui est plus ancien qu’une date spécifique.
-Afficher les commits plus anciens qu’une date spécifique.
-Limiter la sortie des commits à une plage de temps spécifiée.
-Limiter la sortie des commits à ceux dont les lignes d’en-tête auteur/validateur correspondent au motif spécifié (expression régulière). Avec plus d’un --author=<motif>, les commits dont l’auteur correspond à l’un des motifs donnés sont choisis (de même pour plusieurs --committer=<motif>).
Limiter la sortie des commits à ceux dont les entrées de reflog correspondent au motif spécifié (expression régulière). Avec plus d’un --grep-reflog, les commits dont le message de reflog correspond à l’un des modèles donnés sont choisis. C’est une erreur d’utiliser cette option à moins que --walk-reflogs ne soit utilisé.
Limiter la sortie des commits à ceux dont un message de validation correspond au motif spécifié (expression régulière). Avec plus d’un --grep=<motif>, les commits dont le message correspond à l’un des motifs donnés sont choisis (mais voir --all-match).
Limiter la sortie des commits à ceux qui correspondent à la fois à tous les --grep donnés, au lieu de ceux qui correspondent à au moins un.
Limiter la sortie des commits à ceux dont un message de validation ne correspond pas au motif spécifié avec --grep=<motif>.
Faites correspondre les expressions régulières sans tenir compte de la casse des lettres.
-Considérer les motifs limitatifs comme des expressions régulières de base ; c’est la valeur par défaut.
-Considérer les motifs limitatifs comme des expressions régulières étendues au lieu des expressions régulières par défaut de base.
-Considérer les motifs limitatifs comme des chaînes de caractères fixes (ne pas interpréter le motif comme une expression régulière).
-Considérer les motifs limitatifs comme des expressions régulières compatibles Perl.
-La prise en charge de ces types d’expressions régulières est une dépendance optionnelle à la compilation. Si Git n’a pas été compilé avec ce support et que cette option est activée, la commande se termine immédiatement.
-Arrêter lorsqu’un chemin donné disparaît de l’arbre.
-N’afficher que les commits de fusion. C’est exactement la même chose que --min-parents=2.
Ne pas afficher les commits avec plus d’un parent. C’est exactement la même chose que --max-parents=1.
Afficher uniquement les commits qui ont au moins (ou au plus) autant de commits parents. En particulier, --max-parents=1 est la même chose que --no-merges, --min-parents=2 est la même chose que --merges. --max-parents=0 donne tous les commits racine et --min-parents=3 toutes les fusions octopus.
--no-min-parents et --no-max-parents réinitialisent ces limites (à sans limite). Les formes équivalentes sont --min-parents=0 (tout commit a 0 ou plus de parents) et --max-parents=-1 (les nombres négatifs dénotent l’absence de limite supérieure).
Lors de la recherche de commits à inclure, ne suivre que le premier commit parent lors d’un commit de fusion. Cette option peut donner une meilleure vue d’ensemble lors de l’affichage de l’évolution d’une branche de sujet particulière, parce que la fusion dans une branche de sujet a tendance à n’être que des mises à jour avec l’amont de temps en temps, et cette option permet d’ignorer les commits individuels apportés dans votre historique par de telles fusions.
-Lors de la recherche de commits à exclure (avec un ^ ;), ne suivre que le premier commit parent lorsqu’un commit de fusion est vu. Cela peut être utilisé pour trouver l’ensemble des changements dans une branche de sujet à partir du point où elle a divergé de la branche distante, étant donné que des fusions arbitraires peuvent être des changements de branches thématiques valides.
-Inverse le sens du préfixe ^ (ou son absence) pour tous les spécificateurs de révision suivants, jusqu’au prochain --not. Lorsqu’il est utilisé sur la ligne de commande avant --stdin, les révisions passées par stdin ne seront pas affectées. Inversement, lorsqu’il est passé par l’entrée standard, les révisions passées sur la ligne de commande ne seront pas affectées.
Faire comme si toutes les refs de refs/, ainsi que HEAD, étaient listées sur la ligne de commande comme'<commit>'.
Faire comme si toutes les refs de refs/heads étaient listées sur la ligne de commande comme'<commit>'. Si'<motif>' est fournir, limiter les branches à celles qui correspondent à un glob shell donné. Si le motif ne présente pas de ?, *, ni [, /* à la fin est implicite.
Faire comme si toutes les refs de refs/tags étaient listées sur la ligne de commande comme'<commit>'. Si'<motif>' est fournir, limiter les étiquettes à celles qui correspondent à un glob shell donné. Si le motif ne présente pas de ?, *, ni [, /* à la fin est implicite.
Faire comme si toutes les refs de ‘refs/remotes’ étaient listées sur la ligne de commande comme'<commit>'. Si'<motif>' est donné, limiter les branches de suivi à distance à celles qui correspondent à un glob shell donné. Si le motif ne présent pas ?, *, ni [, /* à la fin est implicite.
-Faire comme si toutes les réfs correspondant au shell glob'<motif-glob>' étaient listées sur la ligne de commande comme'<commit>'. Le préfixe refs/, est automatiquement ajouté s’il n’y en a pas. Si le motif ne présente pas de ?, *, ni [, /* à la fin est implicite.
-Ne pas inclure les références correspondant à'<glob-pattern>' que les --all, --branches, --tags, --remotes, ou --glob suivantes considéreraient autrement. Les répétitions de cette option accumulent les motifs d’exclusion jusqu’à la prochaine option --all, --branches, --tags, --remotes ou --glob (les autres options ou arguments n’éliminent pas les motifs accumulés).
Les motifs donnés ne doivent pas commencer par refs/heads, refs/tags, ou refs/remotes lorsqu’ils sont appliqués à --branches, --tags, ou --remotes, respectivement, et ils doivent commencer par refs/ lorsqu’ils sont appliqués à --glob ou --all. Si un'/*' final est intentionnel, il doit être donné explicitement.
Ne pas inclure les références qui seraient cachées par git-fetch, git-receive-pack ou git-upload-pack en consultant la configuration fetch.hideRefs, receive.hideRefs ou uploadpack.hideRefs`correspondante ainsi que `transfer.hideRefs (voir git-config[1]). Cette option affecte l’option de pseudo-référence suivante --all ou --glob et est effacée après leur traitement.
Faire comme si tous les objets mentionnés par les reflogs étaient listés sur la ligne de commande comme <commit>.
Faire comme si tous les objets mentionnés en tant que sommets de référence des dépôts alternatifs étaient listés sur la ligne de commande. Un dépôt alternatif est tout dépôt dont le répertoire d’objets est spécifié dans objects/info/alternates. L’ensemble des objets inclus peut être modifié par core.alternateRefsCommand, etc. Voir git-config[1].
Par défaut, tous les arbres de travail seront examinés par les options suivantes lorsqu’il y en a plusieurs (voir git-worktree[1]) : --all, --reflog et --indexed-objects. Cette option les oblige à n’examiner que l’arbre de travail actuel.
En voyant un nom d’objet invalide dans l’entrée, faire comme si la mauvaise entrée n’avait pas été donnée.
-En plus d’obtenir des arguments de la ligne de commande, les lire aussi depuis l’entrée standard. Cela accepte des commits et des pseudo-options comme --all et --glob=. Lorsqu’un séparateur -- est vu, les entrées suivantes sont traitées comme des chemins et utilisées pour limiter le résultat. Les drapeaux comme --not qui sont lus via l’entrée standard ne sont respectés que pour les arguments passés de la même manière et n’influenceront aucun argument de ligne de commande suivant.
Ne rien imprimer en sortie standard. Cette forme est principalement destinée à permettre à l’appelant de tester l’état de sortie pour voir si une série d’objets est entièrement connectée (ou non). C’est plus rapide que de rediriger stdout vers /dev/null car la sortie n’a pas besoin d’être formatée.
Supprimer la sortie normale ; afficher plutôt la somme des octets utilisés pour le stockage sur disque par les commits ou les objets sélectionnés. Cela équivaut à envoyer la sortie dans git cat-file --batch-check='%(objectsize:disk)', sauf que cela fonctionne beaucoup plus vite (surtout avec --use-bitmap-index). Voir la section AVERTISSEMENTS dans git-cat-file[1] pour les limitations de ce que signifie "stockage sur disque". Avec la valeur optionnelle human, la taille du stockage sur disque est affichée par une chaîne de caractères lisible par l’homme (par exemple 12,24 Kio, 3,50 Mio).
Comme --cherry-pick (voir ci-dessous) mais marquer les commits équivalents avec == plutôt que de les omettre, et les différents avec +.
Omettre tout commit qui introduit le même changement qu’un autre commit de l'"autre côté" lorsque l’ensemble des commits est limité avec une différence symétrique.
-Par exemple, si vous avez deux branches, A et B, une façon habituelle de lister tous les commits d’un seul côté d’entre elles est avec --left-right (voir l’exemple ci-dessous dans la description de l’option --left-right). Cependant, cela montre les commits qui ont été picorés sur l’autre branche (par exemple, “3rd on b” peut être trié sur la branche A). Avec cette option, ces paires de commits sont exclues de la sortie.
Ne lister que les commits du côté respectif d’une différence symétrique, c’est-à-dire seulement ceux qui seraient marqués < resp. > par --left-right.
Par exemple, --cherry-pick --right-only A...B omet les commits de B qui sont dans A ou sont équivalents en rustine à un commit en A. En d’autres termes, cela liste les commits + de git cherry A B. Plus précisément, --cherry-pick --right-only --no-merges donne la liste exacte.
Un synonyme pour --right-only --cherry-mark --no-merges ; utile pour limiter la sortie aux commits de notre côté et marquer ceux qui ont été appliqués de l’autre côté d’un historique en fourche avec git log --cherry amont...mabranche', similaire à `git cherry upstream mabranche.
Au lieu de marcher dans la chaîne des commits ancêtres, parcourir les entrées de reflog du plus récent au plus ancien. Lorsque cette option est utilisée, vous ne pouvez pas spécifier de commits à exclure (c’est-à-dire que les notations ^commit, commit1..commit2 et’commit1...commit2' ne peuvent pas être utilisées).
-Avec un format --pretty autre que online et reference (pour des raisons évidentes), cela fait que la sortie a deux lignes supplémentaires d’informations tirées du reflog. L’indicateur de reflog dans la sortie peut être affiché comme ref@{<Nième>} (où <Nième> est l’index chronologique inverse dans le reflog) ou comme ref@{<horodatage>} (avec l'<horodatage> pour cette entrée), selon quelques règles :
Si le point de départ est spécifié comme ref@{<Nième>}, afficher le format de l’index.
Si le point de départ a été spécifié comme ref@{now}, afficher le format de l’horodatage.
Si ni l’un ni l’autre n’a été utilisé, mais que --date' a été donné sur la ligne de commande, afficher l'horodatage dans le format demandé par `--date.
Sinon, afficher le format de l’index.
-Sous --pretty=oneline, le message de commit est préfixé avec cette information sur la même ligne. Cette option ne peut pas être combinée avec --reverse. Voir aussi git-reflog[1].
Sous l’option --pretty=reference, ces informations ne seront pas affichées du tout.
Afficher les commits touchant les chemins conflictuels dans la plage HEAD... <autre>, où <autre> est la première pseudo-ref existante dans MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD ou REBASE_HEAD. Fonctionne seulement lorsque l’index a des entrées non fusionnées. Cette option peut être utilisée pour montrer les commits pertinents lors de la résolution des conflits à partir d’une fusion à 3 voies.
Afficher les commits de limite exclus. Les limites sont préfixées par -.
Essayer d’accélérer la traversée en utilisant l’index bitmap empaqueté (si disponible). Notez que lorsque vous parcourez avec --objects, les arbres et les blobs n’auront pas leur chemin associé affiché.
Afficher les rapports d’avancement sur stderr au fur et à mesure que les objets sont pris en compte. Le texte "<en-tête>" sera affiché à chaque mise à jour de l’état d’avancement.
-Parfois vous n’êtes intéressé que par certaines parties de l’historique, par exemple les commits qui modifient un <chemin> particulier. Mais il y a deux parties dans la Simplification de l’historique, une partie est la sélection des commits et l’autre la manière de le faire, car il existe différentes stratégies pour simplifier l’historique.
-Les options suivantes sélectionnent les commits à afficher :
-Notez que des commits supplémentaires peuvent être affichés pour donner un historique significatif.
-Les options suivantes influent sur la façon dont la simplification est effectuée :
-Simplifie l’historique jusqu’à l’historique le plus simple en expliquant l’état final de l’arbre. Le plus simple parce qu’il taille certaines branches latérales si le résultat final est le même (c’est-à-dire qu’il fusionne des branches avec le même contenu)
-Inclure tous les commits du mode par défaut, mais aussi tous les commits de fusion qui ne sont pas MEMEARBRE au premier parent mais qui sont MEMEARBRE à un parent ultérieur. Ce mode est utile pour montrer les commits de fusion qui ont "introduit en premier" une modification dans une branche.
-Identique au mode par défaut, mais ne pas élaguer l’historique.
-Seuls les commits sélectionnés sont affichés, plus certains pour avoir un historique significatif.
-Tous les commits de l’historique simplifié sont affichés.
-Option supplémentaire à --full-history pour supprimer certaines fusions inutiles de l’historique résultant, car il n’y a pas de commits sélectionnés contribuant à cette fusion.
Lorsque l’on donne une plage de commits à afficher (par exemple commit1..commit2 ou commit2 ^commit1), n’afficher que les commits de cette plage qui sont des ancêtres de <commit>, des descendants de <commit>, ou <commit> lui-même. Si aucun commit n’est spécifié, utiliser commit1 (la partie exclue de la plage) comme <commit>. Peut être passée plusieurs fois ; si c’est le cas, un commit est inclus s’il est l’un des commits donnés ou s’il est un ancêtre ou un descendant de l’un d’eux.
-Une explication plus détaillée suit.
-Supposons que vous ayez spécifié foo pour <chemins>. Nous appellerons les commits qui modifient foo !MEMEARBRE, et le reste MEMEARBRE. (Dans un diff filtré pour foo, ils sont différents et égaux, respectivement.)
Dans ce qui suit, nous nous référerons toujours au même exemple d’historique pour illustrer les différences entre les paramètres de simplification. Nous supposons que vous filtrez pour un fichier foo dans ce graphe de commits :
.-A---M---N---O---P---Q - / / / / / / - I B C D E Y - \ / / / / / - `-------------' X-
La ligne horizontale de l’historique A---Q est prise pour être le premier parent de chaque fusion. Les commits sont :
-I est le commit initial, dans lequel foo` existe avec le contenu ''asdf', et un fichier quux existe avec le contenu 'quux'. Les commits initiaux sont comparés à un arbre vide, donc I est !MEMEARBRE.
Dans A, foo ne contient que “foo”.
B contient le même changement que A. Sa fusion M est triviale et donc MEMEARBRE pour tous les parents.
C ne change pas foo, mais sa fusion N le change en “foobar”, donc ce n’est pas MEMEARBRE à aucun parent.
D met foo sur baz. Sa fusion O combine les chaînes de caractères de N et D à “foobarbaz” ; c’est-à-dire qu’elle n’est pas MEMEARBRE à aucun parent.
E change quux en “xyzzy”, et sa fusion P combine les chaînes en “quux xyzzy”. P est MEMEARBRE à O, mais pas à E.
X est un commit racine indépendant qui a ajouté un nouveau fichier side, et Y l’a modifié. Y est MEMEARBRE à X. Sa fusion Q a ajouté side à P, et Q est MEMEARBRE à P, mais pas à Y.
rev-list traverse en arrière l’historique, y compris ou en excluant les commits en fonction de si --full-history et / ou la réécriture des parents (par l’intermédiaire de --parents ou --children) sont utilisés. Les paramètres suivants sont disponibles.
Les commits sont inclus s’ils ne sont pas MEMEARBRE à un parent (bien que ceci puisse être changé, voir --sparse ci-dessous). Si le commit était une fusion, et que c’était MEMEARBRE à un des parents, ne suivez que ce parent. (Même s’il y a plusieurs parents MEMEARBRE, ne suivez qu’un seul d’entre eux.) Sinon, suivez tous les parents.
Il en résulte :
-.-A---N---O - / / / - I---------D-
Notez que la règle de ne suivre que le parent MEMEARBRE, s’il y en a un disponible, a entièrement supprimé B de la considération. C a été pris en compte via N, mais il est MEMEARBRE. Les commits racines sont comparés à un arbre vide, donc I est !MEMEARBRE.
Les relations parents/enfants ne sont visibles qu’avec --parents, mais cela n’affecte pas les commits sélectionnés en mode par défaut, nous avons donc montré les lignes parentales.
Ce mode diffère du mode par défaut en un point : toujours suivre tous les parents d’une fusion, même si c’est MEMEARBRE à l’un d’eux. Même si plus d’un côté de la fusion a des commits qui sont inclus, cela ne signifie pas que la fusion elle-même l’est ! Dans l’exemple, nous obtenons
-I A B N D O P Q-
M a été exclu parce qu’il s’agit d’un MEMEARBRE pour les deux parents. E, C et B ont tous été parcourus, mais seul B était un !MEMEARBRE, donc les autres n’apparaissent pas.
Notez que sans réécriture des parents, il n’est pas vraiment possible de parler des relations parent/enfant entre les commits, donc nous les montrons déconnectés.
-Les commits ordinaires ne sont inclus que s’ils le sont !MEMEARBRE (bien que cela puisse être changé, voir --sparse ci-dessous).
Les fusions sont toujours incluses. Cependant, leur liste de parents est réécrite : à côté de chaque parent, élaguer les commits qui ne sont pas inclus eux-mêmes. Il en résulte
-.-A---M---N---O---P---Q - / / / / / - I B / D / - \ / / / / - `-------------'-
À comparer avec --full-history sans réécrire ci-dessus. Notez que E a été élagué parce que c’est MEMEARBRE, mais la liste parent de P a été réécrite pour contenir le parent I de E. Il en a été de même pour C et N, et X, Y et Q.
En plus des paramètres ci-dessus, vous pouvez modifier si MEMEARBRE affecte l’inclusion :
-Les commits qui sont parcourus sont inclus s’ils ne sont pas MEMEARBRE pour aucun parent.
-Tous les commits qui sont parcourus sont inclus.
-Notez que sans --full-history, cela simplifie encore les fusions : si l’un des parents est MEMEARBRE, nous ne suivons que celui-là, donc les autres côtés de la fusion ne sont jamais parcourus.
Tout d’abord, construire un graphe d’historique de la même manière que --full-history avec la réécriture des parents (voir ci-dessus).
Puis simplifier chaque commit C à son remplacement C' dans l’historique final selon les règles suivantes :
Définir C' sur C.
Remplacer chaque parent P de C' par sa simplification P'. Dans le processus, déposer les parents qui sont les ancêtres d’autres parents ou qui sont des commits racines MEMEARBRE à un arbre vide, et supprimer les doublons, mais prendre soin de ne jamais laisser tomber tous les parents auxquels nous sommes MEMEARBRE.
Si après cette réécriture des parents, C' est un commit racine ou de fusion (qui a zéro ou >1 parents), un commit limite, ou !MEMEARBRE, il est conservé. Sinon, il est remplacé par son seul parent.
L’effet de ceci est mieux montré en comparant avec --full-history avec la réécriture des parents. L’exemple se transforme en :
.-A---M---N---O - / / / - I B D - \ / / - `---------'-
Notez les principales différences entre N, P et Q par rapport à --full-history :
'La liste des parents de N a été supprimée, parce qu’elle est un ancêtre de l’autre parent M. Pourtant, N est resté parce qu’il est !MEMEARBRE.
De même, la liste des parents de P a eu I supprimé. P a ensuite été complètement enlevé, parce qu’il avait un parent et qu’il est MEMEARBRE.
La liste des parents de Q a rendu Y simplifié en X. X a ensuite été supprimé, parce que c’était une racine MEMEARBRE. Q a ensuite été complètement supprimée, parce qu’elle avait un parent et qu’il est MEMEARBRE.
Il existe un autre mode de simplification :
-Limiter les commits affichés à ceux qui sont un ancêtre de <commit>, ou qui sont un descendant de <commit>, ou sont <commit> lui-même.
-À titre d’exemple, considérons l’historique de commits suivant :
-D---E-------F - / \ \ - B---C---G---H---I---J - / \ - A-------K---------------L--M-
Un D..M régulier calcule l’ensemble des commits qui sont les ancêtres de M, mais exclut ceux qui sont les ancêtres de D. C’est utile pour voir ce qui s’est passé dans l’historique qui a mené à M depuis le D, au sens de « ce que M a qui n’existait pas dans D ». Le résultat dans cet exemple serait tous les commits, sauf A et B (et D lui-même, bien sûr).
Quand nous voulons savoir quels commits dans M sont contaminés par le bogue introduit par D et ont besoin d’être corrigés, cependant, nous pourrions vouloir voir seulement le sous-ensemble de D..M qui sont en fait des descendants de D, c’est-à-dire en excluant C et K. C’est exactement ce que fait l’option --ancestry-path. Appliqué à l’intervalle D..M, il se traduit en :
E-------F - \ \ - G---H---I---J - \ - L--M-
Nous pouvons également utiliser --ancestry-path=D au lieu de --ancestry-path qui signifie la même chose lorsqu’il est appliqué à la plage D..M mais est juste plus explicite.
Si nous sommes plutôt intéressés par un sujet donné dans cette plage, et tous les commits affectés par ce sujet, nous pouvons seulement vouloir voir ceux du sous-ensemble de D..M qui contiennent ce sujet dans leur chemin d’ascendance. Ainsi, en utilisant --ancestry-path=H D..M par exemple, on obtiendrait le résultat suivant :
E - \ - G---H---I---J - \ - L--M-
Alors que --ancestry-path=K D...M donnerait comme résultat
K---------------L--M-
Avant de discuter d’une autre option, --show-pulls, nous devons créer un nouvel exemple d’historique.
Un problème courant auquel les utilisateurs sont confrontés lorsqu’ils consultent l’historique simplifié est qu’un commit dont ils savent qu’il a modifié un fichier n’apparaît pas dans l’historique simplifié du fichier. Prenons un nouvel exemple et montrons comment des options telles que --full-history et --simplify-merges fonctionnent dans ce cas :
.-A---M-----C--N---O---P - / / \ \ \/ / / - I B \ R-'`-Z' / - \ / \/ / - \ / /\ / - `---X--' `---Y--'-
Pour cet exemple, supposons que I a créé fichier.txt qui a été modifié par A, B et X de différentes manières. Les commits à parent unique C, Z et Y ne modifient pas fichier.txt. Le commit de fusion M a été créé en résolvant le conflit de fusion pour inclure les deux modifications de A et B et n’est donc pas MEMEARBRE pour l’un ou l’autre. Le commit de fusion R, cependant, a été créé en ignorant le contenu du fichier fichier.txt à M et en prenant seulement le contenu du fichier fichier.txt à X. Par conséquent, R est MEMEARBRE à X mais pas à M. Enfin, la résolution de fusion naturelle pour créer N est de prendre le contenu du fichier.txt à R, donc N est MEMEARBRE à R mais pas à C. La fusion engage O et P sont MEMEARBRE à leurs premiers parents, mais pas à leurs seconds parents, Z et Y respectivement.
En utilisant le mode par défaut, N et R ont tous deux un parent MEMEARBRE, donc ces bords sont parcourus et les autres sont ignorés. Le graphique d’historique qui en résulte est :
I---X-
Lors de l’utilisation de --full-history, Git parcourt toutes les arêtes . Il découvrira les commits A et B et la fusion M, mais aussi les commits de fusion O et P. Avec la réécriture des parents, le graphe résultant est :
.-A---M--------N---O---P - / / \ \ \/ / / - I B \ R-'`--' / - \ / \/ / - \ / /\ / - `---X--' `------'-
Ici, les commits de fusion O et P apportent un bruit supplémentaire, car ils n’ont pas réellement apporté de modification à fichier.txt. Ils ont seulement fusionné une branche thématique qui était basée sur une ancienne version de fichier.txt. C’est un problème courant dans les dépôts utilisant une organisation où de nombreux contributeurs travaillent en parallèle et fusionnent leurs branches thématiques le long d’un seul tronc : de nombreuses fusions sans rapport apparaissent dans les résultats de --full-history.
Lorsque l’on utilise l’option --simplify-merges, les valeurs O et P disparaissent des résultats. Cela est dû au fait que les seconds parents réécrits de O et P sont accessibles depuis leurs premiers parents. Ces arêtes sont supprimées et les commits ressemblent alors à des commits monoparentaux qui sont MEMEARBRE pour leur parent. C’est également le cas pour le commit N, ce qui donne l’historique suivant :
.-A---M--. - / / \ - I B R - \ / / - \ / / - `---X--'-
Dans cette optique, nous voyons toutes les modifications monoparentales de A, B et X. Nous voyons également la fusion M, soigneusement résolue, et la fusion R, pas si soigneusement résolue. Ces informations sont généralement suffisantes pour déterminer pourquoi les commits A et B ont « disparu » de l’historique dans la vue par défaut. Cependant, cette approche pose quelques problèmes.
La première question est celle de la performance. Contrairement à toutes les options précédentes, l’option --simplify-merges nécessite de parcourir l’historique complet des commits avant de renvoyer un seul résultat. Cela peut rendre l’option difficile à utiliser pour les très grands dépôts.
La deuxième question est celle de l’audit. Lorsque plusieurs contributeurs travaillent sur le même dépôt, il est important de savoir quels commits de fusion ont introduit un changement dans une branche importante. La fusion problématique R ci-dessus n’est probablement pas le commit de fusion qui a été utilisé pour fusionner dans une branche importante. Au lieu de cela, la fusion N a été utilisée pour fusionner R et X dans la branche importante. Ce commit peut avoir des informations sur la raison pour laquelle la modifcation X est venu remplacer les changements de A et B dans son message de commit.
En plus des commits indiqués dans l’historique par défaut, montrer chaque commit de fusion qui n’est pas MEMEARBRE à son premier parent, mais qui est MEMEARBRE à un parent ultérieur.
-Quand un commit de fusion est inclus par --show-pulls, cette fusion est traitée comme si elle avait "tiré" le changement d’une autre branche. Lorsque l’on utilise --show-pulls sur cet exemple (et aucune autre option), le graphe résultant est :
I---X---R---N-
Ici, les commits de fusion R et N sont inclus, car ils ont tiré les commits X et R dans la branche de base, respectivement. Ces fusions sont les raisons pour lesquelles les commits A et B n’apparaissent pas dans l’historique par défaut.
Lorsque l’option --show-pulls est associée à l’option --simplify-merges, le graphe comprend toutes les informations nécessaires :
.-A---M--. N - / / \ / - I B R - \ / / - \ / / - `---X--'-
Remarquez que puisque M est accessible à partir de R, l’arête entre N et M a été simplifiée. Cependant, N apparaît toujours dans l’historique comme un commit important parce qu’il a « tiré » le changement R dans la branche principale.
L’option --simplify-by-decoration vous donne une vue d’ensemble de la topologie de l’historique, en omettant les commits qui ne sont pas référencés par des étiquettes. Les commits sont marqués comme !MEMEARBRE(en d’autres termes, conservés après les règles de simplification de l’historique décrites ci-dessus) si (1) ils sont référencés par des étiquettes, ou (2) ils changent le contenu des chemins donnés sur la ligne de commande. Tous les autres commits sont marqués comme MEMEARBRE (soumis à une possible simplification).
Limiter la sortie à l’objet commit qui est à peu près à mi-chemin entre les commits inclus et les commits exclus. Notez que la référence mauvaise de bissection refs/bisect/bad est ajoutée aux commits inclus (si elle existe) et la référence bonne de bissection refs/bisect/good-* est ajoutée aux commits exclus (s’ils existent). Ainsi, en supposant qu’il n’y ait pas de références dans refs/bisect/, si
$ git rev-list --bisect foo ^bar ^baz-
affiche midpoint, la sortie des deux commandes
-$ git rev-list foo ^midpoint - $ git rev-list midpoint ^bar ^baz-
seraient à peu près de la même longueur. Trouver le changement qui introduit une régression se réduit donc à une recherche binaire : générer et tester à plusieurs reprises de nouveaux midpoint jusqu’à ce que la chaîne de commits soit de longueur un.
-Cela calcule la même chose que --bisect, sauf que les références dans refs/bisect/ ne sont pas utilisées, et sauf que cela affiche un texte prêt à être évalué par le shell. Ces lignes attribueront le nom de la révision à mi-parcours à la variable bisect_rev, et le nombre prévu de commits à tester après bisect_rev est testé à bisect_nr, le nombre prévu de commits à tester si bisect_rev s’avère être bon à bisect_good, le nombre prévu de commits à tester si bisect_rev s’avère être mauvais à bisect_bad, et le nombre de commits que nous sommes en train de bissecter en ce moment à bisect_all.
Ceci affiche tous les objets commit entre les commits inclus et exclus, classés selon leur distance par rapport aux commits inclus et exclus. Les références dans refs/bisect/ ne sont pas utilisées. Le plus éloigné d’eux est affiché en premier. (C’est le seul affiché par --bisect.)
Ceci est utile car il est facile de choisir un bon commit à tester lorsque vous voulez éviter de tester certains d’entre eux pour une raison quelconque (ils peuvent ne pas compiler par exemple).
-Cette option peut être utilisée avec --bisect-vars, dans ce cas, après tous les objets commit triés, le texte sera le même que si --bisect-vars avait été utilisé seul.
Par défaut, les commits sont affichés dans l’ordre chronologique inverse.
-N’afficher aucun parent avant que tous ses enfants ne soient affichés, mais sinon montrer les commits dans l’ordre de l’horodatage des commits.
-N’afficher aucun parent avant que tous ses enfants ne soient affichés, mais autrement afficher les commits dans l’ordre d’horodatage de l’auteur.
-N’afficher aucun parent avant que tous ses enfants ne soient affichés, et éviter d’afficher des commits entremêlés sur plusieurs lignes d’historique.
-Par exemple, dans un historique de commit comme celui-ci :
----1----2----4----7 - \ \ - 3----5----6----8----
où les nombres indiquent l’ordre des horodatages de commit, git rev-list et consorts avec --date-order affichent les commits dans l’ordre d’horodatage : 8 7 6 5 4 3 2 1.
Avec --topo-order, ils afficheraient 8 6 5 5 3 3 7 4 7 4 2 1 (ou 8 7 4 2 2 6 5 5 3 1) ; certains commits plus anciens sont affichés avant les plus récents afin d’éviter de montrer mélangés ensemble les commits de deux pistes de développement parallèles.
Sortir les commits choisis pour être affichés (voir la section Limitation des commits ci-dessus) dans l’ordre inverse. Ne peut pas être combiné avec --walk-reflogs.
Ces options sont principalement destinées à l’empaquetage des dépôts Git.
-Imprimer les ID d’objet de tout objet référencé par les commits listés. --objects foo ^bar signifie donc “envoie-moi tous les ID d’objets que je dois télécharger si j’ai l’objet commit bar mais pas foo”. Voir aussi --object-names ci-dessous.
Imprimer les identifiants des arbres et des blobs dans l’ordre des commits. Les identifiants des arbres et des blobs sont imprimés que lors qu’ils sont référencés la première fois par un commit.
-Semblable à --objects, mais afficher aussi les ID des commits exclus préfixés par un caractère “-”. Ceci est utilisé par git-pack-objects[1] pour construire un paquet “thin”, qui enregistre les objets sous forme déltaifiée en fonction des objets contenus dans ces commits exclus pour réduire le trafic réseau.
Similaire à --objects-edge, mais s’efforce de trouver les commits exclus au prix d’un temps plus long de traitement. Ceci est utilisé à la place de --objects-edge pour construire des paquets “thin” pour les dépôts superficiels.
Faire comme si tous les arbres et tous les blobs utilisés par l’index étaient listés sur la ligne de commande. Notez que vous voudrez probablement utiliser aussi --objects.
Uniquement utile avec --objects ; afficher les ID d’objets qui ne sont pas dans les paquets.
Uniquement utile avec --objects ; affiche les noms des IDs d’objets trouvés. C’est le comportement par défaut. Notez que le "nom" de chaque objet est ambigu, et qu’il est principalement destiné à servir d’indice pour l’empaquetage des objets. En particulier : aucune distinction n’est faite entre les noms des étiquettes, des arbres et des blobs ; les noms des chemins peuvent être modifiés pour supprimer les nouvelles lignes ; et si un objet apparaît plusieurs fois avec des noms différents, un seul nom est affiché.
Uniquement utile avec --objects ; ne pas afficher les noms des ID des objets trouvés. Ceci inverse --object-names. Ce drapeau permet à la sortie d’être plus facilement analysée par des commandes telles que git-cat-file[1].
Uniquement utile avec l’un des ‘--objects* ; omettre des objets (généralement les blobs) de la liste des objets affichés. Le<spécificateur-de-filtre>’ peut être l’un des suivants :
-La forme --filter=blob:none omet tous les blobs.
-La forme'--filter=blob:limit=<n>[kmg]' omet les blobs d’au moins n octets ou unités. n peut être zéro. Les suffixes k, m et g peuvent être utilisés pour nommer les unités en Kio, Mio ou Gio. Par exemple,blob:limit=1k est identique à blob:limit=1024.
-La forme --filter=object:type=(tag|commit|tree|blob) permet d’omettre tous les objets qui ne sont pas du type demandé.
-La forme --filter=sparse:oid=<blob-esque> utilise une spécification d’extraction clairsemée contenue dans le blob (ou l’expression de blob) <blob-esque> pour omettre les blobs qui ne seraient pas nécessaires pour une extraction clairsemée sur les références demandées.
-La forme --filter=tree:<profondeur> omet tous les blobs et tous les arbres dont la profondeur de l’arbre racine est >= <profondeur> (profondeur minimale si un objet est situé à plusieurs profondeurs dans les commits traversés). <profondeur>=0 n’inclura pas d’arbres ni de blobs à moins d’être inclus explicitement dans la ligne de commande (ou dans l’entrée standard lorsque --stdin est utilisé). <profondeur>=1 inclura seulement l’arbre et les blobs qui sont référencés directement par un commit accessible depuis <commit> ou un objet explicitement donné. <profondeur>=2 est comme <profondeur>=1 tout en incluant aussi les arbres et les blobs d’un niveau supplémentaire tiré d’un commit ou d’un arbre explicitement donné.
-Notez que la forme --filter=sparse:path=<chemin> qui veut lire à partir d’un chemin arbitraire sur le système de fichiers a été supprimé pour des raisons de sécurité.
-Plusieurs drapeaux --filter= peuvent être spécifiés pour combiner les filtres. Seuls les objets acceptés par tous les filtres sont inclus.
-La forme'--filter=combine:<filtre1>+<filtre2>+…<filtreN>' peut aussi être utilisée pour combiner plusieurs filtres, mais c’est plus difficile que de répéter simplement le drapeau'--filter' et ce n’est généralement pas nécessaire. Les filtres sont joints par des signes + et les filtres individuels sont codés en % (c’est-à-dire codés comme des URL). Outre les caractères + et'%', les caractères suivants sont réservés et doivent également être encodés : ~!@#$^^&*()[]{]{}\ ;",<>?'` ainsi que tous les caractères avec un code ASCII ⇐ 0x20, qui inclut l’espace et la ligne nouvelle.
D’autres caractères arbitraires peuvent également être encodés. Par exemple,combine:tree:3+blob:none et combine:tree%3A3+blob%3Anone sont équivalents.
-Désactiver tout argument --filter= précédent.
Filtrer la liste des objets explicitement fournis, qui autrement seraient toujours imprimés même s’ils ne correspondent à aucun des filtres. Seulement utile avec --filter=.
Uniquement utile avec --filter= ; imprimer une liste des objets omis par le filtre. Les ID d’objet sont préfixés par un caractère "~".
Une option de débogage pour aider au développement futur de "clones partiels". Cette option spécifie comment les objets manquants sont traités.
-La forme --missing=error demande que rev-list s’arrête avec une erreur si un objet manquant est rencontré. C’est l’action par défaut.
-La forme --missing=allow-any permet de continuer le parcours d’objet si un objet manquant est rencontré. Les objets manquants seront silencieusement omis des résultats.
-Le forme --missing=allow-promisor est comme allow-any, mais ne permettra la traversée d’objets de continuer que pour les objets manquants du promettant EXPECTED. Les objets manquants inattendus entraîneront une erreur.
-La forme --missing=print est comme allow-any, mais affichera aussi une liste des objets manquants. Les ID d’objet sont préfixés par un caractère "?".
-Si quelques sommets passés à la traversée sont manquants, ils seront considérés comme manquants aussi, et la traversée les ignorera. Dans le cas où nous ne pouvons pas obtenir leur ID Objet, une erreur sera soulevée.
-(Pour usage interne seulement.) Préfiltrer la traversée de l’objet à la limite du promettant. Ceci est utilisé avec un clone partiel. C’est plus fort que --missing=allow-promisor parce qu’il limite la traversée, plutôt que de simplement réduire au silence les erreurs sur les objets manquants.
Montrer seulement les commits donnés, mais ne pas traverser leurs ancêtres. Ceci n’a aucun effet si une plage est spécifiée. Si l’argument unsorted est donné, les commits sont affichés dans l’ordre dans lequel ils ont été donnés sur la ligne de commande. Sinon (si sorted ou aucun argument n’a été donné), les commits sont affichés dans l’ordre chronologique inverse par date de validation. Ne peut pas être combiné avec --graph.
Remplacer un --no-walk précédent.
En utilisant ces options, git-rev-list[1] agira de la même manière que la famille plus spécialisée d’outils de journaux de validation : git-log[1], git-show[1] et git-whatchanged[1]
-Formater le contenu des journaux de commits dans un format donné, où <format> peut être au choix parmi oneline, short, medium, full, fuller, reference, email, raw, format:<chaîne> et tformat:<chaîne>. Lorsque <format> n’est rien de ce qui précède, et qu’il contient'%format', il agit comme si --pretty=tformat:<format> était donné.
-Voir la section "MISE EN FORME" pour plus de détails pour chaque format. Lorsque la partie'=<format>' est omise, la valeur par défaut est’medium'.
-Note : vous pouvez spécifier le format par défaut dans la configuration du dépôt commit.cleanup (voir git-config[1]).
Au lieu d’afficher le nom complet hexadécimal de 40 octets de l’objet commit, afficher un préfixe qui nomme l’objet de manière unique. L’option "--abbrev=<n>" (qui modifie également la sortie diff, si elle est affichée) peut être utilisée pour spécifier la longueur minimale du préfixe.
-Cela devrait rendre "--pretty=oneline" beaucoup plus lisible pour les personnes utilisant des terminaux à 80 colonnes.
-Afficher le nom complet hexadécimal de 40 octets de l’objet commit. Ceci annule --abbrev-commit, qu’elle soit explicitement ou implicitement impliquée par d’autres options telles que "--oneline". Elle remplace également la variable log.abbrevCommit.
C’est un raccourci pour "--pretty=oneline --abbrev-commit" utilisés ensemble.
-Les objets commit enregistrent l’encodage utilisé pour le message de log dans leur en-tête d’encodage ; cette option peut être utilisée pour indiquer à la commande de recoder le message de log du commit dans l’encodage préféré par l’utilisateur. Pour les commandes hors plomberie, cette valeur par défaut est UTF-8. Notez que si un objet prétend être encodé en X et que nous sortons en X, nous allons sortir l’objet à l’identique ; cela signifie que les séquences invalides dans la livraison originale peuvent être copiées dans la sortie. De même, si iconv(3) ne parvient pas à convertir le commit, nous produirons tranquillement l’objet original tel quel.
Effectuer une extension de tabulation (remplacer chaque tabulation par suffisamment d’espaces pour remplir jusqu’à la colonne d’affichage suivante qui est un multiple de'<n>') dans le message de journal avant de l’afficher dans la sortie. --expand-tabs est un raccourci pour --expand-tabs=8, et --no-expand-tabs est un raccourci pour --expand-tabs=0, qui désactive l’extension des tabulations.
Par défaut, les tabulations sont développées par les formatages qui indentent le message de log par 4 espaces (c’est-à-dire medium, qui est le format par défaut, full, fuller).
-Vérifier la validité d’un objet commit signé en passant la signature à gpg --verify et afficher le résultat.
Synonyme de --date=relative.
Ne prendre effet que pour les dates indiquées dans un format lisible par l’homme, par exemple lors de l’utilisation de --pretty. La variable config log.date définit une valeur par défaut pour l’option --date de la commande log. Par défaut, les dates sont affichées dans le fuseau horaire d’origine (soit celui du validateur ou celui de l’auteur). Si -local est ajouté au format (p. ex., iso-local), le fuseau horaire local de l’utilisateur est utilisé à la place.
--date=relative affiche les dates relatives à l’heure actuelle, par exemple “Il y a 2 heures”. L’option -local n’a aucun effet pour --date=relative.
--date=local est un alias pour --date=default-local.
--date=iso (ou --date=iso8601) montre les horodatages dans un format similaire à ISO 8601. Les différences par rapport au format strict ISO 8601 sont :
une espace au lieu du délimiteur date/heure T
une espace entre l’heure et le fuseau horaire
-pas de deux points entre les heures et les minutes du fuseau horaire
---date=iso-strict (ou --date=iso8601-strict) affiche les horodatages au format ISO 8601 strict.
--date=rfc (ou --date=rfc2822) montre les horodatages au format RFC 2822, souvent trouvés dans les messages électroniques.
--date=short montre seulement la date, mais pas l’heure, au format AAA-MM-JJ.
--date=raw montre la date en secondes depuis l’époque (1970-01-01 00:00:00 UTC), suivi d’une espace, puis le fuseau horaire en décalage par rapport à UTC (un + ou - avec quatre chiffres ; les deux premiers sont des heures, et les deux seconds des minutes), c’est-à-dire comme si l’horodatage était formaté avec strftime("%s %z")). Notez que l’option -local n’affecte pas la valeur des secondes depuis l’écho (qui est toujours mesurée en UTC), mais commute la valeur du fuseau horaire qui l’accompagne.
--date=human montre le fuseau horaire si le fuseau horaire ne correspond pas au fuseau horaire actuel, et n’affiche pas la date complète s’il y a correspondance (c’est-à-dire ne pas afficher l’année pour les dates qui sont "cette année", mais aussi sauter la date complète elle-même si elle est dans les derniers jours et que nous pouvons juste indiquer le jour de la semaine passée). Pour les dates plus anciennes, l’heure et la minute sont également omises.
--date=unix affiche la date sous forme d’un horodatage d’époque Unix (secondes depuis 1970). Comme dans le cas de --raw, c’est toujours en UTC et donc -local n’a aucun effet.
--date=format :... alimente le format ... vers strftime de votre système , sauf pour %s, %z et %Z, qui sont gérés en interne. Utilisez --date=format:%c pour afficher la date dans le format préféré de la locale de votre système. Voir le manuel de strftime pour une liste complète des espaces réservés de format. Quand on utilise -local, la syntaxe correcte est --date=format-local :....
--date=default est le format par défaut, et est basé sur la sortie de ctime(3). Il affiche une seule ligne avec le jour de la semaine à trois lettres, le mois à trois lettres, le jour du mois, l’heure, la minute et la seconde au format "HH:MM:SS", suivi de l’année à 4 chiffres, plus les informations du fuseau horaire, à moins que le fuseau horaire local ne soit utilisé, par exemple Thu Jan 1 00:00:00 1970 +0000.
Afficher le contenu du commit en format brut ; chaque enregistrement est séparé par un caractère NUL.
-Supprime la ligne d’en-tête contenant "commit" et l’ID de l’objet affiché avant le format spécifié. Ceci n’a aucun effet sur les formats intégrés ; seuls les formats personnalisés sont concernés.
-Remplacer un --no-commit-header précédent.
Afficher aussi les parents du commit (sous la forme "parent du commit…"). Permet également la réécriture des parents, voir " Simplification de l’historique " ci-dessus.
-Afficher aussi les enfants du commit (sous la forme "commit child…"). Permet également la réécriture des parents, voir " Simplification de l’historique " ci-dessus.
-Imprimer l’horodatage brut du commit.
-Indiquer de quel côté d’une différence symétrique un commit est accessible. Les commits de gauche sont préfixés par " < " et ceux de droite par " > ". Si on combine avec --boundary, ces commits sont préfixés par -.
Par exemple, si vous avez cette topologie :
-y---b---b branche B - / \ / - / . - / / \ - o---x---a---a branche A-
vous obtiendriez une sortie comme celle-ci :
-$ git rev-list --left-right --boundary --pretty=oneline A...B - - >bbbbbbb... 3rd on b - >bbbbbbb... 2nd on b - <aaaaaaa... 3rd on a - <aaaaaaa... 2nd on a - -yyyyyyy... 1st on b - -xxxxxxx... 1st on a-
Dessiner une représentation graphique en texte de l’historique du commit sur la gauche de la sortie. Cela peut entraîner l’impression de lignes supplémentaires entre les validations, afin que l’historique du graphique soit correctement tracé. Ne peut pas être combiné avec --no-walk.
Cela permet la réécriture des parents, voir « Simplification de l’historique » ci-dessus.
-Cela implique l’option --topo-order par défaut, mais l’option --date-order peut aussi être spécifiée.
Lorsque --graph n’est pas utilisé, toutes les branches de l’historique sont aplaties, ce qui peut rendre difficile de voir que les deux commits consécutifs n’appartiennent pas à une branche linéaire. Dans ce cas, cette option met une barrière entre les deux. Si <barrière> est spécifié, c’est la chaîne de caractères qui sera affichée à la place de celle par défaut.
Imprimer un nombre indiquant combien de commits auraient été listés, et supprimer toutes les autres sorties. Lorsqu’il est utilisé avec --left-right, imprimer à la place les comptes des commits gauche et droite, séparés par une tabulation. Lorsqu’utilisé avec --cherry-mark, omettre les commits équivalents de rustines de ces comptes et imprimer le compte des commits équivalents séparés par une tabulation.
Si le commit est une fusion, et si la mise en forme n’est pas oneline, email ou raw, une ligne supplémentaire est insérée avant la ligne Author:. Cette ligne commence par "Merge:" et les empreintes des commits ancêtres sont affichées, séparées par des espaces. Notez que les commits énumérés ne sont pas nécessairement la liste des commits parents directs si vous avez limité votre vue de l’historique : par exemple, si vous n’êtes intéressé que par les modifications liées à un certain répertoire ou fichier.
-Il existe plusieurs formats intégrés, et vous pouvez définir des formats supplémentaires en définissant une option pretty.<nom> config à soit un nouveau nom de format, soit une chaîne’format:', comme décrit ci-dessous (voir git-config[1]). Voici le détail des formats intégrés :
-oneline
-<empreinte> <ligne-de-titre>-
C’est conçu pour être aussi compact que possible.
-short
-commit <empreinte> -Author: <auteur>-
<ligne-de-titre>-
medium
-commit <empreinte> -Author: <auteur> -Date: <date d'auteur>-
<ligne-de-titre>-
<message-de-validation-complet>-
full
-commit <empreinte> -Author: <auteur> -Commit: <validateur>-
<ligne-de-titre>-
<message-de-validation-complet>-
fuller
-commit <empreinte> -Author: <auteur> -AuthorDate: <date d'auteur> -Commit: <validateur> -CommitDate: <date de validation>-
<ligne-de-titre>-
<message-de-validation-complet>-
reference
-<empreinte-abrégée> (<ligne-de-titre>, <date-d'auteur-courte>)-
Ce format est utilisé pour faire référence à un autre commit dans un message de validation et est le même que --pretty='format:%C(auto)%h (%s, %ad)'. Par défaut, la date est formatée avec --date=short à moins qu’une autre option --date ne soit explicitement spécifiée. Comme pour tout format: avec des espaces réservés de format, sa sortie n’est pas affectée par d’autres options comme --decorate et --walk-reflogs.
From <empreinte> <date> -From: <auteur> -Date: <date d'auteur> -Subject: [PATCH] <ligne de titre>-
<message-de-validation-complet>-
mboxrd
-Comme email, mais les lignes dans le message de validation commençant par "From" (précédé de zéro ou plus ">") sont citées avec ">" pour ne pas être confondues avec le début d’un nouveau commit.
-raw
-Le format’raw' montre le commit entier telle qu’elle est stockée dans l’objet commit. Notamment, les empreintes sont affichées dans leur intégralité, que --abbrev ou --no-abbrev soient utilisés ou non, et l’information parents indiquent le véritable commit parent, sans tenir compte des greffes ou de la simplification d’historique. Notez que ce format affecte la façon dont les commits sont affichés, mais pas la façon dont la différence est affichée, par exemple avec git log --raw. Pour obtenir les noms complets des objets dans un format de diff brut, utilisez --no-abbrev.
format:<chaîne-de-formatage>
-Le format format:<chaîne-de-formatage> vous permet de spécifier quelles informations vous voulez afficher. Cela fonctionne un peu comme le format printf, à l’exception notable que vous obtenez une nouvelle ligne avec'%n' au lieu de'\n'.
-Par exemple,format : "L’auteur de %h était %an, %ar%nL’entête était >>%s<<<%n" afficherait quelque chose comme ceci :
-L'auteur de fe6e0ee était Junio C Hamano, 23 hours ago -L'entête était >>t4119: test autocomputing -p<n> for traditional diff input.<<-
Les espaces réservés sont :
-Les places qui s’étendent à un seul caractère littéral :
- -Espaces réservés qui affectent le formatage des espaces réservés ultérieurs :
-passe la couleur au rouge
-passe la couleur au vert
-passe la couleur au bleu
-réinitialise la couleur
-spécification de couleur, telle que décrite sous Valeurs dans la section "FICHIER DE CONFIGURATION" de git-config[1]. Par défaut, les couleurs ne sont affichées que lorsqu’elles sont activées pour la sortie des journaux (par color.diff, color.ui, ou --color, et en respectant les paramètres auto du premier si nous allons sur un terminal). %C(auto,...) est accepté comme synonyme historique de la valeur par défaut (par exemple, %C(auto,red)). Spécifier %C(always,...) affichera les couleurs même si la couleur n’est pas activée autrement (bien qu’il faille toujours utiliser --color=always pour activer la couleur pour toute la sortie, y compris ce format et tout ce que git peut colorier). auto seul (c’est-à-dire %C(auto)) activera la coloration automatique sur les places suivantes jusqu’à ce que la couleur soit à nouveau changée.
marque à gauche (<), à droite (>) ou de limite (-)
basculer de rebouclage de ligne, comme l’option -w de git-shortlog[1].
-faire en sorte que l’espace réservé suivant prenne au moins N largeurs de colonne, en remplissant les espaces à droite si nécessaire. Tronquer éventuellement (avec points de suspension ..) à gauche (ltrunc) .. che, le milieu (mtrunc) mi.. eu, ou la droite (trunc) 'dr.. ', si la sortie est plus longue que N colonnes. Note 1 : cette troncation ne fonctionne correctement qu’avec N >= 2. Note 2 : les espaces autour des valeurs N et M (voir ci-dessous) sont facultatifs. Remarque 3 : Les emojis et autres caractères larges prendront deux colonnes d’affichage, ce qui peut dépasser les limites des colonnes. Note 4 : les marques de combinaison de caractères décomposés peuvent être mal placées au niveau des limites de rembourrage.
-faire en sorte que l’espace réservé suivant prenne au moins jusqu’à la Mième colonne d’affichage, en remplissant les espaces sur la droite si nécessaire. Utilisez des valeurs M négatives pour les positions de colonne mesurées à partir du bord droit de la fenêtre du terminal.
-similaire à %<( <N> ), %<|( <M> ) respectivement, mais les espaces d’alignement à gauche
-similaire à %>( <N> ), %>|( <M> ) respectivement, sauf que si le prochain espace réservé prend plus d’espaces que prévu et qu’il y a des espaces à sa gauche, utiliser ces espaces
-similaire à %<( <N> ), %<|( <M> ) respectivement, mais en décalant des deux côtés (c’est-à-dire que le texte est centré)
-Espaces réservés développant les informations extraites du commit :
-empreinte du commit
-empreinte abrégée du commit
-empreinte de l’arbre
-empreinte abrégée de l’arbre
-empreintes des parents
-empreintes abrégés des parents
-nom de l’auteur
-nom de l’auteur (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
-e-mail de l’auteur
-e-mail de l’auteur (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
-partie locale de l’e-mail de l’auteur (la partie avant le signe "@")
-partie locale de l’auteur (voir %al) en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
-date de l’auteur (le format respecte l’option --date=)
-date d’auteur, style RFC2822
-date de l’auteur, date relative
-date de l’auteur, horodatage UNIX
-date de création, format de type ISO 8601
-date d’auteur, format strict ISO 8601
-date d’auteur, format court (AAAA-MM-JJ)
date de l’auteur, style humain (comme l’option --date=human de git-rev-list[1])
nom du validateur
-nom du validateur (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
-e-mail du validateur
-e-mail du validateur (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
-partie locale de l’e-mail du validateur (la partie avant le signe "@")
-partie locale du validateur (voir %cl) en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
-date de validation (le format respecte l’option --date=)
-date de validation, style RFC2822
-date de validation, date relative
-date de validation, horodatage UNIX
-date de validation, format de type ISO 8601
-date de validation, format ISO 8601 strict
-date de validation, format court (AAAA-MM-JJ)
date du validateur, style humain (comme l’option --date=human de git-rev-list[1])
les noms de ref, comme l’option --decorate de git-log[1].
-les noms des refs, sans encadrement par « ( » et « ) ».
-noms de réfs avec des décorations personnalisées. La chaîne "decorate" peut être suivie de deux points et de zéro ou plus options séparées par des virgules. Les valeurs d’option peuvent contenir des codes de formatage litéraux. Ils doivent être utilisés pour les virgules (%x2C) et les parenthèses de fermeture (%x29), en raison de leur rôle dans la syntaxe optionnelle.
prefix=<valeur> : Affiché avant la liste des noms de réf. Valeur pas défaut " (".
suffix= <valeur> : affiché après la liste des noms réf. Valeur par défaut à ")".
separator=<valeur> : affiché entre les noms de réf. Valeur par défaut à ", ".
pointer=<valeur> : Affichage entre HEAD et la branche pointée, le cas échéant.
-Par défaut " -> ".
tag= <valeur> : Afficher avant les noms des étiquettes. par défaut "tag: ".
Par exemple, pour produire des décorations sans enveloppe ni étiquettes, et des espaces comme séparateurs :
-+
-%(decorate:prefix=,suffix=,tag=,separator= )
nom lisible par l’homme, comme git-describe[1] ; chaîne vide pour les commits non descriptibles. La chaîne describe peut être suivie de deux points et de zéro ou plusieurs options séparées par des virgules. Les descriptions peuvent être incohérentes lorsque des étiquettes sont ajoutées ou supprimées en même temps.
tags[=<valeur-booléenne>] : Au lieu de ne considérer que les étiquettes annotées, prendre également en compte les étiquettes légères.
-abbrev=<nombre> : Au lieu d’utiliser le nombre de chiffres hexadécimaux par défaut (qui varie en fonction du nombre d’objets dans le dépôt avec une valeur par défaut de 7) du nom d’objet abrégé, utiliser <nombre> chiffres, ou autant de chiffres que nécessaire pour former un nom unique.
-match=<motif> : Ne considère que les étiquettes correspondant au motif glob(7) donné, à l’exclusion du préfixe "refs/tags/".
exclude=<motif>' : Ne pas prendre en compte les étiquettes correspondant au motif glob(7) donné, en excluant le préfixe "refs/tags/".
nom de ref fourni en ligne de commande par lequel le commit a été atteint (comme git log --source), ne fonctionne qu’avec git log
encodage
-titre
-ligne de titre aseptisée, convenant pour un nom de fichier
-corps
-corps brut (sujet et corps non enveloppés)
-message de vérification brut de GPG pour un commit signé
-afficher "G" pour une bonne signature (valide), "B" pour une mauvaise signature, "U" pour une bonne signature avec une validité inconnue, "X" pour une bonne signature qui a expiré, "Y" pour une bonne signature faite par une clé expirée, "R" pour une bonne signature faite par une clé révoquée, "E" si la signature ne peut pas être vérifiée (par exemple la clé est manquante) et "N" pour aucune signature
-affiche le nom du signataire d’un commit signé
-afficher la clé utilisée pour signer un commit signé
-afficher l’empreinte digitale de la clé utilisée pour signer un commit signé
-afficher l’empreinte digitale de la clé primaire dont la sous-clé a été utilisée pour signer un commit signé
-afficher le niveau de rouille de la clé utilisée pour signer un commit signé
-sélecteur de reflog, p. ex., refs/stash@{1} ou refs/stash@{2 minutes ago} ; le format suit les règles décrites pour l’option -g. La partie avant @ est le nom de la référence tel qu’il est donné sur la ligne de commande (donc git log -g refs/heads/master produirait refs/heads/master@{0}).
sélecteur de reflog raccourci ; identique à %gD, mais la partie refname est raccourcie pour la lisibilité humaine (ainsi refs/heads/master devient simplement master).
nom de l’identité reflog
-nom de l’identité reflog (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
-adresse de courriel d’identité reflog
-e-mail de l’identité reflog (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
-titre du reflog
-afficher les lignes ajoutées du corps comme interprétées par git-interpret-trailers[1]. La chaîne trailers peut être suivie de deux-points et de zéro ou plus d’options séparées par des virgules. Si une option est fournie plusieurs fois, la dernière option l’emporte.
key=<clé>' : affiche uniquement les chaînes d’attributs avec la <clé> spécifiée. L’appariement se fait de façon insensible à la casse et la virgule finale est facultative. Si l’option est donnée plusieurs fois, les lignes d’attributs correspondant à l’une des clés sont affichées. Cette option active automatiquement l’option only de sorte que les lignes non-attribut dans le bloc d’attributs soient masquées. Si ce n’est pas désiré, ce peut être désactivé avec only=false. Par exemple, %(trailers:key=Reviewed-by) affiche les lignes d’attribut avec la clé Reviewed-by.
only [=<BOOLÉEN>]' : choisir si les lignes non annotées du bloc de lignes finales doivent être incluses.
-separator=<sep> : spécifie le séparateur inséré entre les lignes d’attributs. Par défaut, un caractère de saut de ligne. La chaîne <sep> peut contenir les codes de formatage littéral décrits ci-dessus. Pour utiliser la virgule comme séparateur, il faut utiliser %x2C car sinon elle serait analysée comme option suivante. Par exemple, %(trailers:key=Ticket,separator=%x2C ) affiche toutes les lignes d’attributs dont la clé est « Ticket » séparées par une virgule et un espace.
unfold[=<booléen>] : se comporter comme si l’option --unfold d’interprétation des attributs était donnée. Par exemple, %(trailers:only,unfold=true) déplie et affiche toutes les lignes d’attributs.
keyonly [=<booléen>] : ne montrer que la partie principale du bloc final.
-valueonly [=<booléen>] : n’affichez que la partie valeur des lignes finales.
-key_value_separator=<sep> : spécifier le séparateur inséré entre la clé et la valeur dans chaque ligne terminale. Par défaut " :". Sinon elle partage la même sémantique que separator=<sep> ci-dessus.
-|
- Note
- |
-
-Certains espaces réservés peuvent dépendre d’autres options données au moteur de traversée de révisions. Par exemple, les options de reflog %g* inséreront une chaîne vide à moins que nous ne traversions des entrées de reflog (par exemple, par git log -g). Les caractères de remplissage %d et %D utiliseront le format de décoration « short » si --decorate n’a pas déjà été fourni sur la ligne de commande.
- |
-
Les options booléennes acceptent une valeur optionnelle [=<booléen>]. Les valeurs true, false, on, off etc. sont toutes acceptées. Voir la sous-section "booléen" dans "EXEMPLES" dans git-config[1]. Si une option booléenne est donnée sans valeur, elle est activée.
Si vous ajoutez un + (signe plus) après'%' d’un espace réservé, un saut de ligne est inséré immédiatement avant l’expansion si et seulement si l’espace réservé se développe en une chaîne non vide.
Si vous ajoutez un - (signe moins) après'%' d’un caractère de remplissage, tous les sauts de ligne consécutifs précédant immédiatement l’expansion sont supprimés si et seulement si l’espace réservé se développe en une chaîne vide.
Si vous ajoutez un ‘`(espace) après’%' d’un espace réservé, un espace est inséré immédiatement avant l’expansion si et seulement si l’espace réservé se développe en une chaîne non vide.
-tformat:
-Le format’tformat:' fonctionne exactement comme’format:', sauf qu’il fournit une sémantique « terminator » au lieu de « separator ». En d’autres termes, chaque commit a le caractère de fin de message (habituellement une nouvelle ligne) ajouté, plutôt qu’un séparateur placé entre les entrées. Cela signifie que l’entrée finale d’un format à une ligne se terminera correctement par une nouvelle ligne, tout comme le format "oneline". Par exemple :
-$ git log -2 --pretty=format:%h 4da45bef \ - | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' -4da45be -7134973 -- NO NEWLINE - -$ git log -2 --pretty=tformat:%h 4da45bef \ - | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' -4da45be -7134973-
De plus, toute chaîne non reconnue qui contient un % est interprétée comme si elle avait tformat: devant elle. Par exemple, ces deux éléments sont équivalents :
$ git log -2 --pretty=tformat:%h 4da45bef -$ git log -2 --pretty=%h 4da45bef-
Fait partie de la suite git[1]
-Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .
-Dies ist ein Synonym für git-add[1]. Bitte lesen Sie die Dokumentation dieses Befehls.
-Teil der git[1] Suite
-git update-ref [-m <motivo>] [--no-deref] (-d <ref> [<valorantigo>] | [--create-reflog] <ref> <novovalor> [<valorantigo>] | --stdin [-z])-
Com dois argumentos, armazena o <novo-valor> na <ref>, possivelmente removendo as referências das referências simbólicas. Por exemplo, git update-ref HEAD <novo-valor> atualiza o cabeçalho do ramo atual para o novo objeto.
Com três argumentos, armazena o <novo-valor> na <ref>, possivelmente removendo a referência das referências simbólicas, após verificar se o valor atual da <ref> corresponde ao <valor-antigo>. Por exemplo, git update-ref refs/heads/master <novo-valor> <valor-antigo> atualiza o cabeçalho do ramo master para <novo-valor> somente se o seu valor atual for <valor-antigo>. Você pode especificar 40 "0" ou uma cadeia de caracteres vazia como <valor-antigo> para garantir que a referência que você está criando não exista.
Ele também permite que um arquivo "ref" seja um ponteiro simbólico para um outro arquivo "ref", iniciando com a sequência de quatro bytes do cabeçalho "ref:".
-Mais importante ainda, ele permite que a atualização de um arquivo de referência siga estes ponteiros simbólicos, sejam eles links simbólicos ou essas "referências simbólicas de arquivos regulares". Ele segue links simbólicos reais apenas se eles começarem com refs/: caso contrário, ele tentará lê-los e atualizá-los como um arquivo normal (ou seja, permitirá que o sistema de arquivos os siga, mas sobrescreverá esse link simbólico em outro lugar com um nome de arquivo normal).
-Caso a opção --no-deref seja utilizado, a própria <ref> será substituída, em vez do resultado de seguir os ponteiros simbólicos.
Em geral, utilizando
-git update-ref HEAD "$head"-
deve ser muito mais seguro do que fazer
-echo "$head" > "$GIT_DIR/HEAD"-
Tanto do ponto de vista do acompanhamento do link simbólico quanto do ponto de vista da verificação de erros. A regra "refs/" para os links simbólicos significa que os links simbólicos que apontam para "fora" da árvore são seguros: eles serão seguidos para leitura, mas não para gravação (portanto, nunca escreveremos por meio de um link simbólico de referência para outra árvore, se você tiver copiado um arquivo inteiro criando uma árvore de links simbólicos).
-Com a opção -d, exclui o nome <ref> após a verificação que ainda contenha o <valorantigo>.
Com a opção --stdin, o comando update-ref lê as instruções da entrada predefinida e executa todas as modificações juntas. Especifique os comandos do formulário:
update SP <ref> SP <novovalor> [SP <valorantigo>] LF -create SP <ref> SP <novovalor> LF -delete SP <ref> [SP <valorantigo>] LF -verify SP <ref> [SP <valorantigo>] LF -option SP <opt> LF -start LF -prepare LF -commit LF -abort LF-
Com a opção --create-reflog, o update-ref criará um reflog para cada "ref", mesmo que um não seja criado normalmente.
Cite os campos que contêm espaços em branco como se fossem strings no código-fonte C, ou seja, entre aspas duplas e com escapes de barra invertida. Use 40 caracteres "0" ou uma string vazia para especificar um valor zero. Para especificar um valor ausente, omita totalmente o valor e o SP anterior.
-Como alternativa, utilize a opção -z para definir no formato terminado por NUL, sem citar:
update SP <ref> NUL <novovalor> NUL [<valorantigo>] NUL -create SP <ref> NUL <novovalor> NUL -delete SP <ref> NUL [<valorantigo>] NUL -verify SP <ref> NUL [<valorantigo>] NUL -option SP <opt> NUL -start NUL -prepare NUL -commit NUL -abort NUL-
Neste formato, utilize 40 0 para definir um valor zero e utilize texto cazio para definir um valor ausente.
-Em ambos os formatos, os valores podem ser especificados em qualquer maneira que o Git reconheça como um nome de objeto. Comandos em qualquer outro formato ou um <ref> repetido geram um erro. Os significados dos comandos são:
-Defina <ref> como <novo-valor> após verificar <valor-antigo>, se fornecido. Especifique um <novo-valor> zero para garantir que a referência não exista após a atualização e/ou um <valor-antigo> zero para garantir que a referência não exista antes da atualização.
-Crie <ref> com <novo-valor> após verificar se ele não existe. O <novo-valor> fornecido não pode ser zero.
-Exclua <ref> após verificar se ela existe com <valor-antigo>, se fornecido. Se fornecido, <valor-antigo> pode não ser zero.
-Verifique <ref> em relação a <valor-antigo>, mas não o altere. Se <valor-antigo> for zero ou estiver ausente, a referência não deve existir.
-Modifica o comportamento do próximo comando que nomeia uma <ref>. A única opção válida é no-deref para evitar a referência a uma referência simbólica.
Inicie uma transação. Em contraste com uma sessão não transacionada, uma transação irá interromper automaticamente caso a cessão se encerre sem um commit explícito. Este comando pode criar uma nova transação vazia quando o commit tenha sido feito no atual ou já tenha sido cancelado.
-Prepare para transacionar o commit. Isto criará uma trava nos arquivos em todas as atualizações das referências que estiverem na fila. No caso de uma referência não puder ser travada, a transação irá ser encerrada.
-Faça o commit de todas as atualizações da referência na fila para a transação, finalizando a mesma.
-Interrompa a transação, liberando todos os bloqueios caso a transação esteja na condição de preparado.
-Se todas as <ref>s puderem ser bloqueadas com <valor-antigo>s correspondentes simultaneamente, todas as modificações serão executadas. Caso contrário, nenhuma modificação é realizada. Observe que, embora cada <ref> individual seja atualizado ou excluído atomicamente, um leitor simultâneo ainda pode ver um subconjunto das alterações.
-Se o parâmetro de configuração "core.logAllRefUpdates" for verdadeiro e o ref for um em refs/heads/, refs/remotes/, refs/notes/, ou um "pseudoref" como HEAD ou ORIG_HEAD; ou o arquivo $GIT_DIR/logs/<ref> existir, então o git update-ref anexará uma linha ao arquivo de registro $GIT_DIR/logs/<ref> (tirando a referência de todas as referências simbólicas antes de criar o nome do registro) descrevendo a alteração no valor da ref. As linhas de registro são formatadas como:
oldsha1 SP newsha1 SP committer LF-
Onde "sha1antigo" é o valor hexadecimal com 40 caracteres armazenado anteriormente na <ref>, o "novosha1" é o valor hexadecimal com 40 caracteres do <novovalor> e "committer" é o nome de quem fez o commit, o endereço de e-mail e a data no formato Git predefinido da identificação de quem faz o commit.
-Opcionalmente com -m:
oldsha1 SP newsha1 SP committer TAB message LF-
Onde todos os campos são como descritos acima e a "mensagem" é o valor informado para a opção -m.
-Uma atualização irá falhar (sem alterar a <ref>) caso o usuário atual não consiga criar um novo arquivo de registro log, anexá-lo ao arquivo log já existente ou caso não haja informações disponíveis.
-Parte do conjunto git[1]
-Creates a tree object using the current index. The name of the new tree object is printed to standard output.
-Der Index muss dafür in einem vollständig vereinigten Status sein.
-git write-tree sync()t den aktuellen Indexinhalt in eine Sammlung von Baumobjektdateien. Um eine Übereinstimmung mit dem momentanen eigentlichen Verzeichnisinhalt zu erhalten, muss zunächst git update-index ausgeführt werden, noch vor git write-tree.
-Normalerweise stellt git write-tree sicher, dass die durch das Verzeichnis referenzierten Objekte sich in der Objektdatenbank befinden. Diese Option deaktiviert diese Überprüfung.
-Erzeugt ein Baumobjekt, welches das Unterverzeichnis <Präfix> darstellt. Das kann verwendet werden, um das Baumobjekt für ein Unterprojekt in jenem Unterverzeichnis zu schreiben.
Teil der git[1] Suite
-git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>] - [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] - [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare] - [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] - [--super-prefix=<path>] [--config-env=<name>=<envvar>] - <command> [<args>]-
Git ist ein schnelles skalierbares verteiltes Versionskontrollsystem mit einem ungewöhnlich umfangreichen Befehlssatz, der sowohl hochrangige Operationen als auch vollen Zugriff auf interne Abläufe bietet.
-Siehe gittutorial[7] für den Einstieg und anschließend giteveryday[7] für einen nützlichen Mindestbefehlssatz. Das }}">Git-Nutzerhandbuch enthält eine tiefergehende Einführung.
-Wenn Sie die grundlegenden Konzepte verstanden haben, können Sie auf dieser Seite lernen, welche Befehle Git anbietet. Mit "git help <Befehl>" können Sie mehr über einzelne Git-Befehle erfahren. Die Handbuchseite gitcli[7] bietet Ihnen einen Überblick über die Befehlszeilen-Syntax.
-Eine HTML-Version der aktuellen Git-Dokumentation mit Formatierung und Verknüpfungen ist unter https://git.github.io/htmldocs/git.html oder https://git-scm.com/docs verfügbar.
-Gibt die Version der Git-Suite, aus der das git-Programm stammt, aus.
-This option is internally converted to git version ... and accepts the same options as the git-version[1] command. If --help is also given, it takes precedence over --version.
Gibt eine Übersicht und eine Liste der gebräuchlichsten Befehle aus. Wenn die Option --all oder -a angegeben wurde, werden alle verfügbaren Befehle ausgegeben. Falls der Name eines Git-Befehls angegeben wurde, wird die Handbuchseite für diesen Befehl geöffnet.
Zur Steuerung wie die Handbuchseite dargestellt wird sind andere Optionen verfügbar. Weitere Informationen finden Sie unter git-help[1], weil git --help ... intern in git help ... konvertiert wird.
Git ausführen, als ob Git in <Pfad> statt dem aktuellen Arbeitsverzeichnis gestartet wurde. Falls die Option -C mehrfach angegeben wurde, wird jeder nicht-absolute -C <Pfad> als relativ zum vorherigen -C <Pfad> interpretiert. Wenn <Pfad> existiert, aber leer ist (also -C ""), wird das aktuelle Arbeitsverzeichnis nicht verändert.
Diese Option beeinflusst andere Optionen, die Pfade erwarten, wie --git-dir`und `--work-tree, da ihre Pfade relativ zum Arbeitsverzeichnis, das über -C angegeben wurde, interpretiert werden. Die folgenden Aufrufe sind z.B. identisch:
git --git-dir=a.git --work-tree=b -C c status -git --git-dir=c/a.git --work-tree=c/b status-
Übergibt einen Konfigurationsparameter an den Befehl. Der übergebene Wert Überschreibt Werte aus Konfigurationsdateien. Der <Name> wird im gleichen Format erwartet, das von git config ausgegeben wird. (Unterschlüssel durch Punkte getrennt).
-Beachten Sie, dass das Weglassen des = in git -c foo.bar ... erlaubt ist und foo.bar auf true setzt (genau wie [foo]bar in einer Konfigurationsdatei). Ein Gleichheitszeichen ohne Wert (wie git -c foo.bar= ...) setzt foo.bar auf einen leeren String, den git config --type=bool in false konvertiert.
Like -c <name>=<value>, give configuration variable <name> a value, where <envvar> is the name of an environment variable from which to retrieve the value. Unlike -c there is no shortcut for directly setting the value to an empty string, instead the environment variable itself must be set to the empty string. It is an error if the <envvar> does not exist in the environment. <envvar> may not contain an equals sign to avoid ambiguity with <name> containing one.
This is useful for cases where you want to pass transitory configuration options to git, but are doing so on OS’s where other processes might be able to read your cmdline (e.g. /proc/self/cmdline), but not your environ (e.g. /proc/self/environ). That behavior is the default on Linux, but may not be on your system.
Note that this might add security for variables such as http.extraHeader where the sensitive information is part of the value, but not e.g. url.<base>.insteadOf where the sensitive information can be part of the key.
Installationspfad Ihrer Git-Programme. Dies kann auch durch Setzen der Umgebungsvariable GIT_EXEC_PATH. Wenn kein Pfad angegeben ist, gibt git die aktuelle Einstellung aus.
-Ausgabe des Pfads in dem Git’s HTML-Dokumentation installiert ist ohne abschließenden Schrägstrich.
-Ausgabe des Handbuchpfads (siehe man(1)) für die Handbuchseiten für diese Git-Version.
Ausgave des Pfads in dem die Info-Dateien die diese Git-Version dokumentieren installiert sind.
-Alle Ausgaben an less (oder, falls gesetzt $PAGER) weiterleiten, falls die Standard-Ausgabe ein terminal ist. Dies setzt sich über die pager.<cmd> Konfigurationsoptionen hinweg (siehe Abschnitt "Configuration Mechanism" weiter unten).
Git-Ausgaben nicht an einen Pager weiterleiten.
-Set the path to the repository (".git" directory). This can also be controlled by setting the GIT_DIR environment variable. It can be an absolute path or relative path to current working directory.
Specifying the location of the ".git" directory using this option (or GIT_DIR environment variable) turns off the repository discovery that tries to find a directory with ".git" subdirectory (which is how the repository and the top-level of the working tree are discovered), and tells Git that you are at the top level of the working tree. If you are not at the top-level directory of the working tree, you should tell Git where the top-level of the working tree is, with the --work-tree=<path> option (or GIT_WORK_TREE environment variable)
If you just want to run git as if it was started in <path> then use git -C <path>.
Set the path to the working tree. It can be an absolute path or a path relative to the current working directory. This can also be controlled by setting the GIT_WORK_TREE environment variable and the core.worktree configuration variable (see core.worktree in git-config[1] for a more detailed discussion).
-Setzt den Git Namespace. Siehe gitnamespaces[7] für weitere Details. Dies entspricht dem Setzen der Umgebungsvariable GIT_NAMESPACE.
Currently for internal use only. Set a prefix which gives a path from above a repository down to its root. One use is to give submodules context about the superproject that invoked it.
-Das Repository als Bare-Repository behandeln. Wenn die Umgebungsvariable GIT_DIR nicht gestezt ist, wird sie auf das aktuelle Arbeitsverzeichnis gesetzt.
-Do not use replacement refs to replace Git objects. See git-replace[1] for more information.
-Pfadspezifikationen buchstäblich (d.h. kein Globbing, keine Pfadspezifikationsangaben) behandeln. Dies entspricht dem Setzen der Umgebungsvariable GIT_LITERAL_PATHSPECS auf 1.
Fügt die Pfadspezifikationsangabe "glob" zu allen Pfadspezifikationen hinzu. Dies entspricht dem Setzen der Umgebungsvariable GIT_GLOB_PATHSPECS auf 1. Globbing kann für einzelne Pfadspezifikationen mit der Pfadspezifikationsangabe ":(literal)" deaktiviert werden
Fügt die Pfadspezifikationsangabe "literal" zu allen Pfadspezifikationen hinzu. Dies entspricht dem Setzen der Umgebungsvariable GIT_NOGLOB_PATHSPECS auf 1. Globbing kann für einzelne Pfadspezifikationen mit der Pfadspezifikationsangabe ":(glob)" aktiviert werden
Fügt die Pfadspezifikationsangabe "icase" zu allen Pfadspezifikationen hinzu. Dies entspricht dem Setzen der Umgebungsvariable GIT_ICASE_PATHSPECS auf 1.
Führt keine optionalen Operationen durch, die Sperren erfordern. Dies entspricht dem Setzen von GIT_OPTIONAL_LOCKS auf 0.
Befehle nach Gruppe auflisten. Dies ist eine interne/experimentelle Option und könnte in zukunft geändert oder entfernt werden. Unterstützt folgende Gruppen: builtins (Integrierte Befehle), parseopt (Integrierte Befehle, die Parse-Optionen verwenden), main (Alle Befehle im Verzeichnis libexec), others (Alle anderen Befehle in $PATH mit Präfix git-), list-<Kategorie> (siehe Kategorien in command-list.txt), nohelpers (Hilfsbefehle ausschließen), alias and config (Befehlsliste aus Konfigurationsvariable completion.commands)
Wir unterteilen Git in hochrangige Befehle ("Porcelain") und Systembefehle ("Plumbing").
-Wir unterteilen "Porcelain"-Befehle in Hauptbefehle und zusätzliche Benutzerwerkzeuge.
-Füge Dateiinhalte zum Index hinzu.
-Eine Serie von Patches von einer Mailbox anwenden.
-Dateiarchiv von angegebenem Verzeichnis erstellen.
-Binärsuche verwenden, um den Commit zu finden, der einen Fehler verursacht hat.
-Branches anzeigen, erstellen oder entfernen.
-Objekte und Referenzen über ein Archiv verteilen.
-Branches wechseln oder Dateien im Arbeitsverzeichnis wiederherstellen.
-Änderungen eines existierenden Commits anwenden.
-Graphische Alternative zu git-commit.
-Unversionierte Dateien vom Arbeitsverzeichnis entfernen.
-Ein Repository in einem neuen Verzeichnis klonen.
-Änderungen in das Repository eintragen.
-Einem Objekt einen für Menschen lesbaren Namen basierend auf einer verfügbaren Referenz geben.
-Änderungen zwischen Commits, Commit und Arbeitsverzeichnis, etc. anzeigen.
-Objekte und Referenzen von einem anderen Repository herunterladen.
-Patches für E-Mail-Versand vorbereiten.
-Nicht benötigte Dateien entfernen und das lokale Repository optimieren.
-Zeilen darstellen, die einem Muster entsprechen.
-Eine portable grafische Schnittstelle zu Git.
-Ein leeres Git-Repository erstellen oder ein bestehendes neuinitialisieren.
-Commit-Historie anzeigen.
-Run tasks to optimize Git repository data.
-Zwei oder mehr Entwicklungszweige zusammenführen.
-Eine Datei, ein Verzeichnis oder einen Symlink verschieben oder umbenennen.
-Objekt-Notizen hinzufügen oder überprüfen.
-Objekte von einem externen Repository anfordern und sie mit einem anderen Repository oder einem lokalen Branch zusammenführen.
-Remote-Referenzen mitsamt den verbundenen Objekten aktualisieren.
-Vergleiche zwei Commit-Bereiche (z.B. zwei Versionen eines Branches).
-Wiederholtes Anwenden von Commits auf anderem Basis-Commit.
-Aktuellen HEAD zu einem spezifizierten Zustand setzen.
-Dateien im Arbeitsverzeichnis wiederherstellen.
-Einige bestehende Commits rückgängig machen.
-Dateien aus dem Arbeitsverzeichnis und dem Index löschen.
-Ausgabe von git log zusammenfassen.
-Verschiedene Arten von Objekten anzeigen.
-Reduce your working tree to a subset of tracked files.
-Änderungen in einem Arbeitsverzeichnis aufbewahren.
-Den Zustand des Arbeitsverzeichnisses anzeigen.
-Submodule initialisieren, aktualisieren oder inspizieren.
-Branches wechseln.
-Ein mit GPG signiertes Tag-Objekt erzeugen, auflisten, löschen oder verifizieren.
-Mehrere Arbeitsverzeichnisse verwalten.
-Der Git-Repository-Browser.
-A tool for managing large Git repositories.
-Manipulatoren:
-Repositoryweite oder globale Optionen lesen und setzen.
-Export-Tool für Git-Daten.
-Backend für schnelle Git-Datenimport-Tools.
-Branches umschreiben.
-Ausführen von Tools zur Auflösung von Merge-Konflikten zur Behebung dieser.
-Branches und Tags für effizienten Zugriff auf das Repository packen.
-Alle nicht erreichbaren Objekte von der Objektdatenbank entfernen.
-Reflog-Informationen verwalten.
-Low-level access to refs.
-Einen Satz entfernter Repositories verwalten.
-Ungepackte Objekte in einem Repository packen.
-Referenzen für ersetzende Objekte erstellen, auflisten, löschen.
-Abfragen:
-Zeilen der Datei mit Commit-Informationen versehen und anzeigen.
-Anzeigen, durch welchen Commit und Autor die jeweiligen Zeilen einer Datei zuletzt geändert wurden.
-Collect information for user to file a bug report.
-Anzahl und Speicherverbrauch ungepackter Objekte zählen.
-Generate a zip archive of diagnostic information.
-Änderungen mittels den allgemeinen Diff-Tools anzeigen.
-Stellt die Verbundenheit und Gültigkeit der Objekte in der Datenbank sicher.
-Hilfsinformationen über Git anzeigen.
-Ihr aktuelles Repository sofort in gitweb betrachten.
-Perform merge without touching index or working tree.
-Aufgezeichnete Auflösung von Merge-Konflikten wiederverwenden.
-Branches und ihre Commits ausgeben.
-Die GPG-Signatur von Commits prüfen.
-Die GPG-Signatur von Tags prüfen.
-Display version information about Git.
-Show logs with differences each commit introduces.
-Git Web Interface (Web-Frontend für Git-Repositories).
-Diese Befehle dienen zum Interagieren mit fremden Versionsverwalungen oder mit anderen Personen über Patch per E-Mail.
-Ein GNU-Arch-Repository in Git importieren.
-Einzelnen Commit zu einem ausgecheckten CVS-Repository exportieren.
-Ihre Daten aus einem anderen SCM übernehmen.
-Ein CVS-Server-Emulator für Git.
-Eine Sammlung von Patches von der Standard-Eingabe an einen IMAP-Ordner senden.
-Repositories aus Perforce importieren und an diese senden.
-Patches aus quilt auf aktuellen Branch anwenden.
-Eine Übersicht über ausstehende Änderungen generieren.
-Eine Sammlung von Patches als E-Mails versenden.
-Bidirektionale Operationen zwischen einem Subversion-Repository und Git.
-There are three commands with similar names: git reset, git restore and git revert.
git-revert[1] is about making a new commit that reverts the changes made by other commits.
-git-restore[1] is about restoring files in the working tree from either the index or another commit. This command does not update your branch. The command can also be used to restore files in the index from another commit.
-git-reset[1] is about updating your branch, moving the tip in order to add or remove commits from the branch. This operation changes the commit history.
-git reset can also be used to restore the index, overlapping with git restore.
Auch wenn Git eigene hochrangige Befehle enthält, reichen die Systembefehle aus, um alternative hochrangige Befehle zu entwickeln. Entwickler solcher Befehle sollten sich zum Einstieg in git-update-index[1] und git-read-tree[1] einlesen.
-Die Schnittstelle (Eingaben, Ausgaben, verfügbare Optionen und Semantik) zu diesen Systembefehlen sollen viel stabiler als "Porcelain"-Befehle sein, da sie hauptsächlich zum Gebrauch in Skripten vorgesehen sind. Bei der Schnittstelle zu "Porcelain"-Befehlen sind dagegen Änderungen zur Verbesserung der Benutzerfreundlichkeit vorbehalten.
-Im folgenden Text werden die Systembefehle unterteilt in Befehle um Objekte (in the repository, index, and working tree) zu manipulieren, Befehle um Objekte abzufragen und zu vergleichen und Befehle um Objekte und Referenzen zwischen Repositories zu übertragen.
-Einen Patch auf Dateien und/oder den Index anwenden.
-Dateien von dem Index ins Arbeitsverzeichnis kopieren.
-Schreibe und verifiziere Git-Commit-Graph-Dateien.
-Ein neues Commit-Objekt erstellen.
-Compute object ID and optionally create an object from a file.
-Pack-Index-Datei für ein existierendes gepacktes Archiv erzeugen.
-Einen 3-Wege-Datei-Merge ausführen.
-Einen Merge für zusammenzuführende Dateien ausführen.
-Creates a tag object with extra validation.
-Tree-Objekt aus ls-tree formattiertem Text erzeugen.
-Schreibe und verifiziere Multipackindizes.
-Ein gepacktes Archiv von Objekten erstellen.
-Zusätzliche Objekte, die sich bereits in Paketdateien befinden, entfernen.
-Verzeichnisinformationen in den Index einlesen.
-EXPERIMENTAL: Replay commits on a new base, works with bare repos too.
-Symbolische Referenzen lesen, ändern und löschen.
-Objekte aus einem gepackten Archiv entpacken.
-Dateiinhalte aus dem Arbeitsverzeichnis im Index registrieren.
-Den Objektnamen, der in einer Referenz gespeichert ist, sicher aktualisieren.
-Tree-Objekt vom aktuellen Index erstellen.
-Provide contents or details of repository objects.
-Commits finden, die noch auf dem Upstream-Branch angewendet werden müssen.
-Dateien von dem Arbeitsverzeichnis und dem Index vergleichen.
-Ein Verzeichnis von dem Arbeitsverzeichnis und dem Index vergleichen.
-Den Inhalt und Modus von Blobs aus zwei Verzeichnisobjekten vergleichen.
-Informationen für jede Referenz ausgeben.
-Run a Git command on a list of repositories.
-Commit-ID eines Archivs extrahieren, welches mit git-archive erstellt wurde.
-Informationen über Dateien in dem Index und im Arbeitsverzeichnis anzeigen.
-Referenzen in einem Remote-Repository auflisten.
-Inhalte eines Tree-Objektes auflisten.
-Bestmöglichen gemeinsamen Vorgänger-Commit für einen Merge finden.
-Symbolische Namen für die gegebenen Commits finden.
-Redundante Paketdateien finden.
-Commit-Objekte chronologisch absteigend sortiert auflisten.
-Parameter herauspicken und ändern.
-Gepackten Archiv-Index anzeigen.
-Referenzen in einem lokalen Repository auflisten.
-Eine temporäre Datei mit den Inhalten eines Blobs erstellen.
-Eine logische Variable von Git anzeigen.
-Gepackte Git-Archivdateien validieren.
-Abfragebefehle verändern im Allgemeinen keine Dateien im Arbeitsverzeichnis.
-Ein wirklich einfacher Server für Git Repositories.
-Fehlende Objekte von einem anderen Repository empfangen.
-Serverseitige Implementierung von Git über HTTP.
-Objekte über das Git Protokoll zu einem anderen Repository übertragen.
-Hilfsinformationsdatei zur Hilfe von einfachen Servern aktualisieren.
-Die folgenden Befehle sind Hilfsbefehle für die oben genannten Befehle; Endbenutzer rufen sie normalerweise nicht direkt auf.
-Von einem Remote-Git-Repository über HTTP herunterladen.
-Objekte über HTTP/DAV zu einem anderen Repository übertragen.
-Empfangen was in das Repository übertragen wurde.
-Login-Shell beschränkt für Nur-Git SSH-Zugriff.
-Archiv zurück zu git-archive senden.
-Objekte gepackt zurück an git-fetch-pack senden.
-Diese Befehle sind Hilfsbefehle für die andere Befehle; Endbenutzer rufen sie normalerweise nicht direkt auf.
-gitattributes-Informationen darstellen.
-Fehlersuche in gitignore- / exclude-Dateien.
-Name und E-Mail-Adresse von Kontakten anzeigen.
-Sicherstellen, dass ein Referenzname wohlgeformt ist.
-Daten in Spalten anzeigen.
-Zugangsdaten des Benutzers abrufen und speichern.
-Hilfsprogramm zum temporären Speichern von Zugangsdaten im Hauptspeicher.
-Hilfsprogramm zum Speichern von Zugangsdaten auf der Festplatte.
-Beschreibung eines Merge-Commits erzeugen.
-Run git hooks.
-Strukturierte Informationen in Commit-Beschreibungen hinzufügen oder parsen.
-Patch und Urheberschaft aus einer einzelnen E-Mail-Nachricht extrahieren.
-Einfaches UNIX mbox Splitter-Programm.
-Das Standard-Hilfsprogramm für die Verwendung mit git-merge-index.
-Eindeutige ID für einen Patch berechnen.
-Git’s i18n-Konfigurationscode für Shell-Skripte.
-Allgemeiner Git Shell-Skript Konfigurationscode.
-Nicht erforderlichen Whitespace entfernen.
-The following documentation pages are guides about Git concepts.
-|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
This documentation discusses repository and command interfaces which users are expected to interact with directly. See --user-formats in git-help[1] for more details on the critera.
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
This documentation discusses file formats, over-the-wire protocols and other git developer interfaces. See --developer-interfaces in git-help[1].
|
- Warning
- |
-
-
-
-Missing
-
-See original version for this content. - |
-
Git nutzt ein einfaches Textformat um Einstellungen pro Benutzer und Repository zu speichern. So eine Konfigurationsdatei kann wie folgt aussehen:
-# -# Eine Raute '#' oder ein Semikolon ';' markiert # einen Kommentar. -# - -; Kernvariablen -[core] - ; den Dateimodi nicht vertrauen - filemode = false - -; Identät des Nutzers -[user] - name = "Junio C Hamano" - email = "gitster@pobox.com"-
Verschiedene Git-Befehle lesen die Konfigurationsdatei und passen ihr Verhalten entsprechend an. Siehe git-config[1] für eine Liste der Optionen und mehr Details über den Konfigurationsmechanismus.
-Bezeichnet den Namen eines Objekts beliebigen Typs.
-Bezeichnet den Namen eines Blob-Objekts.
-Bezeichnet den Namen eines Tree-Objekts.
-Bezeichnet den Namen eines Commit-Objekts.
-Bezeichnet den Namen eines Tree-, Commit- oder Markierungs-Objekts. Ein Befehl, der eine <Commit-Referenz> als Argument akzeptiert arbeitet letztendlich mit einem <Tree>-Objekt, dereferenziert aber auch automatisch <Commit>- und <Markierung>-Objekte, die auf einen <Tree> verweisen.
-Bezeichnet den Namen eines Commit- oder Markierungs-Objekts. Ein Befehl, der eine <Commit-Angabe> als Argument akzeptiert arbeitet letztendlich mit einem <Commit>-Objekt, dereferenziert aber auch automatisch <Markierung>-Objekte, die auf einen <Commit> verweisen.
-Gibt an, dass eine Objekt-Art benötigt wird. Momentan sind möglich: blob, tree, commit oder tag (Markierung).
Bezeichnet einen Dateinamen, der fast immer relativ zur Verzeichnisstruktur in GIT_INDEX_FILE ist.
Jeder Git-Befehl der ein beliebiges <Objekt> akzeptiert kann auch die folgende symbolische Notation verwenden:
-Für eine umfänglichere Auflistung wie Objektbezeichnungen angegeben werden können siehe den Abschnitt "REVISIONEN ANGEBEN" in gitrevisions[7].
-Siehe das Dokument gitrepository-layout[5].
-Lesen Sie githooks[5] für mehr Details über die einzelnen Hooks.
-Übergeordnete SCMs können zusätzliche Informationen im $GIT_DIR bereitstellen und verwalten.
Siehe gitglossary[7].
-Verschiedene Git-Befehle benutzen die folgenden Umgebungsvariablen:
-These environment variables apply to all core Git commands. Nb: it is worth noting that they may be used/overridden by SCMS sitting above Git so take care if using a foreign front-end.
-GIT_INDEX_FILE Diese Umgebungsvariable erlaubt es eine alternative Indexdatei anzugeben. Andernfalls wird die Standarddatei $GIT_DIR/index verwendet.
GIT_INDEX_VERSION Mit dieser Umgebungsvariable kann die Indexversion für neue Repositories. Dies hat keine Auswirkung auf bestehende Indexdateien. Standardmäßig wird Indexversion 2 oder 3 verwendet. Siehe git-update-index[1] für weitere Informationen.
-GIT_OBJECT_DIRECTORY Wenn das Objektverzeichnis über diese Umgebungsvariable angegeben wird werden die SHA1-Verzeichnisse darunter angelegt, ansonsten wird standardmäßig Das Verzeichnis`$GIT_DIR/objects` verwendet.
-GIT_ALTERNATE_OBJECT_DIRECTORIES Durch die unveränderliche Natur von Git-Objekten können alte Objekte in gemeinsame schreibgeschützte Verzeichnisse archiviert werden. Diese Variable gibt eine mit ":" (";" unter Windows) getrennte Liste von Objektverzeichnissen, in denen nach Git-Objekten gesucht werden kann, an. Neue Objekte werden nicht in diese Verzeichnisse geschrieben.
-Einträge, die mit " (doppelten Anführungszeichen) beginnen werden wie Zeichenketten in C interpretiert, d.h. führende und abschließende doppelte Anführungszeichen werden entfernt und Rückwärtsschrägstrich-basierte Escape-Sequenzen werden respektiert. D.h. der Wert "Pfad-mit-\"-und-:-im-Pfad":Standard-Pfad enthält zwei Pfade: "Pfad-mit-"-und-:-im-Pfad und Standard-Pfad.
GIT_DIR Wenn die Umgebungsvariable GIT_DIR gesetzt ist, gibt sie den Pfad an, der statt .git als Basis des Repositories verwendet wird. Die Befehlszeilenoption --git-dir setzt diesen Wert auch.
GIT_WORK_TREE Set the path to the root of the working tree. This can also be controlled by the --work-tree command-line option and the core.worktree configuration variable.
GIT_NAMESPACE Setzt den Git Namespace; Siehe gitnamespaces[7] für Details. Die Befehlszeilenoption --namespace setzt diesen Wert auch.
GIT_CEILING_DIRECTORIES This should be a colon-separated list of absolute paths. If set, it is a list of directories that Git should not chdir up into while looking for a repository directory (useful for excluding slow-loading network directories). It will not exclude the current working directory or a GIT_DIR set on the command line or in the environment. Normally, Git has to read the entries in this list and resolve any symlink that might be present in order to compare them with the current directory. However, if even this access is slow, you can add an empty entry to the list to tell Git that the subsequent entries are not symlinks and needn’t be resolved; e.g., GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.
GIT_DISCOVERY_ACROSS_FILESYSTEM When run in a directory that does not have ".git" repository directory, Git tries to find such a directory in the parent directories to find the top of the working tree, but by default it does not cross filesystem boundaries. This environment variable can be set to true to tell Git not to stop at filesystem boundaries. Like GIT_CEILING_DIRECTORIES, this will not affect an explicit repository directory set via GIT_DIR or on the command line.
GIT_COMMON_DIR Wenn diese Variable einen Pfad enthält, werden nicht-Arbeitsverzeichnis-Dateien, die sich normalerweise in $GIT_DIR befinden stattdessen aus diesem Verzeichnis geladen. Arbeitsverzeichnis-spezifische Dateien wie HEAD oder index werden aus $GIT_DIR geladen. Siehe gitrepository-layout[5] und git-worktree[1] für Details. Andere Pfadvariablen wie GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY, etc. haben Vorrang gegenüber dieser Variable.
-GIT_DEFAULT_HASH If this variable is set, the default hash algorithm for new repositories will be set to this value. This value is currently ignored when cloning; the setting of the remote repository is used instead. The default is "sha1". THIS VARIABLE IS EXPERIMENTAL! See --object-format in git-init[1].
GIT_AUTHOR_NAME The human-readable name used in the author identity when creating commit or tag objects, or when writing reflogs. Overrides the user.name and author.name configuration settings.
GIT_AUTHOR_EMAIL The email address used in the author identity when creating commit or tag objects, or when writing reflogs. Overrides the user.email and author.email configuration settings.
GIT_AUTHOR_DATE The date used for the author identity when creating commit or tag objects, or when writing reflogs. See git-commit[1] for valid formats.
-GIT_COMMITTER_NAME The human-readable name used in the committer identity when creating commit or tag objects, or when writing reflogs. Overrides the user.name and committer.name configuration settings.
GIT_COMMITTER_EMAIL The email address used in the author identity when creating commit or tag objects, or when writing reflogs. Overrides the user.email and committer.email configuration settings.
GIT_COMMITTER_DATE The date used for the committer identity when creating commit or tag objects, or when writing reflogs. See git-commit[1] for valid formats.
-EMAIL The email address used in the author and committer identities if no other relevant environment variable or configuration setting has been set.
-GIT_DIFF_OPTS Die einziegen gültigen Werte sind "--unified=??" oder "-u??" um die Anzahl der angezeigten Kontextzeilen zu steuern, wenn ein vereinheitlichtes Diff erstellt wird. Dies hat Vorrang vor jeglichen auf der Kommandozeile an git diff übergebenen Werten der Optionen "-U" oder "--unified".
-GIT_EXTERNAL_DIFF When the environment variable GIT_EXTERNAL_DIFF is set, the program named by it is called to generate diffs, and Git does not use its builtin diff machinery. For a path that is added, removed, or modified, GIT_EXTERNAL_DIFF is called with 7 parameters:
Pfad alte-Datei alter-Hash alte-Rechte neue-Datei neuer-Hash neue-Rechte-
wobei:
-are files GIT_EXTERNAL_DIFF can use to read the contents of <old|new>,
-die 40-stelligen hexadezimalen Hashes sind,
-die oktale Representation der Datei-Rechte sind.
-Die Dateiparameter können auf die Arbeitsdatei des Benutzers (z.B. neue-Datei in "git-diff-files"), /dev/null (z.B. alte-Datei wenn eine neue Datei hinzugefügt wird) oder eine temporäre Datei (z.B. alte-Datei im Index) verweisen. GIT_EXTERNAL_DIFF muss sich nicht damit befassen die temporäre Datei zu löschen. --- sie wird entfernt sobald GIT_EXTERNAL_DIFF beendet wird.
Für einen nicht zusammengeführten Pfad wird GIT_EXTERNAL_DIFF mit einem Parameter, <Pfad>, aufgerufen.
Für jeden Pfad mit dem GIT_EXTERNAL_DIFF aufgerufen wird, werden die beiden Umgebungsvariablen GIT_DIFF_PATH_COUNTER und GIT_DIFF_PATH_TOTAL gesetzt.
GIT_DIFF_PATH_COUNTER Ein 1-basierter Zähler, der für jeden Pfad um eins inkrementiert wird.
-GIT_DIFF_PATH_TOTAL Die Gesamtanzahl Pfade.
-GIT_MERGE_VERBOSITY Eine numerische Angabe, die Ausgabemenge der rekursiven Merge-Strategie steuert. Überschreibt merge.verbosity. Siehe git-merge[1]
-GIT_PAGER Diese Umgebungsvariable überschreibt $PAGER. Wenn sie auf eine leere Zeichenkette oder "cat" gesetzt ist, startet Git keinen Pager. Siehe auch die Option core.pager in git-config[1].
GIT_PROGRESS_DELAY A number controlling how many seconds to delay before showing optional progress indicators. Defaults to 2.
-GIT_EDITOR Diese Umgebungsvariable überschreibt $EDITOR und $VISUAL. Sie wird von mehreren Git-Befehlen verwendet, um im interaktiven Modus einen Editor zu öffnen. Siehe auch git-var[1] und die Option core.editor in git-config[1].
GIT_SEQUENCE_EDITOR This environment variable overrides the configured Git editor when editing the todo list of an interactive rebase. See also git-rebase[1] and the sequence.editor option in git-config[1].
GIT_SSH GIT_SSH_COMMAND Wenn eine dieser Umgebungsvariablen gesetzt ist, verwenden git fetch und git push den angegebenen Befehl statt ssh zum Verbinden mit entfernten Systemen. Die Kommandozeilenparameter die dem konfigurierten Befehl übergeben werden, richten sich nach der SSH-Varinate. Siehe die Option ssh.variant in git-config[1] für Details.
$GIT_SSH_COMMAND hat Vorrang über $GIT_SSH und wird von der Shell interpretiert, daher können zusätzliche Argumente mit angegeben werden. GIT_SSH dagegen darf nur den Pfad zu einem Programm enthalten (dieses kann ein Wrapper-Shell-Script sein, falls zusätzliche Argumente benötigt werden).
Meistens ist es einfacher die gewünschten Optionen über Ihre persönliche .shh/config-Datei zu konfigurieren. Bitte konsultieren Sie Ihre SSH-Dokumentation für weitere Details.
GIT_SSH_VARIANT Wenn diese Umgebungsvariable gesetzt ist, überschreibt sie Git’s automatische Erkennung ob sich GIT_SSH/GIT_SSH_COMMAND/core.sshCommand auf OpenSSH, plink oder tortoiseplink bezieht. Diese Variable überschreibt sie die Konfigurationseinstellung ssh.variant die den selben Zweck erfüllt.
GIT_ASKPASS Wenn diese Umgebungsvariable gesetzt ist, rufen Git-Befehle die Passwörter benötigten (z.B. für HTTP- oder IMAP-Authentifizierung) dieses Programm mit geeigneten Kommandozeilenparametern auf und lesen das Passwort von seiner Standardausgabe. Siehe auch die Option core.askPass in git-config[1].
GIT_TERMINAL_PROMPT Wenn diese Umgebungsvariable auf 0 gesetzt ist, fragt Git nicht nach Eingaben im Terminal (z.B. zur HTTP-Authentifizierung).
GIT_CONFIG_GLOBAL GIT_CONFIG_SYSTEM Take the configuration from the given files instead from global or system-level configuration files. If GIT_CONFIG_SYSTEM is set, the system config file defined at build time (usually /etc/gitconfig) will not be read. Likewise, if GIT_CONFIG_GLOBAL is set, neither $HOME/.gitconfig nor $XDG_CONFIG_HOME/git/config will be read. Can be set to /dev/null to skip reading configuration files of the respective level.
GIT_CONFIG_NOSYSTEM Gibt an, ob das Auslesen der Systemweiten Konfigurationsdatei $(prefix)/etc/gitconfig übersprungen wird. Diese Umgebungsvariable kann in Kombination mit $HOME und $XDG_CONFIG_HOME genutzt werden um eine reproduzierbare Umgebung für ein Skript herzustellen oder um eine fehlerhafte /etc/gitconfig-Datei vorübergehend zu vermeiden, während man auf jemanden mit den nötigen Berechtigungen um die Fehler zu beheben wartet.
GIT_FLUSH Wenn diese Umgebungsvariable auf 1 gesetzt ist, erzwingen Befehle -wie git blame (im inkrementellen Modus),git rev-list,git log, -git check-attr und git check-ignore ein Leeren des -Ausgabestroms nach jedem Datensatz. Wenn diese -Variable auf "0" gesetzt ist, wird die Ausgabe dieser Befehle mit -vollständig gepuffertem I/O durchgeführt. Wenn diese -Umgebungsvariable nicht gesetzt ist, wählt Git zwischen gepufferter -oder datensatzbasierter Ausgabe basierend darauf, ob stdout in eine -Datei umgeleitet zu sein scheint oder nicht.
-GIT_TRACE Aktiviert allgemeine Ablaufverfolgungsmeldungen, z.B.. Alias-Erweiterung, Ausführung von eingebauten und externen Befehlen.
-Wenn diese Variable auf "1", "2" oder "true" (Vergleich ist unabhängig von Groß-/Kleinschreibung) gesetzt ist, werden Ablaufverfolgungsmeldungen nach stderr ausgegeben.
-Wenn dieser Variable ein ganzzahliger Wert größer als 2 und kleiner als 10 zugewiesen ist, interpretiert Git diesen Wert als geöffneten Datei-Handle und versucht die Ablaufverfolgungsmeldungen in diese Datei zu schreiben.
-Alternativ kann diese Variable auf einen absoluten Pfad (beginnt mit einem /), schreibt Git die Ablaufverfolgungsmeldungen in diese Datei.
-Zurücksetzen der Variable oder setzen auf einen leeren Wert, "0" oder "false" (unabhängig von Groß-/Kleinschreibung) deaktiviert Ablaufverfolgungsmeldungen.
-GIT_TRACE_FSMONITOR Aktiviert Ablaufverfolgungsmeldungen für die Dateisystemmonitor-Erweiterung. Siehe GIT_TRACE? für verfügbare Ausgabemöglichkeiten.
GIT_TRACE_PACK_ACCESS Aktiviert Ablaufverfolgungsmeldungen für Zugriffe auf Pakete. Für jeden Zugriff werden der Name der Paketdatei und ein Offset im Paket aufgezeichnet. Dies kann bei der Fehlersuche bei packetbezogenen Performance-Problemen hilfreich sein. Siehe GIT_TRACE für verfügbare Ablaufverfolgungsoptionen.
GIT_TRACE_PACKET Aktiviert Ablaufverfolgungsmeldungen für alle Pakete, die in und aus einem bestimmten Programm kommen. Dies kann bei der Suche nach Problemen mit der Objektaushandlung oder anderen protokollbezogenen Problemen. Die Ablaufverfolgung wird bei Packeten, die mit pack beginnen deaktiviert (Siehe hierzu GIT_TRACE_PACKFILE). Siehe GIT_TRACE für verfügbare Ablaufverfolgungsoptionen.
GIT_TRACE_PACKFILE Aktiviert die Ablaufverfolgung von gesendeten und empfangenen Packdateien eines bestimmten Programms. Im Gegensatz zu anderen Ablaufverfolgungsmeldungen ist diese Ablaufverfolgung wortgetreu: Keine Kopfzeilen und keine Umwandlung von binären Daten. Sie wollen diese Daten höchstwahrscheinlich in eine Datei umleiten (z.B. GIT_TRACE_PACKFILE=/tmp/my.pack), statt sie auf die Konsole auszugeben oder mit anderen Ablaufverfolgungsmeldungen zu vermischen.
Dies ist momentan nur für die Client-Seite der Befehle clone und fetch implementiert.
-GIT_TRACE_PERFORMANCE Aktiviert performancebezogene Ablaufverfolgungsmeldungen, z.B. gesamte Ausführunszeit jedes Git-Befehls. Siehe GIT_TRACE für verfügbare Ablaufverfolgungsoptionen.
GIT_TRACE_REFS Enables trace messages for operations on the ref database. See GIT_TRACE for available trace output options.
GIT_TRACE_SETUP Enables trace messages printing the .git, working tree and current working directory after Git has completed its setup phase. See GIT_TRACE for available trace output options.
GIT_TRACE_SHALLOW Aktiviert Ablaufverfolgungsmeldungen die zur Fehlersuche beim Anfordern (fetching)/Klonen von Repositories mit unvollständiger Historie (shallow) helfen können. Siehe GIT_TRACE für verfügbare Ablaufverfolgungsoptionen.
GIT_TRACE_CURL Enables a curl full trace dump of all incoming and outgoing data, including descriptive information, of the git transport protocol. This is similar to doing curl --trace-ascii on the command line. See GIT_TRACE for available trace output options.
GIT_TRACE_CURL_NO_DATA Falls Curl-Ablaufverfolgung aktiviert ist (sieh GIT_TRACE_CURL oben), keine Nutzdaten, sondern nur Header und Info-Zeilen ausgegeben.
GIT_TRACE2 Enables more detailed trace messages from the "trace2" library. Output from GIT_TRACE2 is a simple text-based format for human readability.
Wenn diese Variable auf "1", "2" oder "true" (Vergleich ist unabhängig von Groß-/Kleinschreibung) gesetzt ist, werden Ablaufverfolgungsmeldungen nach stderr ausgegeben.
-Wenn dieser Variable ein ganzzahliger Wert größer als 2 und kleiner als 10 zugewiesen ist, interpretiert Git diesen Wert als geöffneten Datei-Handle und versucht die Ablaufverfolgungsmeldungen in diese Datei zu schreiben.
-Alternativ kann diese Variable auf einen absoluten Pfad (beginnt mit einem /), schreibt Git die Ablaufverfolgungsmeldungen in diese Datei. Falls der Pfad ein existierendes Verzeichnis ist, werden die Ablaufverfolgungsmeldungen in Dateien (eine pro Prozess), benannt nach dem letzten Teils der SID und einem optionalen Zähler (um Datienamenskollisionen zu vermeiden), in diesem Verzeichnis geschrieben.
-In addition, if the variable is set to af_unix:[<socket_type>:]<absolute-pathname>, Git will try to open the path as a Unix Domain Socket. The socket type can be either stream or dgram.
Zurücksetzen der Variable oder setzen auf einen leeren Wert, "0" oder "false" (unabhängig von Groß-/Kleinschreibung) deaktiviert Ablaufverfolgungsmeldungen.
-See }}">Trace2 documentation for full details.
-GIT_TRACE2_EVENT This setting writes a JSON-based format that is suited for machine interpretation. See GIT_TRACE2 for available trace output options and }}">Trace2 documentation for full details.
GIT_TRACE2_PERF In addition to the text-based messages available in GIT_TRACE2, this setting writes a column-based format for understanding nesting regions. See GIT_TRACE2 for available trace output options and }}">Trace2 documentation for full details.
GIT_TRACE_REDACT By default, when tracing is activated, Git redacts the values of cookies, the "Authorization:" header, the "Proxy-Authorization:" header and packfile URIs. Set this variable to 0 to prevent this redaction.
GIT_LITERAL_PATHSPECS Das Setzen dieser Variable auf 1 veranlasst Git alle Pfadspezifikationen buchstäblich und nicht als Glob-Muster zu interpreieren. Zum Beispiel sucht GIT_LITERAL_PATHSPECS=1 git log -- '*.c' nach Commits, die den Pfad *.c verrändern, nicht nach Dateien, die das Muster *.c betrifft. Das kann gewollt sein, wenn tatsächliche Pfade an Git übergeben werden (z.B. Pfade die von git ls-tree ausgegeben wurden oder aus Diffausgaben mit --raw o.ä. stammen).
GIT_GLOB_PATHSPECS Das Setzen dieser Variable auf 1 veranlasst Git alle Pfadspezifikationen als Glob-Muster zu behandeln (Pfadspezifikationsangabe "glob").
-GIT_NOGLOB_PATHSPECS Das Setzen dieser Variable auf 1 veranlasst Git alle Pfadspezifikationen buchstäblich zu interpreieren (Pfadspezifikationsangabe "literal").
-GIT_ICASE_PATHSPECS Das Setzen dieser Variable auf 1 veranlasst Git bei allen Pfadspezifikationen Groß- und Kleinschreibung zu ignorieren.
-GIT_REFLOG_ACTION Wenn eine Referenz aktualisiert wird, werden Reflog-Einträge erstellt, um den Grund, dass die Referenz aktualisiert wurde (üblicherweise ist das die Bezeichnung des hochrangigen Befehls, der die Referenz aktualisiert hat), sowie den alten und neuen Wert der Referenz nachvollziehen zu können. Geskriptete Porcelain-Befehle können die Hilfsfunktion set_reflog_action in git-sh-setup um ihren Namen in diese Variable einzutragen, wenn sie vom Endbenutzer als Befehl der obersten Ebene aufgerufen werden, damit dieser im Reflog festgehalten wird.
GIT_REF_PARANOIA If set to 0, ignore broken or badly named refs when iterating over lists of refs. Normally Git will try to include any such refs, which may cause some operations to fail. This is usually preferable, as potentially destructive operations (e.g., git-prune[1]) are better off aborting rather than ignoring broken refs (and thus considering the history they point to as not worth saving). The default value is 1 (i.e., be paranoid about detecting and aborting all operations). You should not normally need to set this to 0, but it may be useful when trying to salvage data from a corrupted repository.
GIT_ALLOW_PROTOCOL If set to a colon-separated list of protocols, behave as if protocol.allow is set to never, and each of the listed protocols has protocol.<name>.allow set to always (overriding any existing configuration). See the description of protocol.allow in git-config[1] for more details.
GIT_PROTOCOL_FROM_USER Set to 0 to prevent protocols used by fetch/push/clone which are configured to the user state. This is useful to restrict recursive submodule initialization from an untrusted repository or for programs which feed potentially-untrusted URLS to git commands. See git-config[1] for more details.
GIT_PROTOCOL Nur zum internen Gebrauch. Wird beim Handshake des Git Wire Protokolls verwendet. Enthält eine durch Doppelpunkte : getrennte Liste von Schlüsseln mit optionalen Werten schlüssel[=wert]. Unbekannte Schlüssel und Werte müssen ignoriert werden.
-Note that servers may need to be configured to allow this variable to pass over some transports. It will be propagated automatically when accessing local repositories (i.e., file:// or a filesystem path), as well as over the git:// protocol. For git-over-http, it should work automatically in most configurations, but see the discussion in git-http-backend[1]. For git-over-ssh, the ssh server may need to be configured to allow clients to pass this variable (e.g., by using AcceptEnv GIT_PROTOCOL with OpenSSH).
This configuration is optional. If the variable is not propagated, then clients will fall back to the original "v0" protocol (but may miss out on some performance improvements or features). This variable currently only affects clones and fetches; it is not yet used for pushes (but may be in the future).
-GIT_OPTIONAL_LOCKS If set to 0, Git will complete any requested operation without performing any optional sub-operations that require taking a lock. For example, this will prevent git status from refreshing the index as a side effect. This is useful for processes running in the background which do not want to cause lock contention with other operations on the repository. Defaults to 1.
GIT_REDIRECT_STDIN GIT_REDIRECT_STDOUT GIT_REDIRECT_STDERR Nur unter Windows: Erlaubt es die Standardeingabe/-ausgabe/-fehlerausgabe auf die in diesen Umgebungsvariablen angegebenen Pfade umzuleiten. Dies ist besonders hilfreich bei Multithreading-Anwendungen bei denen die Standardmethode diese Datenströme mit CreateProcess() keine Option ist, da das bewirken würde, dass alle weiteren Prozesse diese erben, was reguläre Git-Operationen blockieren kann. Der Hauptanwendungsfall ist die Verwendung von benannten Pipes (z.B. \\.\pipe\my-git-stdin-123).
Es werden zwei besondere Werte unterstützt: off deaktiviert den entsprechenden Standarddatenstrom und wenn GIT_REDIRECT_STDERR auf 2>&1 gesetzt ist wird die Standardfehlerausgabe in den selben Strom wie die Standardausgabe geleitet.
GIT_PRINT_SHA1_ELLIPSIS (veraltet) If set to yes, print an ellipsis following an (abbreviated) SHA-1 value. This affects indications of detached HEADs (git-checkout[1]) and the raw diff output (git-diff[1]). Printing an ellipsis in the cases mentioned is no longer considered adequate and support for it is likely to be removed in the foreseeable future (along with the variable).
Mehr Details zum den folgenden Themen sind im }}">Kapitel "Git concepts" des Benutzerhandbuchs und unter gitcore-tutorial[7] verfügbar.
-Ein Git-Projekt besteht normalerweise aus einem Arbeitsverzeichnis mit einem „.git“-Unterverzeichnis auf der obersten Ebene. Das „.git“-Verzeichnis enthält unter anderem eine komprimierte Objektdatenbank, die den vollständigen Projektverlauf wiedergibt, eine „Index“-Datei, die diesen Verlauf mit dem aktuellen Inhalt des Arbeitsbereichs verknüpft und Pointer in diesem Verlauf benennt, wie z.B. Tags und Branch-Heads.
-Die Objektdatenbank enthält drei Hauptarten von Objekten: Blobs, die Dateiinformationen enthalten; Trees, die auf Blobs und andere Trees verweisen, um Verzeichnisstrukturen abzubilden; und Commits, die jeweils auf einen einzelnen Tree und eine gewisse Anzahl Eltern-Commits verweisen.
-Der Commit, in anderen Systemen auch „Changeset“ oder „Version“ genannt, stellt einen Schritt in der Projekthistorie dar und jeder Eltern-Commit stellt einen direkt vorhergehenden Schritt dar. Commits mit mehr als einem Eltern-Commit stellen Zusammenführungen verschiedener Entwicklungslinien dar.
-Alle Objekte werden mit dem SHA1-Hash ihres Inhalts bezeichnet. Dieser wird normalerweise als 40-stellige Hexadezimalzahl angegeben. Diese Bezeichnungen sind eindeutig. Ein einzelner signierter Commit kann die gesamte Historie bis zu diesem Commit verifizieren. Zu diesem Zweck wird eine vierte Objektart, die Markierung angeboten.
-Beim Erstellen werden Objekte in individuellen Dateien gespeichert, können aber aus Effizienzgründen später zusammen in sogenannten Packdateien komprimiert werden.
-Benannte Zeiger, die Referenzen genannt werden, markieren interessante Punkte in der Historie. Eine Referenz kann auf ein Objekt oder eine andere Referenz verweisen. Referenzen deren Bezeichnung mit ref/head/ beginnt enthalten die SHA1-Bezeichnung de letzten Commits (der „Spitze“) eines Entwicklungszweigs. SHA1-Bezeichnungen interessanter Markierungen werden unter ref/tags/ gespeichert. Eine besondere Referenz namens HEAD verweist auf die Bezeichnung des momnentan ausgecheckten Entwicklungszweigs.
Die Indexdatei wird mit einer Liste aller Pfade, sowie pro Pfad einem Blob-Objekt und einer Reihe von Attributen initialisiert. Das Blob-Objekt repräsentiert die Inhalte der Datei gemäß der Spitze des aktuellen Entwicklungszweigs. Die Attribute (zuletzt geändert, Größe, etc.) werden von der entsprechenden Datei im Arbeitsverzeichnis genommen. Spätere Änderungen am Arbeitsverzeichnis können durch Vergleichen dieser Attribute ermittelt werden. Der Index kann mit neuen Inhalten aktualisiert werden und aus dem Inhalt des Indexes können neue Commits erstellt werden.
-Der Index kann auch mehrere Einträge (genannt „Stages“) eines bestimmten Pfads enthalten. Diese Stages enthalten verschiedene noch nicht zusammengeführte Versionen einer Datei während eines Merges.
-Siehe die Verweise im Abschnitt „Beschreibung“ um mit der Verwendung von Git zu beginnen. Nachfolgend finden Sie vermutlich mehr Details als es für einen erstmaligen Benutzer nötig ist.
-Das }}">Kapitel „Git concepts“ des Benutzerhandbuchs und gitcore-tutorial[7] stellen eine Einführung in die zugrundeliegende Git-Architektur zur Verfügung.
-Siehe gitworkflows[7] für eine Übersicht über empfohlene Arbeitsabläufe.
-In den }}">Howto-Dokumenten finden Sie nützliche Beispiele.
-Die Interna sind in der }}">Git-API-Dokumentation dokumentiert.
-Für Benutzer, die von CVS migrieren könnte auch gitcvs-migration[7] interessant sein.
-Git wurde ursprünglich von Linus Torvalds geschrieben und wird jetzt von Junio C Hamano weitergeführt. Zahlreiche Beiträge sind über die Git-E-Mail-Verteilerliste <git@vger.kernel.org> entstanden. Unter http://www.openhub.net/p/git/contributors/summary steht eine etwas vollständigere Liste der Mitwirkenden bereit.
-Wenn sie einen Klon von git.git haben, können Sie sich mit git-shortlog[1] und git-blame[1] die Urheber einzelner Projektteile anzeigen lassen.
-Report bugs to the Git mailing list <git@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there. See the list archive at https://lore.kernel.org/git for previous bug reports and other discussions.
-Sicherheitsrelevante Fehler sollten vetraulich an die Git-Sicherheits-E-Mail-Verteilerliste <git-security@googlegroups.com> gemeldet werden.
-Teil der git[1] Suite
-