English ▾ Themen ▾ Neueste Version ▾ git-pull zuletzt aktualisiert in 2.52.0

NAME

git-pull - Holen und Integrieren von einem anderen Repository oder einem lokalen Branch

SYNOPSIS

git pull [<options>] [<repository> [<refspec>…​]]

BESCHREIBUNG

Integrieren Sie Änderungen aus einem Remote-Repository in den aktuellen Branch.

Zuerst führt git pull git fetch mit denselben Argumenten (ohne Merge-Optionen) aus, um Remote-Branches zu holen. Dann entscheidet es, welcher Remote-Branch integriert werden soll: Wenn Sie git pull ohne Argumente ausführen, wird standardmäßig der Upstream des aktuellen Branches verwendet. Dann integriert es diesen Branch in den aktuellen Branch.

Es gibt 4 Hauptoptionen für die Integration des Remote-Branches

  1. git pull --ff-only führt nur "fast-forward"-Updates durch: es schlägt fehl, wenn sich Ihr lokaler Branch vom Remote-Branch abweicht. Dies ist die Standardeinstellung.

  2. git pull --rebase führt git rebase aus

  3. git pull --no-rebase führt git merge aus.

  4. git pull --squash führt git merge --squash aus

Sie können auch die Konfigurationsoptionen pull.rebase, pull.squash oder pull.ff mit Ihrem bevorzugten Verhalten einstellen.

Wenn es während des Merges oder Rebase zu einem Merge-Konflikt kommt, den Sie nicht handhaben möchten, können Sie diesen sicher mit git merge --abort oder git --rebase abort abbrechen.

OPTIONEN

<repository>

Das "Remote"-Repository, von dem geholt werden soll. Dies kann entweder eine URL sein (siehe Abschnitt GIT URLS unten) oder der Name eines Remotes (siehe Abschnitt REMOTES unten).

Standardmäßig der konfigurierte Upstream für den aktuellen Branch oder origin. Weitere Informationen zur Konfiguration von Upstreams finden Sie unter UPSTREAM BRANCHES.

<refspec>

Welchen Branch oder welche Referenzen sollen geholt und in den aktuellen Branch integriert werden, z. B. main in git pull origin main. Standardmäßig der konfigurierte Upstream für den aktuellen Branch.

Dies kann ein Branch, ein Tag oder eine andere Sammlung von Referenzen sein. Die vollständige Syntax finden Sie unter <refspec> unten unter "Optionen im Zusammenhang mit dem Holen" und wie git pull dieses Argument zur Bestimmung des zu integrierenden Remote-Branches verwendet, finden Sie unter STANDARDVERHALTEN.

-q
--quiet

Dies wird sowohl an das zugrundeliegende git-fetch übergeben, um die Berichterstattung während der Übertragung zu unterdrücken, als auch an das zugrundeliegende git-merge, um die Ausgabe während des Merges zu unterdrücken.

-v
--verbose

Übergeben Sie --verbose an git-fetch und git-merge.

--recurse-submodules[=(yes|on-demand|no)]
--no-recurse-submodules

Diese Option steuert, ob neue Commits von populierten Submodulen geholt werden sollen und ob auch die Arbeitskopien aktiver Submodule aktualisiert werden sollen (siehe git-fetch[1], git-config[1] und gitmodules[5]).

Wenn der Checkout per Rebase erfolgt, werden auch lokale Submodul-Commits neu angeordnet.

Wenn das Update per Merge erfolgt, werden die Submodul-Konflikte aufgelöst und ausgecheckt.

Optionen im Zusammenhang mit dem Mergen

--commit
--no-commit

Führen Sie den Merge durch und committen Sie das Ergebnis. Diese Option kann verwendet werden, um --no-commit zu überschreiben. Nur nützlich beim Mergen.

Mit --no-commit führen Sie den Merge durch und stoppen kurz vor dem Erstellen eines Merge-Commits, um dem Benutzer die Möglichkeit zu geben, das Merge-Ergebnis zu überprüfen und weiter zu bearbeiten, bevor er committet.

Beachten Sie, dass Fast-Forward-Updates keinen Merge-Commit erstellen und daher keine Möglichkeit besteht, diese Merges mit --no-commit zu stoppen. Wenn Sie also sicherstellen möchten, dass Ihr Branch durch den Merge-Befehl nicht verändert oder aktualisiert wird, verwenden Sie --no-ff mit --no-commit.

--edit
-e
--no-edit

Rufen Sie einen Editor auf, bevor ein erfolgreicher mechanischer Merge committet wird, um die automatisch generierte Merge-Nachricht weiter zu bearbeiten, damit der Benutzer den Merge erklären und rechtfertigen kann. Die Option --no-edit kann verwendet werden, um die automatisch generierte Nachricht zu akzeptieren (dies wird generell nicht empfohlen).

Ältere Skripte können vom historischen Verhalten abhängen, das dem Benutzer nicht erlaubt, die Merge-Log-Nachricht zu bearbeiten. Sie werden sehen, dass ein Editor geöffnet wird, wenn sie git merge ausführen. Um die Anpassung solcher Skripte an das aktualisierte Verhalten zu erleichtern, kann die Umgebungsvariable GIT_MERGE_AUTOEDIT zu Beginn auf no gesetzt werden.

--cleanup=<mode>

Diese Option bestimmt, wie die Merge-Nachricht vor dem Committen bereinigt wird. Weitere Details finden Sie unter git-commit[1]. Wenn der <mode> den Wert scissors erhält, werden Scheren an MERGE_MSG angehängt, bevor sie im Falle eines Merge-Konflikts an die Commit-Maschinerie weitergeleitet werden.

--ff-only

Aktualisieren Sie die neue Historie nur, wenn keine abweichende lokale Historie vorhanden ist. Dies ist die Standardeinstellung, wenn keine Methode zur Auflösung abweichender Historien angegeben wird (über die --rebase=* Flags).

--ff
--no-ff

Beim Mergen anstelle von Rebasen wird angegeben, wie ein Merge behandelt wird, wenn die eingehende Historie bereits ein Nachkomme der aktuellen Historie ist. Wenn Mergen angefordert wird, ist --ff die Standardeinstellung, es sei denn, es wird ein annotierter (und möglicherweise signierter) Tag gemergt, der sich nicht an seinem natürlichen Ort in der refs/tags/ Hierarchie befindet. In diesem Fall wird --no-ff angenommen.

Mit --ff wird, wenn möglich, der Merge als Fast-Forward aufgelöst (nur der Branch-Zeiger wird angepasst, um dem gemergten Branch zu entsprechen; es wird kein Merge-Commit erstellt). Wenn dies nicht möglich ist (wenn die eingehende Historie kein Nachkomme der aktuellen Historie ist), wird ein Merge-Commit erstellt.

Mit --no-ff wird in allen Fällen ein Merge-Commit erstellt, auch wenn der Merge stattdessen als Fast-Forward aufgelöst werden könnte.

-S[<key-id>]
--gpg-sign[=<key-id>]
--no-gpg-sign

Signieren Sie den resultierenden Merge-Commit mit GPG. Das Argument <key-id> ist optional und hat standardmäßig die Kommentator-Identität; wenn es angegeben wird, muss es ohne Leerzeichen am Optionsnamen angehängt werden. --no-gpg-sign ist nützlich, um sowohl die Konfigurationsvariable commit.gpgSign als auch ein früheres --gpg-sign zu überschreiben.

--log[=<n>]
--no-log

Fügen Sie zusätzlich zu den Branch-Namen Einzeilen-Beschreibungen von höchstens <n> tatsächlich gemergten Commits in die Log-Nachricht ein. Siehe auch git-fmt-merge-msg[1]. Nur nützlich beim Mergen.

Mit --no-log werden keine Einzeilen-Beschreibungen der tatsächlich gemergten Commits aufgeführt.

--signoff
--no-signoff

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

Die Option --no-signoff kann verwendet werden, um eine frühere Option --signoff auf der Kommandozeile zu widerrufen.

--stat
-n
--no-stat

Zeigen Sie am Ende des Merges eine Diff-Statistik an. Die Diff-Statistik wird auch durch die Konfigurationsoption merge.stat gesteuert.

Mit -n oder --no-stat wird am Ende des Merges keine Diff-Statistik angezeigt.

--compact-summary

Zeigen Sie am Ende des Merges eine kompakte Zusammenfassung an.

--squash
--no-squash

Erzeugt den Arbeitsbaum und den Index-Zustand, als ob ein echter Merge stattgefunden hätte (außer der Merge-Informationen), committet aber nicht tatsächlich, verschiebt HEAD nicht und zeichnet $GIT_DIR/MERGE_HEAD nicht auf (um zu bewirken, dass der nächste git commit Befehl einen Merge-Commit erstellt). Dies ermöglicht es Ihnen, einen einzelnen Commit auf dem aktuellen Branch zu erstellen, dessen Auswirkung dieselbe ist wie das Mergen eines anderen Branches (oder mehr im Falle eines Oktopus).

Mit --no-squash wird der Merge durchgeführt und das Ergebnis committet. Diese Option kann verwendet werden, um --squash zu überschreiben.

Mit --squash ist --commit nicht erlaubt und führt zu einem Fehler.

Nur nützlich beim Mergen.

--verify
--no-verify

Standardmäßig werden die Pre-Merge- und Commit-Msg-Hooks ausgeführt. Wenn --no-verify angegeben wird, werden diese umgangen. Siehe auch githooks[5]. Nur nützlich beim Mergen.

-s <strategy>
--strategy=<strategy>

Verwenden Sie die angegebene Merge-Strategie; kann mehrmals angegeben werden, um sie in der Reihenfolge anzugeben, in der sie versucht werden sollen. Wenn keine -s Option angegeben ist, wird stattdessen eine vordefinierte Liste von Strategien verwendet (ort beim Mergen eines einzelnen Heads, octopus andernfalls).

-X <option>
--strategy-option=<option>

Übergeben Sie strategie-spezifische Optionen an die Merge-Strategie.

--verify-signatures
--no-verify-signatures

Überprüfen Sie, ob der Tip-Commit des zu mergenden Seiten-Branches mit einem gültigen Schlüssel signiert ist, d.h. einem Schlüssel mit einer gültigen UID: im Standard-Vertrauensmodell wurde der Signierschlüssel von einem vertrauenswürdigen Schlüssel signiert. Wenn der Tip-Commit des Seiten-Branches nicht mit einem gültigen Schlüssel signiert ist, wird der Merge abgebrochen.

Nur nützlich beim Mergen.

--summary
--no-summary

Synonyme für --stat und --no-stat; diese sind veraltet und werden in Zukunft entfernt.

--autostash
--no-autostash

Erzeugt automatisch einen temporären Stash-Eintrag, bevor die Operation beginnt, speichert ihn in der Referenz MERGE_AUTOSTASH und wendet ihn nach Abschluss der Operation an. Das bedeutet, dass Sie die Operation auf einem unsauberen Arbeitsbaum ausführen können. Seien Sie jedoch vorsichtig: die abschließende Anwendung des Stashes nach einem erfolgreichen Merge kann zu nicht-trivialen Konflikten führen.

--allow-unrelated-histories

Standardmäßig lehnt der Befehl git merge das Mergen von Historien ab, die keinen gemeinsamen Vorfahren teilen. Diese Option kann verwendet werden, um diese Sicherheitsmaßnahme beim Mergen von Historien zweier Projekte zu umgehen, die ihr Leben unabhängig voneinander begonnen haben. Da dies ein sehr seltener Fall ist, existiert keine Konfigurationsvariable, um dies standardmäßig zu aktivieren, und wird auch keine hinzugefügt.

Nur nützlich beim Mergen.

-r
--rebase[=(false|true|merges|interactive)]

Wenn true, wird der aktuelle Branch nach dem Holen auf den Upstream-Branch neu angeordnet. Wenn es einen Remote-Tracking-Branch gibt, der dem Upstream-Branch entspricht, und der Upstream-Branch seit dem letzten Holen neu angeordnet wurde, verwendet die Neuordnung diese Informationen, um die Neuordnung nicht-lokaler Änderungen zu vermeiden.

Wenn auf merges gesetzt, erfolgt die Neuordnung mit git rebase --rebase-merges, sodass die lokalen Merge-Commits in die Neuordnung einbezogen werden (siehe git-rebase[1] für Details).

Wenn false, wird der Upstream-Branch in den aktuellen Branch gemergt.

Wenn interactive, wird der interaktive Modus von Rebase aktiviert.

Siehe pull.rebase, branch.<name>.rebase und branch.autoSetupRebase in git-config[1], wenn Sie möchten, dass git pull immer --rebase anstelle von Mergen verwendet.

Hinweis
 Dies ist ein potenziell *gefährlicher* Betriebsmodus. Er schreibt die Historie neu, was nicht gut ist, wenn Sie diese Historie bereits veröffentlicht haben. Verwenden Sie diese Option *nicht*, es sei denn, Sie haben git-rebase[1] sorgfältig gelesen.
--no-rebase

Dies ist eine Kurzform für --rebase=false.

Optionen im Zusammenhang mit dem Holen

--all
--no-all

Holen Sie alle Remotes, außer denen, bei denen die Konfigurationsvariable remote.<name>.skipFetchAll gesetzt ist. Dies überschreibt die Konfigurationsvariable fetch.all.

-a
--append

Hängen Sie Referenznamen und Objekt-Namen der geholten Referenzen an den vorhandenen Inhalt von .git/FETCH_HEAD an. Ohne diese Option werden alte Daten in .git/FETCH_HEAD überschrieben.

--atomic

Verwenden Sie eine atomare Transaktion, um lokale Referenzen zu aktualisieren. Entweder werden alle Referenzen aktualisiert oder im Fehlerfall werden keine Referenzen aktualisiert.

--depth=<depth>

Begrenzen Sie das Holen auf die angegebene Anzahl von Commits von der Spitze jedes Remote-Branches. Wenn in ein *flaches* Repository geholt wird, das mit der Option git clone --depth=<depth> erstellt wurde (siehe git-clone[1]), vertiefen oder verkürzen Sie die Historie auf die angegebene Anzahl von Commits. Tags für die vertieften Commits werden nicht geholt.

--deepen=<depth>

Ähnlich wie --depth, gibt jedoch die Anzahl der Commits von der aktuellen flachen Grenze anstelle von der Spitze jedes Remote-Branches an.

--shallow-since=<date>

Vertieft oder verkürzt die Historie eines flachen Repositorys, um alle erreichbaren Commits nach <datum> einzuschließen.

--shallow-exclude=<ref>

Vertieft oder verkürzt die Historie eines flachen Repositorys, um Commits auszuschließen, die von einem angegebenen Remote-Branch oder Tag erreichbar sind. Diese Option kann mehrfach angegeben werden.

--unshallow

Wenn das Quell-Repository vollständig ist, konvertieren Sie ein flaches Repository in ein vollständiges und entfernen Sie alle Einschränkungen, die von flachen Repositories auferlegt werden.

Wenn das Quell-Repository flach ist, holen Sie so viel wie möglich, sodass das aktuelle Repository dieselbe Historie wie das Quell-Repository hat.

--update-shallow

Standardmäßig weigert sich git fetch beim Holen aus einem flachen Repository, Referenzen zu holen, die eine Aktualisierung von .git/shallow erfordern. Diese Option aktualisiert .git/shallow und akzeptiert solche Referenzen.

--negotiation-tip=<commit|glob>

Standardmäßig berichtet Git dem Server Commits, die von allen lokalen Referenzen erreichbar sind, um gemeinsame Commits zu finden und so die Größe des zu empfangenden Packfiles zu reduzieren. Wenn angegeben, berichtet Git nur von den Commits, die von den angegebenen Spitzen erreichbar sind. Dies ist nützlich, um Fetches zu beschleunigen, wenn der Benutzer weiß, welche lokale Referenz wahrscheinlich gemeinsame Commits mit der geholten Upstream-Referenz hat.

Diese Option kann mehrfach angegeben werden; in diesem Fall berichtet Git von den Commits, die von einem der angegebenen Commits erreichbar sind.

Das Argument dieser Option kann ein Glob für Referenznamen, eine Referenz oder die (möglicherweise abgekürzte) SHA-1 eines Commits sein. Die Angabe eines Globs entspricht der mehrfachen Angabe dieser Option, eine für jeden übereinstimmenden Referenznamen.

Siehe auch die Konfigurationsvariablen fetch.negotiationAlgorithm und push.negotiate, die in git-config[1] dokumentiert sind, sowie die Option --negotiate-only unten.

--negotiate-only

Holen Sie nichts vom Server und drucken Sie stattdessen die Vorfahren der angegebenen --negotiation-tip=* Argumente aus, die wir mit dem Server gemeinsam haben.

Dies ist inkompatibel mit --recurse-submodules=[yes|on-demand]. Intern wird dies zur Implementierung der Option push.negotiate verwendet. Siehe git-config[1].

--dry-run

Zeigen Sie, was getan würde, ohne Änderungen vorzunehmen.

--porcelain

Druckt die Ausgabe zur Standardausgabe in einem leicht zu parsende Format für Skripte. Details finden Sie im Abschnitt OUTPUT in git-fetch[1].

Dies ist inkompatibel mit --recurse-submodules=[yes|on-demand] und hat Vorrang vor der Konfigurationsoption fetch.output.

-f
--force

Wenn git fetch mit der <src>:<dst> Refspec verwendet wird, kann es die Aktualisierung des lokalen Branches verweigern, wie im Teil <refspec> der Dokumentation von git-fetch[1] erläutert. Diese Option überschreibt diese Prüfung.

-k
--keep

Heruntergeladenes Pack behalten.

--prefetch

Ändert die konfigurierte Refspec, um alle Referenzen im Namensraum refs/prefetch/ zu platzieren. Siehe die Aufgabe prefetch in git-maintenance[1].

-p
--prune

Vor dem Holen entfernen Sie alle Remote-Tracking-Referenzen, die nicht mehr im Remote vorhanden sind. Tags unterliegen keinem Pruning, wenn sie nur wegen des standardmäßigen Tag-Autofollowings oder wegen einer --tags-Option geholt werden. Wenn Tags jedoch wegen einer expliziten Refspec geholt werden (entweder auf der Kommandozeile oder in der Remote-Konfiguration, z. B. wenn das Remote mit der Option --mirror geklont wurde), unterliegen sie ebenfalls dem Pruning. Die Angabe von --prune-tags ist eine Kurzform für die Angabe der Tag-Refspec.

--no-tags

Standardmäßig werden Tags, die auf Objekte zeigen, die aus dem Remote-Repository heruntergeladen werden, geholt und lokal gespeichert. Diese Option deaktiviert dieses automatische Tag-Following. Das Standardverhalten für ein Remote kann mit der Einstellung remote.<name>.tagOpt festgelegt werden. Siehe git-config[1].

--refmap=<refspec>

Beim Holen von auf der Kommandozeile aufgeführten Referenzen wird die angegebene Refspec (kann mehrfach angegeben werden) verwendet, um die Referenzen auf Remote-Tracking-Branches abzubilden, anstatt der Werte der Konfigurationsvariablen remote.*.fetch für das Remote-Repository. Die Angabe einer leeren <refspec> für die Option --refmap bewirkt, dass Git die konfigurierten Refspecs ignoriert und sich vollständig auf die als Befehlszeilenargumente übergebenen Refspecs verlässt. Siehe den Abschnitt "Configured Remote-tracking Branches" für Details.

-t
--tags

Holen Sie alle Tags vom Remote (d.h. holen Sie Remote-Tags refs/tags/* in lokale Tags mit demselben Namen), zusätzlich zu allem anderen, was sonst geholt würde. Die alleinige Verwendung dieser Option unterliegt keinem Pruning, auch wenn --prune verwendet wird (obwohl Tags trotzdem beschnitten werden können, wenn sie auch das Ziel einer expliziten Refspec sind; siehe --prune).

-j
--jobs=<n>

Anzahl der parallelen Kindprozesse, die für alle Formen des Holens verwendet werden.

Wenn die Option --multiple angegeben wurde, werden die verschiedenen Remotes parallel geholt. Wenn mehrere Submodule geholt werden, werden sie parallel geholt. Um sie unabhängig voneinander zu steuern, verwenden Sie die Konfigurationseinstellungen fetch.parallel und submodule.fetchJobs (siehe git-config[1]).

Typischerweise sind parallele rekursive und Multi-Remote-Fetches schneller. Standardmäßig werden Fetches sequentiell und nicht parallel durchgeführt.

--set-upstream

Wenn das Remote erfolgreich geholt wurde, fügen Sie eine Upstream- (Tracking-) Referenz hinzu, die von git-pull[1] ohne Argumente und anderen Befehlen verwendet wird. Weitere Informationen finden Sie unter branch.<name>.merge und branch.<name>.remote in git-config[1].

--upload-pack <upload-pack>

Wenn angegeben und das zu holende Repository von git fetch-pack behandelt wird, wird --exec=<upload-pack> an den Befehl übergeben, um einen nicht standardmäßigen Pfad für den auf der Gegenseite ausgeführten Befehl anzugeben.

--progress

Der Fortschrittsstatus wird standardmäßig auf dem Standardfehlerausgabestrom berichtet, wenn dieser an ein Terminal angeschlossen ist, es sei denn, -q wird angegeben. Diese Flag erzwingt die Anzeige des Fortschrittsstatus, auch wenn der Standardfehlerausgabestrom nicht an ein Terminal weitergeleitet wird.

-o <option>
--server-option=<option>

Übermittelt die angegebene Zeichenfolge an den Server, wenn über Protokollversion 2 kommuniziert wird. Die angegebene Zeichenfolge darf keine NUL- oder LF-Zeichen enthalten. Die Handhabung von Server-Optionen durch den Server, einschließlich unbekannter, ist serverspezifisch. Wenn mehrere --server-option=<option> angegeben werden, werden sie alle in der auf der Kommandozeile angegebenen Reihenfolge an die Gegenseite gesendet. Wenn keine --server-option=<option> von der Kommandozeile angegeben wird, werden stattdessen die Werte der Konfigurationsvariablen remote.<name>.serverOption verwendet.

--show-forced-updates

Standardmäßig prüft git, ob ein Branch während des Holens zwangsaktualisiert wird. Dies kann durch fetch.showForcedUpdates deaktiviert werden, aber die Option --show-forced-updates garantiert, dass diese Prüfung durchgeführt wird. Siehe git-config[1].

--no-show-forced-updates

Standardmäßig prüft git, ob ein Branch während des Holens zwangsaktualisiert wird. Geben Sie --no-show-forced-updates an oder setzen Sie fetch.showForcedUpdates auf false, um diese Prüfung aus Leistungsgründen zu überspringen. Wenn sie während eines git-pull verwendet wird, prüft die Option --ff-only trotzdem auf Zwangsaktualisierungen, bevor ein Fast-Forward-Update versucht wird. Siehe git-config[1].

-4
--ipv4

Nur IPv4-Adressen verwenden, IPv6-Adressen ignorieren.

-6
--ipv6

Nur IPv6-Adressen verwenden, IPv4-Adressen ignorieren.

<repository>

Das "Remote"-Repository, das die Quelle einer Fetch- oder Pull-Operation ist. Dieser Parameter kann entweder eine URL sein (siehe Abschnitt GIT URLS unten) oder der Name eines Remotes (siehe Abschnitt REMOTES unten).

<refspec>

Gibt an, welche Referenzen geholt werden sollen und welche lokalen Referenzen aktualisiert werden sollen. Wenn keine <refspec>s in der Kommandozeile erscheinen, werden die zu holenden Referenzen stattdessen aus den remote.<repository>.fetch Variablen gelesen (siehe den Abschnitt "KONFIGURIERTE REMOTE-TRACKING-BRANCHES" in git-fetch[1]).

Das Format eines <refspec> Parameters ist ein optionales Pluszeichen +, gefolgt von der Quelle <src>, gefolgt von einem Doppelpunkt :, gefolgt vom Ziel <dst>. Der Doppelpunkt kann weggelassen werden, wenn <dst> leer ist. <src> ist typischerweise eine Referenz, oder ein Glob-Muster mit einem einzelnen *, das zur Übereinstimmung mit einer Menge von Referenzen verwendet wird, aber es kann auch ein vollständig ausgeschriebener Hex-Objektname sein.

Ein <refspec> kann ein * in seinem <src> enthalten, um eine einfache Mustererkennung anzuzeigen. Ein solcher Refspec funktioniert wie ein Glob, der jeden Ref mit dem Muster abgleicht. Ein Muster-Refspec <refspec> muss genau ein * sowohl im <src> als auch im <dst> haben. Er wird Refs zum Ziel abbilden, indem er das * durch den aus der Quelle übereinstimmenden Inhalt ersetzt.

Wenn ein Refspec mit einem ^-Präfix versehen ist, wird er als negativer Refspec interpretiert. Anstatt anzugeben, welche Refs abgerufen oder welche lokalen Refs aktualisiert werden sollen, gibt ein solcher Refspec stattdessen auszusendende Refs an. Ein Ref gilt als übereinstimmend, wenn er mit mindestens einem positiven Refspec übereinstimmt und mit keinem negativen Refspec übereinstimmt. Negative Refspecs können nützlich sein, um den Geltungsbereich eines Muster-Refspecs einzuschränken, sodass er keine bestimmten Refs einschließt. Negative Refspecs können selbst Muster-Refspecs sein. Sie dürfen jedoch nur ein <src> enthalten und kein <dst> angeben. Vollständig ausgeschriebene Hex-Objektnamen werden ebenfalls nicht unterstützt.

tag <tag> bedeutet dasselbe wie refs/tags/<tag>:refs/tags/<tag>; es fordert das Abrufen von allem bis zum angegebenen Tag an.

Der Remote-Ref, der mit <src> übereinstimmt, wird abgerufen, und wenn <dst> keine leere Zeichenkette ist, wird versucht, den lokalen Ref, der damit übereinstimmt, zu aktualisieren.

Ob diese Aktualisierung ohne --force erlaubt ist, hängt vom Ref-Namespace ab, zu dem abgerufen wird, von der Art des abgerufenen Objekts und davon, ob die Aktualisierung als Fast-Forward betrachtet wird. Im Allgemeinen gelten für das Abrufen die gleichen Regeln wie beim Pushen; siehe den Abschnitt <refspec>... von git-push[1] für deren Details. Ausnahmen von diesen Regeln, die speziell für *git fetch* gelten, werden unten aufgeführt.

Bis Git Version 2.20 und im Gegensatz zum Pushen mit git-push[1] wurden alle Aktualisierungen von refs/tags/* ohne + im Refspec (oder --force) akzeptiert. Beim Abrufen betrachteten wir promiscuous alle Tag-Aktualisierungen von einem Remote als erzwungene Abrufe. Seit Git Version 2.20 funktioniert das Abrufen zur Aktualisierung von refs/tags/* genauso wie beim Pushen. D.h. alle Aktualisierungen werden ohne + im Refspec (oder --force) abgelehnt.

Im Gegensatz zum Pushen mit git-push[1] werden alle Aktualisierungen außerhalb von refs/{tags,heads}/* ohne + im Refspec (oder --force) akzeptiert, sei es der Austausch z.B. eines Tree-Objekts gegen ein Blob, oder eines Commits gegen einen anderen Commit, der den vorherigen Commit nicht als Vorfahren hat usw.

Im Gegensatz zum Pushen mit git-push[1] gibt es keine Konfiguration, die diese Regeln ändert, und nichts Vergleichbares zu einem pre-fetch-Hook analog zum pre-receive-Hook.

Wie beim Pushen mit git-push[1] können alle oben beschriebenen Regeln für nicht erlaubte Aktualisierungen durch Hinzufügen eines optionalen führenden + zu einem Refspec (oder durch Verwendung der Kommandozeilenoption --force) überschrieben werden. Die einzige Ausnahme ist, dass kein Zwang die refs/heads/*-Namensraum dazu bringt, ein Nicht-Commit-Objekt zu akzeptieren.

Hinweis
 Wenn der Remote-Branch, den Sie abrufen möchten, bekanntermaßen regelmäßig zurückgesetzt und neu basisiert wird, wird erwartet, dass seine neue Spitze kein Nachfahre seiner vorherigen Spitze ist (wie in Ihrem Remote-Tracking-Branch beim letzten Abruf gespeichert). Sie möchten das +-Zeichen verwenden, um anzuzeigen, dass für solche Branches Nicht-Fast-Forward-Aktualisierungen erforderlich sind. Es gibt keine Möglichkeit zu bestimmen oder zu deklarieren, dass ein Branch mit diesem Verhalten in einem Repository verfügbar gemacht wird; der ziehende Benutzer muss einfach wissen, dass dies das erwartete Nutzungsmuster für einen Branch ist.
Hinweis
 Es gibt einen Unterschied zwischen dem Auflisten mehrerer <refspec> direkt auf der Kommandozeile von *git pull* und dem Vorhandensein mehrerer remote.<repository>.fetch-Einträge in Ihrer Konfiguration für ein <repository> und dem Ausführen eines *git pull*-Befehls ohne explizite <refspec>-Parameter. Explizit auf der Kommandozeile aufgeführte <refspec>s werden immer in den aktuellen Branch zusammengeführt, nachdem abgerufen wurde. Mit anderen Worten, wenn Sie mehr als einen Remote-Ref auflisten, erstellt *git pull* einen Octopus-Merge. Wenn Sie hingegen keinen expliziten <refspec>-Parameter auf der Kommandozeile angeben, ruft *git pull* alle <refspec>s ab, die es in der Konfiguration remote.<repository>.fetch findet, und führt nur den ersten gefundenen <refspec> in den aktuellen Branch zusammen. Dies liegt daran, dass das Erstellen eines Octopus aus Remote-Refs selten vorkommt, während das Verfolgen mehrerer Remote-Heads auf einmal durch Abrufen von mehr als einem oft nützlich ist.

GIT URLS

Im Allgemeinen enthalten URLs Informationen über das Transportprotokoll, die Adresse des Remote-Servers und den Pfad zum Repository. Abhängig vom Transportprotokoll können einige dieser Informationen fehlen.

Git unterstützt ssh, git, http und https Protokolle (zusätzlich können ftp und ftps zum Abrufen verwendet werden, aber das ist ineffizient und veraltet; verwenden Sie sie nicht).

Der native Transport (d.h. git:// URL) führt keine Authentifizierung durch und sollte mit Vorsicht in ungesicherten Netzwerken verwendet werden.

Die folgenden Syntaxe können damit verwendet werden

  • ssh://[<user>@]<host>[:<port>]/<pfad-zum-git-repo>

  • git://<host>[:<port>]/<pfad-zum-git-repo>

  • http[s]://<host>[:<port>]/<pfad-zum-git-repo>

  • ftp[s]://<host>[:<port>]/<pfad-zum-git-repo>

Eine alternative scp-ähnliche Syntax kann auch mit dem ssh-Protokoll verwendet werden

  • [<user>@]<host>:/<pfad-zum-git-repo>

Diese Syntax wird nur erkannt, wenn keine Schrägstriche vor dem ersten Doppelpunkt stehen. Dies hilft, einen lokalen Pfad, der einen Doppelpunkt enthält, zu unterscheiden. Zum Beispiel kann der lokale Pfad foo:bar als absoluter Pfad oder ./foo:bar angegeben werden, um eine Fehlinterpretation als ssh-URL zu vermeiden.

Die Protokolle ssh und git unterstützen zusätzlich die Erweiterung von ~<username>

  • ssh://[<user>@]<host>[:<port>]/~<user>/<pfad-zum-git-repo>

  • git://<host>[:<port>]/~<user>/<pfad-zum-git-repo>

  • [<user>@]<host>:~<user>/<pfad-zum-git-repo>

Für lokale Repositories, die ebenfalls nativ von Git unterstützt werden, können die folgenden Syntaxe verwendet werden

  • /pfad/zu/repo.git/

  • file:///pfad/zu/repo.git/

Diese beiden Syntaxe sind weitgehend äquivalent, außer beim Klonen, wenn die erste die Option --local impliziert. Siehe git-clone[1] für Details.

git clone, git fetch und git pull, aber nicht git push, akzeptieren auch eine geeignete Bundle-Datei. Siehe git-bundle[1].

Wenn Git ein bestimmtes Transportprotokoll nicht handhaben kann, versucht es, den Remote-Helfer remote-<transport> zu verwenden, falls einer existiert. Um explizit einen Remote-Helfer anzufordern, kann die folgende Syntax verwendet werden

  • <transport>::<adresse>

wobei <adresse> ein Pfad, ein Server und Pfad oder eine beliebige URL-ähnliche Zeichenkette sein kann, die vom spezifischen aufgerufenen Remote-Helfer erkannt wird. Siehe gitremote-helpers[7] für Details.

Wenn es eine große Anzahl ähnlich benannter Remote-Repositories gibt und Sie ein anderes Format dafür verwenden möchten (so dass die von Ihnen verwendeten URLs in URLs umgeschrieben werden, die funktionieren), können Sie einen Konfigurationsabschnitt der Form erstellen

	[url "<actual-url-base>"]
		insteadOf = <other-url-base>

Zum Beispiel, mit diesem

	[url "git://git.host.xz/"]
		insteadOf = host.xz:/path/to/
		insteadOf = work:

eine URL wie "work:repo.git" oder "host.xz:/path/to/repo.git" wird in jedem Kontext, der eine URL entgegennimmt, zu "git://git.host.xz/repo.git" umgeschrieben.

Wenn Sie URLs nur für Push-Operationen umschreiben möchten, können Sie einen Konfigurationsabschnitt der Form erstellen

	[url "<actual-url-base>"]
		pushInsteadOf = <other-url-base>

Zum Beispiel, mit diesem

	[url "ssh://example.org/"]
		pushInsteadOf = git://example.org/

eine URL wie "git://example.org/path/to/repo.git" wird für Push-Operationen zu "ssh://example.org/path/to/repo.git" umgeschrieben, aber Pull-Operationen verwenden weiterhin die ursprüngliche URL.

REMOTES

Der Name eines der folgenden kann anstelle einer URL als Argument repository verwendet werden

  • ein Remote in der Git-Konfigurationsdatei: $GIT_DIR/config,

  • eine Datei im Verzeichnis $GIT_DIR/remotes oder

  • eine Datei im Verzeichnis $GIT_DIR/branches.

All dies erlaubt Ihnen auch, die Refspec von der Kommandozeile wegzulassen, da jede dieser Dateien eine Refspec enthält, die Git standardmäßig verwendet.

Benannter Remote in der Konfigurationsdatei

Sie können den Namen eines Remotes angeben, den Sie zuvor mit git-remote[1], git-config[1] oder durch manuelle Bearbeitung der Datei $GIT_DIR/config konfiguriert haben. Die URL dieses Remotes wird verwendet, um auf das Repository zuzugreifen. Die Refspec dieses Remotes wird standardmäßig verwendet, wenn Sie keine Refspec auf der Kommandozeile angeben. Der Eintrag in der Konfigurationsdatei würde wie folgt aussehen:

	[remote "<name>"]
		url = <URL>
		pushurl = <pushurl>
		push = <refspec>
		fetch = <refspec>

Die <pushurl> wird nur für Pushes verwendet. Sie ist optional und standardmäßig <URL>. Das Pushen zu einem Remote betrifft alle definierten Push-URLs oder alle definierten URLs, wenn keine Push-URLs definiert sind. Fetch hingegen holt nur von der ersten definierten URL, wenn mehrere URLs definiert sind.

Benannte Datei in $GIT_DIR/remotes

Sie können den Namen einer Datei in $GIT_DIR/remotes angeben. Die URL in dieser Datei wird verwendet, um auf das Repository zuzugreifen. Die Refspec in dieser Datei wird als Standard verwendet, wenn Sie keine Refspec auf der Kommandozeile angeben. Diese Datei sollte folgendes Format haben:

	URL: one of the above URL formats
	Push: <refspec>
	Pull: <refspec>

Push: Zeilen werden von git push verwendet und Pull: Zeilen werden von git pull und git fetch verwendet. Mehrere Push: und Pull: Zeilen können für zusätzliche Branch-Mappings angegeben werden.

Benannte Datei in $GIT_DIR/branches

Sie können den Namen einer Datei in $GIT_DIR/branches angeben. Die URL in dieser Datei wird verwendet, um auf das Repository zuzugreifen. Diese Datei sollte folgendes Format haben:

	<URL>#<head>

<URL> ist erforderlich; #<head> ist optional.

Abhängig vom Vorgang verwendet Git eine der folgenden Refspecs, wenn Sie keine auf der Kommandozeile angeben. <branch> ist der Name dieser Datei in $GIT_DIR/branches und <head> standardmäßig master.

git fetch verwendet

	refs/heads/<head>:refs/heads/<branch>

git push verwendet

	HEAD:refs/heads/<head>

UPSTREAM BRANCHES

Branches in Git können optional einen Upstream-Remote-Branch haben. Git verwendet standardmäßig den Upstream-Branch für Remote-Operationen, z. B.

  • Dies ist der Standard für git pull oder git fetch ohne Argumente.

  • Dies ist der Standard für git push ohne Argumente, mit einigen Ausnahmen. Sie können zum Beispiel die Option branch.<name>.pushRemote verwenden, um zu einem anderen Remote zu pushen, als von dem Sie ziehen, und standardmäßig mit push.default=simple muss der von Ihnen konfigurierte Upstream-Branch denselben Namen haben.

  • Verschiedene Befehle, einschließlich git checkout und git status, zeigen Ihnen, wie viele Commits zu Ihrem aktuellen Branch und zum Upstream hinzugefügt wurden, seitdem Sie ihn verzweigt haben, z. B. "Your branch and origin/main have diverged, and have 2 and 3 different commits each respectively".

Der Upstream wird in .git/config in den Feldern "remote" und "merge" gespeichert. Wenn zum Beispiel main's Upstream origin/main ist

[branch "main"]
   remote = origin
   merge = refs/heads/main

Sie können einen Upstream-Branch explizit mit git push --set-upstream <remote> <branch> festlegen, aber Git legt den Upstream oft automatisch für Sie fest, zum Beispiel

  • Wenn Sie ein Repository klonen, setzt Git den Upstream für den Standard-Branch automatisch.

  • Wenn die Konfigurationsoption push.autoSetupRemote gesetzt ist, setzt git push den Upstream automatisch beim ersten Push eines Branches.

  • Das Auschecken eines Remote-Tracking-Branches mit git checkout <branch> erstellt automatisch einen lokalen Branch mit diesem Namen und setzt den Upstream auf den Remote-Branch.

Hinweis
 Upstream-Branches werden manchmal als "Tracking-Informationen" bezeichnet, wie in "set the branch’s tracking information".

MERGE-STRATEGIEN

Der Merge-Mechanismus (git merge und git pull Befehle) erlaubt die Auswahl der Backend-Merge-Strategien mit der Option -s. Einige Strategien können auch ihre eigenen Optionen haben, die durch Angabe von -X<option>-Argumenten an git merge und/oder git pull übergeben werden können.

ort

Dies ist die Standard-Merge-Strategie beim Ziehen oder Zusammenführen eines Branches. Diese Strategie kann nur zwei Heads mit einem 3-Wege-Merge-Algorithmus auflösen. Wenn es mehr als einen gemeinsamen Vorfahren gibt, der für einen 3-Wege-Merge verwendet werden kann, erstellt sie einen zusammengeführten Baum der gemeinsamen Vorfahren und verwendet diesen als Referenzbaum für den 3-Wege-Merge. Dies führt Berichten zufolge zu weniger Merge-Konflikten, ohne Fehlmerges zu verursachen, wie Tests mit tatsächlichen Merge-Commits aus der Linux 2.6 Kernel-Entwicklungshistorie zeigen. Zusätzlich kann diese Strategie das Erkennen und Behandeln von Merges mit Umbenennungen. Sie nutzt keine erkannten Kopien. Der Name für diesen Algorithmus ist ein Akronym ("Ostensibly Recursive’s Twin") und entstand aus der Tatsache, dass er als Ersatz für den vorherigen Standardalgorithmus, recursive, geschrieben wurde.

In Fällen, in denen der Pfad ein Submodul ist, wenn der auf einer Seite des Merges verwendete Submodul-Commit ein Nachfahre des auf der anderen Seite des Merges verwendeten Submodul-Commits ist, versucht Git, zum Nachfahren zu wechseln. Andernfalls behandelt Git diesen Fall als Konflikt und schlägt als Auflösung einen Submodul-Commit vor, der ein Nachfahre der konfligierenden ist, falls einer existiert.

Die ort-Strategie kann die folgenden Optionen annehmen

ours

Diese Option erzwingt die automatische Auflösung von konfligierenden Hunks, indem sie die Version von *unserer* Seite bevorzugt. Änderungen vom anderen Baum, die nicht mit unserer Seite kollidieren, werden im Merge-Ergebnis berücksichtigt. Bei einer Binärdatei werden die gesamten Inhalte von unserer Seite übernommen.

Dies sollte nicht mit der ours-Merge-Strategie verwechselt werden, die nicht einmal den anderen Baum betrachtet. Sie verwirft alles, was der andere Baum enthält, und erklärt, dass *unser* Verlauf alles enthält, was darin passiert ist.

theirs

Dies ist das Gegenteil von ours; beachte, dass es im Gegensatz zu ours keine theirs-Merge-Strategie gibt, mit der man diese Merge-Option verwechseln könnte.

ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eol

Behandelt Zeilen mit der angegebenen Art von Leerzeichenänderung als unverändert für den Zweck eines Drei-Wege-Merges. Leerzeichenänderungen, die mit anderen Änderungen an einer Zeile vermischt sind, werden nicht ignoriert. Siehe auch git-diff[1] -b, -w, --ignore-space-at-eol und --ignore-cr-at-eol.

  • Wenn die *ihre* Version nur Leerzeichenänderungen an einer Zeile einführt, wird *unsere* Version verwendet;

  • Wenn *unsere* Version Leerzeichenänderungen einführt, aber *ihre* Version eine wesentliche Änderung enthält, wird *ihre* Version verwendet;

  • Andernfalls wird der Merge wie gewohnt fortgesetzt.

renormalize

Führt einen virtuellen Checkout und Check-in aller drei Stufen jeder Datei durch, die einen Drei-Wege-Merge benötigt. Diese Option ist für das Mergen von Branches mit unterschiedlichen Clean-Filtern oder End-of-Line-Normalisierungsregeln gedacht. Siehe "Merging branches with differing checkin/checkout attributes" in gitattributes[5] für Details.

no-renormalize

Deaktiviert die Option renormalize. Dies überschreibt die Konfigurationsvariable merge.renormalize.

find-renames[=<n>]

Schaltet die Erkennung von Umbenennungen ein und setzt optional den Ähnlichkeitsschwellenwert. Dies ist die Standardeinstellung. Dies überschreibt die Konfigurationsvariable merge.renames. Siehe auch git-diff[1] --find-renames.

rename-threshold=<n>

Veraltetes Synonym für find-renames=<n>.

no-renames

Schaltet die Erkennung von Umbenennungen aus. Dies überschreibt die Konfigurationsvariable merge.renames. Siehe auch git-diff[1] --no-renames.

histogram

Veraltetes Synonym für diff-algorithm=histogram.

patience

Veraltetes Synonym für diff-algorithm=patience.

diff-algorithm=(histogram|minimal|myers|patience)

Verwendet einen anderen Diff-Algorithmus beim Mergen, der helfen kann, Fehlmerges zu vermeiden, die aufgrund unwichtiger übereinstimmender Zeilen (wie Klammern aus unterschiedlichen Funktionen) auftreten. Siehe auch git-diff[1] --diff-algorithm. Beachten Sie, dass ort standardmäßig diff-algorithm=histogram verwendet, während normale Diffs derzeit standardmäßig auf die Konfigurationseinstellung diff.algorithm zurückgreifen.

subtree[=<path>]

Diese Option ist eine fortgeschrittenere Form der Subtree-Strategie, bei der die Strategie eine Vermutung darüber anstellt, wie zwei Bäume verschoben werden müssen, um zueinander zu passen, wenn sie gemerged werden. Stattdessen wird der angegebene Pfad vorangestellt (oder vom Anfang entfernt), um die Form zweier Bäume anzupassen.

recursive

Dies ist jetzt ein Synonym für ort. Es war bis v2.49.0 eine alternative Implementierung, wurde aber in v2.50.0 auf ort umgeleitet. Die frühere rekursive Strategie war die Standardstrategie zum Auflösen von zwei Heads von Git v0.99.9k bis v2.33.0.

resolve

Dies kann nur zwei Heads (d.h. den aktuellen Branch und einen anderen von Ihnen gezogenen Branch) mittels eines 3-Wege-Merge-Algorithmus auflösen. Es versucht, Kreuz-Merge-Mehrdeutigkeiten sorgfältig zu erkennen. Es behandelt keine Umbenennungen.

octopus

Dies löst Fälle mit mehr als zwei Heads auf, weigert sich aber, einen komplexen Merge durchzuführen, der eine manuelle Auflösung erfordert. Er ist hauptsächlich dazu gedacht, Topic-Branch-Heads zu bündeln. Dies ist die Standard-Merge-Strategie beim Ziehen oder Zusammenführen von mehr als einem Branch.

ours

Dies löst eine beliebige Anzahl von Heads auf, aber der resultierende Baum des Merges ist immer der des aktuellen Branch-Heads, wobei alle Änderungen von allen anderen Branches effektiv ignoriert werden. Er ist dazu gedacht, die alte Entwicklungsgeschichte von Seiten-Branches zu ersetzen. Beachten Sie, dass dies sich von der Option -Xours zur ort-Merge-Strategie unterscheidet.

subtree

Dies ist eine modifizierte ort-Strategie. Beim Mergen der Bäume A und B wird, wenn B einem Subtree von A entspricht, B zuerst angepasst, um die Baumstruktur von A abzugleichen, anstatt die Bäume auf derselben Ebene zu lesen. Diese Anpassung wird auch auf den gemeinsamen Vorfahren-Baum angewendet.

Mit den Strategien, die 3-Wege-Merges verwenden (einschließlich der Standardstrategie ort), wird eine Änderung, die auf beiden Branches vorgenommen wurde, aber später auf einem der Branches rückgängig gemacht wurde, im zusammengeführten Ergebnis vorhanden sein; einige Leute finden dieses Verhalten verwirrend. Es tritt auf, weil nur die Heads und die Merge-Basis für die Durchführung eines Merges berücksichtigt werden, nicht die einzelnen Commits. Der Merge-Algorithmus betrachtet daher die rückgängig gemachte Änderung als keine Änderung und ersetzt sie stattdessen durch die geänderte Version.

STANDARDVERHALTEN

Oft verwenden Leute git pull ohne Angabe von Parametern. Traditionell entsprach dies der Angabe von git pull origin. Wenn jedoch die Konfiguration branch.<name>.remote vorhanden ist, während man sich auf dem Branch <name> befindet, wird dieser Wert anstelle von origin verwendet.

Um zu ermitteln, von welcher URL abgerufen werden soll, wird der Wert der Konfiguration remote.<origin>.url konsultiert, und wenn keine solche Variable vorhanden ist, wird der Wert in der Zeile URL: in $GIT_DIR/remotes/<origin> verwendet.

Um zu ermitteln, welche Remote-Branches abgerufen (und optional in den Remote-Tracking-Branches gespeichert) werden sollen, wenn der Befehl ohne Refspec-Parameter auf der Kommandozeile ausgeführt wird, werden die Werte der Konfigurationsvariablen remote.<origin>.fetch konsultiert, und wenn keine vorhanden sind, wird $GIT_DIR/remotes/<origin> konsultiert und seine Pull:-Zeilen verwendet. Zusätzlich zu den im OPTIONS-Abschnitt beschriebenen Refspec-Formaten können Sie einen globbing-Refspec haben, der wie folgt aussieht:

refs/heads/*:refs/remotes/origin/*

Ein globbing-Refspec muss eine nicht-leere RHS haben (d.h. er muss speichern, was in Remote-Tracking-Branches abgerufen wurde), und seine LHS und RHS müssen mit /* enden. Das Obige gibt an, dass alle Remote-Branches unter der Hierarchie refs/remotes/origin/ mit demselben Namen über Remote-Tracking-Branches verfolgt werden.

Die Regel zur Bestimmung, welcher Remote-Branch nach dem Abrufen zusammengeführt wird, ist etwas kompliziert, um die Abwärtskompatibilität nicht zu beeinträchtigen.

Wenn explizite Refspecs auf der Kommandozeile von git pull angegeben wurden, werden alle zusammengeführt.

Wenn auf der Kommandozeile kein Refspec angegeben wurde, verwendet git pull den Refspec aus der Konfiguration oder $GIT_DIR/remotes/<origin>. In solchen Fällen gelten folgende Regeln:

  1. Wenn die Konfiguration branch.<name>.merge für den aktuellen Branch <name> existiert, ist dies der Name des Branches auf der Remote-Seite, der zusammengeführt wird.

  2. Wenn der Refspec ein globbing-Refspec ist, wird nichts zusammengeführt.

  3. Andernfalls wird der Remote-Branch des ersten Refspec zusammengeführt.

BEISPIELE

  • Aktualisieren Sie die Remote-Tracking-Branches für das Repository, von dem Sie geklont haben, und führen Sie dann einen davon in Ihren aktuellen Branch zusammen.

    $ git pull
$ git pull origin

    Normalerweise ist der zusammengeführte Branch der HEAD des Remote-Repositorys, aber die Wahl wird durch die Optionen branch.<name>.remote und branch.<name>.merge bestimmt; siehe git-config[1] für Details.

  • Führen Sie den Remote-Branch next in den aktuellen Branch zusammen.

    $ git pull origin next

    Dies hinterlässt eine Kopie von next temporär in FETCH_HEAD und aktualisiert den Remote-Tracking-Branch origin/next. Dasselbe kann durch Aufrufen von fetch und merge erreicht werden.

    $ git fetch origin
$ git merge origin/next

Wenn Sie einen Pull versucht haben, der zu komplexen Konflikten geführt hat und Sie von vorne beginnen möchten, können Sie mit *git reset* wiederherstellen.

SICHERHEIT

Die Fetch- und Push-Protokolle sind nicht darauf ausgelegt, zu verhindern, dass eine Seite Daten von einem anderen Repository stiehlt, die nicht zum Teilen bestimmt waren. Wenn Sie private Daten haben, die Sie vor einem böswilligen Peer schützen müssen, ist Ihre beste Option, sie in einem anderen Repository zu speichern. Dies gilt sowohl für Clients als auch für Server. Insbesondere Namensräume auf einem Server sind für die Lesezugriffskontrolle nicht effektiv; Sie sollten einem Namensraum nur Lesezugriff gewähren, wenn Sie einem Client vertrauen würden, der Lesezugriff auf das gesamte Repository hat.

Die bekannten Angriffsvektoren sind wie folgt:

  1. Das Opfer sendet "have"-Zeilen, die die IDs von Objekten ankündigen, die es besitzt und die nicht explizit zum Teilen bestimmt sind, aber zur Optimierung der Übertragung verwendet werden können, wenn der Peer sie ebenfalls hat. Der Angreifer wählt ein Objekt-ID X zum Stehlen aus und sendet eine Ref auf X, muss aber nicht den Inhalt von X senden, da das Opfer es bereits hat. Nun glaubt das Opfer, dass der Angreifer X hat, und es sendet den Inhalt von X später zurück an den Angreifer. (Dieser Angriff ist für einen Client am einfachsten auf einen Server durchzuführen, indem eine Ref auf X in dem Namensraum erstellt wird, auf den der Client Zugriff hat, und diese dann geholt wird. Der wahrscheinlichste Weg für einen Server, dies auf einem Client durchzuführen, ist, X in einen öffentlichen Branch zu "mergen" und zu hoffen, dass der Benutzer zusätzliche Arbeit an diesem Branch leistet und ihn an den Server zurückpusht, ohne den Merge zu bemerken.)

  2. Wie in #1 wählt der Angreifer eine Objekt-ID X zum Stehlen aus. Das Opfer sendet ein Objekt Y, das der Angreifer bereits hat, und der Angreifer behauptet fälschlicherweise, X und nicht Y zu haben, so dass das Opfer Y als Delta gegen X sendet. Das Delta enthüllt dem Angreifer Regionen von X, die Y ähnlich sind.

BUGS

Die Verwendung von --recurse-submodules kann derzeit nur neue Commits in bereits ausgecheckten Submodulen abrufen. Wenn z. B. der Upstream ein neues Submodul in den gerade abgerufenen Commits des Superprojekts hinzugefügt hat, kann das Submodul selbst nicht abgerufen werden, was es unmöglich macht, dieses Submodul später auszuchecken, ohne erneut abrufen zu müssen. Dies wird voraussichtlich in einer zukünftigen Git-Version behoben.

SIEHE AUCH

git-fetch[1], git-merge[1], git-config[1]

GIT

Teil der git[1] Suite