Jaka jest różnica pomiędzy git clone -- mirror a git clone --bare

Question

Jaka jest różnica pomiędzy git clone -- mirror a git clone --bare

Strona pomocy git clone ma to do powiedzenia o --mirror:

Skonfigurowanie serwera lustrzanego zdalnego repozytorium. Oznacza to --bare.

Ale nie wdaje się w szczegóły o tym, jak klon --mirror różni się od klonu --bare.

516

git git-clone

Author: Steven Penny, 2010-10-18

Source

7 answers

$ git clone --mirror $URL

Jest krótką ręką dla

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

(skopiowane bezpośrednio z tutaj )

Jak przedstawia to aktualna strona podręcznika:

W porównaniu do --bare, --mirror nie tylko mapuje lokalne gałęzie źródła do lokalnych gałęzi celu, mapuje wszystkie refy (w tym odległe gałęzie, notatki itp.) i ustawia konfigurację refspec tak, że wszystkie te refy są nadpisywane przez git remote update w repozytorium docelowym.

63

Author: hfs,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-04-09 01:12:24

Moje dzisiejsze testy z git-2.0.0 wskazują, że opcja -- mirror nie kopiuje hooków, pliku konfiguracyjnego, pliku opisu, pliku info / exclude, a przynajmniej w moim przypadku testowym kilka refów (których nie rozumiem.) Nie nazwałbym tego "funkcjonalnie identyczną kopią, wymienną z oryginałem."

-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

25

Author: Mark E. Hamilton,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-06-17 18:05:09

Klon kopiuje refy z pilota i wpycha je do podkatalogu o nazwie 'są to refy, które posiada pilot'.

Lustro kopiuje refy z pilota i umieszcza je na swoim własnym najwyższym poziomie-zastępuje własne refy z tych z pilota.

Oznacza to, że gdy ktoś wyciągnie z twojego lustra i wypchnie refy lustra do podkatalogu, otrzyma te same refy, co w oryginale. Wynikiem pobierania Z up-to-date mirror jest to samo, co pobieranie bezpośrednio z pierwotnego repo.

15

Author: PaulMurrayCbr,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-07-12 02:33:47

Niuansowe Wyjaśnienie z Dokumentacji GitHub na temat powielania repozytorium :

Podobnie jak w przypadku gołego klona, klon lustrzany zawiera wszystkie zdalne gałęzie i znaczniki, ale wszystkie lokalne odniesienia będą nadpisywane za każdym razem, gdy pobierasz, więc zawsze będzie taki sam jak oryginalne repozytorium.

14

Author: Feckmore,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-04-27 17:25:15

Dodaję zdjęcie, pokazuję configróżnicę między lustrem a gołym. Lewa jest naga, prawa to lustro. Możesz być czysty, plik konfiguracyjny mirrora ma klucz fetch, co oznacza, że możesz go zaktualizować, przez git remote update lub git fetch --all

14

Author: yanzi1225627,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-09-01 08:20:08

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

To polecenie uczyni nowy katalog "example " samym $GIT_DIR (zamiast example/.git). Również głowice odgałęzień na zdalnym są kopiowane bezpośrednio do odpowiednich lokalnych głowic odgałęzień, bez mapowania. Gdy ta opcja jest używana, nie są tworzone ani gałęzie zdalnego śledzenia, ani powiązane zmienne konfiguracyjne.

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

Podobnie jak w przypadku gołego klona, klon lustrzany zawiera wszystkie zdalne gałęzie i tagi, ale wszystkie lokalne odniesienia (w tym gałęzie zdalnego śledzenia, notatki itp.) will być nadpisywane za każdym razem, gdy pobierasz, więc zawsze będzie to to samo, co oryginalne repozytorium.

4

Author: Shantanu Singh,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-12-31 13:03:44

score 611 · Accepted Answer

Różnica polega na tym, że przy użyciu --mirror, wszystkie refy są kopiowane jako . Oznacza to wszystko: zdalne śledzenie gałęzi, notatek, refs / originals / * (kopie zapasowe z filter-branch). Sklonowany repo ma wszystko. Jest również skonfigurowany tak, aby zdalna aktualizacja ponownie pobrała wszystko z źródła (nadpisując skopiowane refy). Chodzi o to, aby lustrzać repozytorium, mieć całkowitą kopię, tak aby można było na przykład hostować Centralne repo w wielu miejscach lub tworzyć kopie zapasowe. Pomyśl o prostym kopiowaniu repo, z wyjątkiem bardziej eleganckiego Gita.

Nowa dokumentacja W zasadzie mówi to wszystko:

--mirror

Skonfigurowanie serwera lustrzanego repozytorium źródłowego. Oznacza to --bare. W porównaniu do --bare, --mirror nie tylko mapuje lokalne gałęzie źródła do lokalnych gałęzi celu, mapuje wszystkie refy (w tym odległe gałęzie, notatki itp.) i ustawia konfigurację refspec taką, że wszystkie te refy są nadpisane przez git remote update w repozytorium docelowym.

Moja oryginalna odpowiedź zwróciła również uwagę na różnice pomiędzy gołym klonem a zwykłym (nie-gołym) klonem - klon nie-gołym ustawia zdalne gałęzie śledzące, tworząc tylko lokalną gałąź dla HEAD, podczas gdy gołym klonem kopiuje gałęzie bezpośrednio.

Przypuśćmy, że pochodzenie ma kilka gałęzi (master (HEAD), next, pu, i maint), niektóre znaczniki (v1, v2, v3), niektóre odległe gałęzie (devA/master, devB/master), i inne refy (refs/foo/bar, refs/foo/baz, które mogą być notatkami, stashami, przestrzeniami nazw innych deweloperów, kto wie).

git clone origin-url (nie-bare): otrzymasz skopiowane wszystkie znaczniki, lokalną gałąź master (HEAD) śledzącą zdalną gałąź origin/master i zdalne gałęzie origin/next, origin/pu, i origin/maint. Gałęzie śledzenia są skonfigurowane tak, że jeśli zrobisz coś podobnego git fetch origin, zostaną pobrane zgodnie z oczekiwaniami. Wszelkie zdalne gałęzie (w sklonowanym zdalnym) i inne refy są całkowicie ignorowane.
git clone --bare origin-url: otrzymasz wszystkie skopiowane tagi, lokalne gałęzie master (HEAD), next, pu, i maint, brak zdalnego śledzenia gałęzi. Oznacza to, że wszystkie gałęzie są kopiowane tak, jak jest i są skonfigurowane całkowicie niezależnie, bez oczekiwania ponownego pobierania. Wszelkie zdalne gałęzie (w sklonowanym zdalnym) i inne refy są całkowicie ignorowane.
git clone --mirror origin-url: każdy z tych refów zostanie skopiowany tak, jak jest. Dostaniesz wszystkie tagi, lokalne oddziały master (HEAD), next, pu, i maint, odległe gałęzie devA/master i devB/master, inne refy refs/foo/bar i refs/foo/baz. Wszystko jest dokładnie takie, jak było w sklonowanym pilocie. Zdalne śledzenie jest skonfigurowane tak, że jeśli uruchomisz git remote update Wszystkie refy zostaną nadpisane z origin, tak jakbyś właśnie usunął lustro i odzyskał je. Jak pierwotnie powiedzieli lekarze, to lustro. Ma być funkcjonalnie identyczną kopią, zamienną z oryginałem.