wake-up-neo.com

Was ist der Unterschied zwischen git clone --mirror und git clone --bare?

Auf der Hilfeseite zum Git-Klon steht Folgendes zu --mirror:

Richten Sie einen Spiegel des Remote-Repository ein. Dies impliziert --bare.

Aber geht nicht ins Detail darüber, wie sich der --mirror Klon von einem --bare Klon unterscheidet.

432
Sam

Der Unterschied besteht darin, dass bei Verwendung von --mirror alle Refs unverändert kopiert werden. Dies bedeutet alles: Remote-Tracking-Zweige, Notizen, Refs/Originale/* (Backups vom Filter-Zweig). Das geklonte Repo hat alles. Es ist auch so eingerichtet, dass bei einem Remote-Update alles aus Origin erneut abgerufen wird (Überschreiben der kopierten Referenzen). Die Idee ist wirklich, das Repository zu spiegeln, um eine vollständige Kopie zu erhalten, damit Sie beispielsweise Ihr zentrales Repo an mehreren Orten hosten oder es sichern können. Denken Sie nur daran, das Repo direkt zu kopieren, außer auf eine viel elegantere Art und Weise.

Das neue Dokumentation sagt so ziemlich alles:

--mirror

Richten Sie einen Spiegel des Quellrepositorys ein. Dies impliziert --bare. Im Vergleich zu --bare ordnet --mirror nicht nur lokale Zweige der Quelle lokalen Zweigen des Ziels zu, sondern ordnet alle Verweise (einschließlich entfernter Zweige, Notizen usw.) zu und richtet eine solche Verweiskonfiguration ein Diese Referenzen werden durch einen git remote update im Ziel-Repository überschrieben.

In meiner ursprünglichen Antwort wurden auch die Unterschiede zwischen einem bloßen Klon und einem normalen (nicht bloßen) Klon festgestellt. Der nicht bloße Klon richtet Remote-Tracking-Zweige ein und erstellt nur einen lokalen Zweig für HEAD, während der bloße Klon den Klon kopiert Zweige direkt.

Angenommen, Origin hat einige Verzweigungen (master (HEAD), next, pu und maint), einige Tags (v1, v2, v3), einige entfernte Zweige (devA/master, devB/master) und einige andere Verweise (refs/foo/bar, refs/foo/baz, die Notizen, Verstecke oder Namespaces anderer Entwickler sein können , Wer weiß).

  • git clone Origin-url (nicht bloß): Sie erhalten alle Tags kopiert, eine lokale Verzweigung master (HEAD), die eine entfernte Verzweigung verfolgt Origin/master und entfernte Zweige Origin/next, Origin/pu und Origin/maint. Die Verfolgungszweige sind so eingerichtet, dass sie erwartungsgemäß abgerufen werden, wenn Sie etwas wie git fetch Origin ausführen. Alle Remote-Verzweigungen (in der geklonten Remote) und andere Referenzen werden vollständig ignoriert.

  • git clone --bare Origin-url: Sie erhalten alle Tags kopiert, lokale Verzweigungen master (HEAD), next, pu und maint, keine Fernverfolgungszweige. Das heißt, alle Zweige werden unverändert kopiert und sind völlig unabhängig voneinander eingerichtet, ohne dass ein erneutes Abrufen erwartet wird. Alle Remote-Verzweigungen (in der geklonten Remote) und andere Refs werden vollständig ignoriert.

  • git clone --mirror Origin-url: Jeder letzte dieser Refs wird unverändert kopiert. Sie erhalten alle Tags, lokale Zweige master (HEAD), next, pu und maint, ferne Zweige devA/master und devB/master, andere refs refs/foo/bar und refs/foo/baz. Alles ist genau so, wie es in der geklonten Fernbedienung war. Remote-Tracking ist so eingerichtet, dass beim Ausführen von git remote update alle Refs von Origin überschrieben werden, als ob Sie den Spiegel gerade gelöscht und erneut geklont hätten. Wie die Dokumentation ursprünglich sagte, ist es ein Spiegel. Es soll eine funktionsidentische Kopie sein, die mit dem Original austauschbar ist.

507
Cascabel
$ git clone --mirror $URL

ist eine Abkürzung für

$ git clone --bare $URL
$ (cd $(basename $URL) && git remote add --mirror=fetch Origin $URL)

(Direkt kopiert von hier )

Wie es die aktuelle Manpage ausdrückt:

Im Vergleich zu --bare ordnet --mirror nicht nur lokale Zweige der Quelle lokalen Zweigen des Ziels zu, sondern ordnet alle Verweise (einschließlich entfernter Zweige, Notizen usw.) zu und richtet eine solche Verweiskonfiguration ein Diese Referenzen werden durch einen git remote update im Ziel-Repository überschrieben.

48
hfs

Meine heutigen Tests mit git-2.0.0 haben ergeben, dass die Option --mirror keine Hooks, die Konfigurationsdatei, die Beschreibungsdatei, die Info/Exclude-Datei und zumindest in meinem Testfall einige Refs (die ich nicht benutze) kopiert. Ich würde es nicht als "funktionsidentische Kopie, austauschbar mit dem Original" bezeichnen.

-bash-3.2$ git --version
git version 2.0.0
-bash-3.2$ git clone --mirror /git/hooks
Cloning into bare repository 'hooks.git'...
done.

-bash-3.2$ diff --brief -r /git/hooks.git hooks.git
Files /git/hooks.git/config and hooks.git/config differ
Files /git/hooks.git/description and hooks.git/description differ
...
Only in hooks.git/hooks: applypatch-msg.sample
...
Only in /git/hooks.git/hooks: post-receive
...
Files /git/hooks.git/info/exclude and hooks.git/info/exclude differ
...
Files /git/hooks.git/packed-refs and hooks.git/packed-refs differ
Only in /git/hooks.git/refs/heads: fake_branch
Only in /git/hooks.git/refs/heads: master
Only in /git/hooks.git/refs: meta
24

Eine nuancierte Erklärung aus der GitHub-Dokumentation zu Duplizieren eines Repositorys :

Wie bei einem nackten Klon enthält ein gespiegelter Klon alle Remote-Verzweigungen und -Tags, aber alle lokalen Referenzen werden bei jedem Abruf überschrieben, sodass sie immer mit dem ursprünglichen Repository identisch sind.

12
Feckmore

Ein Klon kopiert die Referenzen von der Fernbedienung und fügt sie in ein Unterverzeichnis mit dem Namen "Dies sind die Referenzen, über die die Fernbedienung verfügt" ein.

Ein Spiegel kopiert die Refs von der Fernbedienung und legt sie auf eine eigene oberste Ebene - er ersetzt seine eigenen Refs durch die der Fernbedienung.

Das heißt, wenn jemand aus Ihrem Spiegel zieht und die Refs des Spiegels in sein Unterverzeichnis stopft, erhält er dieselben Refs wie auf dem Original. Das Ergebnis des Abrufs von einem aktuellen Spiegel entspricht dem Abruf direkt aus dem ursprünglichen Repo.

12
PaulMurrayCbr

Ich füge ein Bild hinzu, zeige configDifferenz zwischen Spiegel und blank. enter image description here Die linke Seite ist nackt, die rechte Seite ist Spiegel. Sie können sich darüber klar sein, dass die Konfigurationsdatei des Spiegels den Schlüssel fetch hat, was bedeutet, dass Sie sie mit git remote update oder git fetch --all aktualisieren können.

12
yanzi1225627
$ git clone --bare https://github.com/example

Dieser Befehl macht das Neue selbst zum $ GIT_DIR. Auch die Abzweigköpfe der Gegenstelle werden ohne Zuordnung direkt in die entsprechenden lokalen Abzweigköpfe kopiert. Wenn diese Option verwendet wird, werden weder Remote-Tracking-Zweige noch die zugehörigen Konfigurationsvariablen erstellt.

$ git clone --mirror https://github.com/example

Wie bei einem nackten Klon enthält ein gespiegelter Klon alle Remote-Zweige und -Tags, aber alle lokalen Referenzen (einschließlich Remote-Tracking-Zweige, Notizen usw.) werden bei jedem Abruf überschrieben, sodass sie immer mit dem ursprünglichen Repository identisch sind .

2
Shantanu Singh