Eine harte Zeit Verständnis git-fetch -

Question

Ich habe eine harte Zeit zu verstehen, die Nuancen der git-fetch.Ich verstehe, dass dabei eine fetch, holt die remote-refs in ein lokales tracking-Zweig.

Ich habe ein paar Fragen, aber:

1. Kann es möglich sein, dass ein lokales tracking-Zweig nicht vorhanden ist?Wenn ja, wird es dann automatisch erstellt werden?

2. Was passiert, wenn ich tun fetch und geben Sie einen nicht-tracking-Zweig als Ziel?

3. Die man-page git-fetch gibt:

   git-fetch <options> <repository> <refspec>
   

Wie würde ich die refspec zu Holen, um Inhalte aus meinem remote-master in Ihre remote-tracking-Zweig?Ich glaube, dass dies möglich sein kann, wenn meine aktuelle KOPF ist auf master und ich Lauf

git fetch origin master

Allerdings kann ich die <+?src:dest> refspec, das gleiche zu erreichen?Ich denke, dies wird mir helfen, zu verstehen, die Konzepte besser.

Und noch eine Frage:

Meine .git/config-Datei die folgende Zeile für den Abruf (zeigt nur relevante Zeilen):

fetch = +refs/heads/*:refs/remotes/origin/*

Kann mir bitte jemand erklären, was diese Linie genau bedeutet?

Answer 1

Zunächst gibt es kein solches Konzept von lokal Tracking Zweige, nur Remote-Tracking Filialen. So origin / master ist ein Remote-Tracking-Zweig für Master in der Herkunft Repo.

Normalerweise Sie git remote $ holen , die aktualisiert alle Remote-Tracking-Zweige und schafft neue, wenn nötig.

Sie können jedoch auch eine Refspec angeben, aber das wird Ihren Remote-Tracking-Zweig nicht berühren, sondern es wird die Niederlassung von Ihnen angegebenen holen und auf FETCH_HEAD sparen, wenn Sie ein Ziel angeben. Im Allgemeinen Sie wollen nicht zu verwirren mit diesem.

Schließlich

fetch = +refs/heads/*:refs/remotes/origin/*

Das bedeutet, wenn Sie das tun

git fetch origin

Es wird tatsächlich tun:

git fetch origin +refs/heads/*:refs/remotes/origin/*

Das bedeutet ein Remote Köpfe / foobar wird lokal Fernbedienungen / Herkunft / foobar , und das Pluszeichen bedeutet, dass sie aktualisiert werden, werden auch wenn sie nicht schnell- sind nach vorn.

Vielleicht, was Sie denken wie ein Tracking-Zweig ist etwas im Zusammenhang mit git pull und der Merge-Konfig.

Answer 2

felipec have beantwortet die meisten Fragen in Frage in seiner Antwort .

Ein paar verbleibenden (die meisten genommen von git holen manpage, was ein wenig an einigen Stellen leider) datiert ist:

• Wenn Remote-Tracking-Zweig (Niederlassung, die eine gewisse Verzweigung in einem entfernten Repository-Spuren) nicht existiert, wäre es erstellt werden.

• Der Zweig Sie in (der <dst> in [+]<src>:<dst>) holen muss nicht in remotes/<remote>/ Namespace befinden. Zum Beispiel für Repositories (git clone --mirror) Refspec Spiegelung 1 bis 1. In alten Zeiten, bevor getrenntes Fernbedienungen Layout (vor remotes/<remote>/ Namespace für Remote-Tracking-Refs) Master Zweig wurde geholt in dem Zweig genannt Herkunft . Selbst zur Zeit Tags werden in Mirroring Mode direkt in tags/ Namensraum geholt.

• Wenn Zweig Sie in (die rechte Seite von Refspec <src>:<dst> sind Holen nicht vorhanden ist, würde Git überprüfen, ob Download in vorspulen führen würde, das heißt, wenn die aktuelle Zustand in <dst> Vorfahren des Staates in <src> ist in abgelegenem gegeben Repository. Wenn es nicht ist, und Sie nicht -f / --force Option verwenden, um git-holen, oder Präfix Refspec mit '+' (Verwendung +<src>:<dst> Refspec) holen würde sich weigern, diesen Zweig zu aktualisieren.

• git fetch origin master entspricht git fetch origin master:, nicht zu git fetch origin master:master; es speichert geholt Wert von Master Zweig (Remote Herkunft ) in FETCH_HEAD , und nicht in Master Zweig oder remote -verfolgung remotes/origin/master Zweig. Es kann durch git merge FETCH_HEAD folgen. Normalerweise verwendet nicht direkt, sondern als Teil der einmaligen Zug ohne Einstellung Fernverfolgung Zweig. git pull <URL> <branch>

• +refs/heads/*:refs/remotes/origin/* als Wert für remote.origin.fetch Konfigurationsvariable bedeutet, dass jeder Zweig (ref in refs/heads/ Namensraum) in Fern Herkunft abgerufen wird in jeweils benannt Fern -verfolgung Niederlassung in refs/remotes/origin/ Namensraum, zB Master Zweig in Herkunft (d.h. refs/heads/master ref) würde in origin / master Remote-Tracking-Zweig (d refs/remotes/origin/master ref) abgeholt werden. Das ‚+‘ Präfix bedeutet, dass gelingen würde holen auch in nicht vorspulen Fall, was bedeutet, wenn Zweig auf Fern umbasiert wird oder zurückgespult (Reset zu einem gewissen Zustand in Vergangenheit) oder in anderer Weise geändert.

Nebenbei bemerkt: Sie würden wahrscheinlich wollen höhere Ebene verwenden git remote Befehl Remote-Repositories zu verwalten und Updates erhalten

Answer 3

Beachten Sie, dass der Haupt-maintainer von Git ist jetzt (Git 2.1, August 2014) hat diese Erklärung für git fetch:
(Siehe commit fcb14b0 von Junio C Hamano (gitster):

KONFIGURIERT DIE REMOTE-TRACKING-ZWEIGE

Sie interagieren oft mit den gleichen remote-repository regelmäßig und wiederholt abrufen von es.Um zu verfolgen, den Fortschritt von solchen remote-repository, git fetch ermöglicht Ihnen die Konfiguration remote.<repository>.fetch Konfigurations-Variablen.

In der Regel solchen Variablen kann wie folgt Aussehen:

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*

Diese Konfiguration ist verwendet in zwei Möglichkeiten:

• Wenn git fetch ausgeführt wird, ohne anzugeben, was Branchen-und/oder tags zu Holen, die auf der Kommandozeile, z.B. git fetch origin oder git fetch, remote.<repository>.fetch Werte als refspecs---geben Sie die refs zu Holen und die lokalen refs zu aktualisieren.
  Das obige Beispiel bezieht alle Zweige, die es in der origin (d.h.jedem ref entspricht der linken Seite der Wert, refs/heads/*), und aktualisieren Sie den entsprechenden remote-tracking-Zweige in der refs/remotes/origin/* Hierarchie.

• Wenn git fetch starten Sie mit ausdrücklicher Branchen-und/oder tags zu Holen, die auf der Kommandozeile, z.B. git fetch origin master, die <refspec>s in der Befehlszeile angegeben wird bestimmen, welche heruntergeladen werden (z.B. master in dem Beispiel, das ist eine kurze hand für master:, ist , was wiederum bedeutet "Holen 'master'Zweig, aber ich weiß nicht ausdrücklich sagen, was remote-tracking-Zweig update von der Befehlszeile aus"), und das Beispiel wird der Befehl fetch nur die 'master'branch.
  Die remote.<repository>.fetch Werte bestimmen die remote-tracking-Zweig, sofern vorhanden, aktualisiert.
  Wenn auf diese Weise verwendet, die remote.<repository>.fetch Werte haben keine Auswirkungen bei der Entscheidung was wird geholt (D. H.die Werte dienen nicht als refspecs wenn die Kommandozeilen-Listen refspecs);Sie werden nur verwendet, um zu entscheiden, wo die refs, die abgerufen werden, gespeichert sind, indem Sie als mapping.

Answer 4

Beachten Sie auch, dass, mit Git 2.5+ (Q2 2015), git merge FETCH_HEAD können verbinden Sie mehrere git fetch s.

Finden commit d45366e von Junio C Hamano (gitster), 26 Mar 2015.
^{(Zusammengefasst von Junio C Hamano -- gitster -- in commit bcd1ecd, 19 May 2015)}

"git merge FETCH_HEAD"gelernt, dass der frühere "git fetch"werden könnten, um erstellen Sie einen Oktopus Zusammenführen, D. H.Aufnahme mehrere Zweige, die sind nicht markiert als "not-for-merge";
dies ermöglicht uns zu verlieren, ein old-style-Aufruf "git merge <msg> HEAD $commits..."in der Umsetzung "git pull"Skript;die old-style-syntax ist nun veraltet.

Die git merge doc jetzt erwähnen:

Wenn FETCH_HEAD (und keine anderen commit) angegeben ist, die Zweige, aufgenommen in der .git/FETCH_HEAD - Datei durch den vorherigen Aufruf von git fetch für die Zusammenführung zusammengeführt werden, um den aktuellen Zweig.

---

Git 2.13 (Q2 2017) offiziell zieht sich die alte syntax für git merge.
Finden commit b439165 (26 Mar 2015) von Junio C Hamano (gitster).
^{(Zusammengefasst von Junio C Hamano -- gitster -- in commit 1fdbfc4, 30 Mar 2017)}

merge:drop 'git merge <message> HEAD <commit>'syntax

Mehr unterstützen "git merge <message> HEAD <commit>"syntax hat veraltet seit Oktober 2007 und gibt eine deprecation Warnung, da v2.5.0.

Das bedeutet, dass die Warnmeldung im alten Stil "'git merge <msg> HEAD <commit>' is deprecated."ist nicht mehr.