Jak mogę sklonować repozytorium git z określoną wersją, jak zwykle w Mercurial:
hg clone -r 3 /path/to/repository
Jak mogę sklonować repozytorium git z określoną wersją, jak zwykle w Mercurial:
hg clone -r 3 /path/to/repository
Odpowiedzi:
AKTUALIZACJA 2 Od wersji Git 2.5.0 opisaną poniżej funkcję można włączyć po stronie serwera za pomocą zmiennej konfiguracyjnej uploadpack.allowReachableSHA1InWant
, tutaj żądanie funkcji GitHub i zatwierdzenie GitHub włączające tę funkcję . Pamiętaj, że niektóre serwery Git domyślnie aktywują tę opcję, np. Serwer Bitbucket włączył ją od wersji 5.5+ . Zobacz tę odpowiedź na Stackexchange aby dowiedzieć się, jak aktywować opcję konfiguracji.
AKTUALIZACJA 1 W przypadku wersji Git 1.7 < v < 2.5
użyj klonowania git i resetowania git, jak opisano w Vaibhav Bajpai
Jeśli nie chcesz pobrać pełnego repozytorium, prawdopodobnie nie powinieneś go używać clone
. Zawsze możesz po prostu użyć opcji Pobierz, aby wybrać gałąź, którą chcesz pobrać. Nie jestem ekspertem od hg, więc nie znam szczegółów, -r
ale w git możesz zrobić coś takiego.
# make a new blank repository in the current directory
git init
# add a remote
git remote add origin url://to/source/repository
# fetch a commit (or branch or tag) of interest
# Note: the full history up to this commit will be retrieved unless
# you limit it with '--depth=...' or '--shallow-since=...'
git fetch origin <sha1-of-commit-of-interest>
# reset this repository's master branch to the commit of interest
git reset --hard FETCH_HEAD
git fetch origin <sha1>
działa; wygląda na to, że musisz przekazać nazwane odwołanie, takie jak tag lub nazwa oddziału. Zobacz kerneltrap.org/mailarchive/git/2009/1/13/4707444
git fetch origin <SHA1>
aby przełączyć się na dowolną wersję, którą chciałem po tym, jak ściągnąłem mistrza ze zdalnego i wykonałem reset --hard
lokalną instancję w celu rzeczywistego utworzenia gałęzi. Nie mogłem pobrać poszczególnych wersji bezpośrednio. Z git 1.7 git fetch origin <SHA1>
nie działało, jak donosi @artur; musisz użyć, git checkout <SHA1>
a następnie reset --hard
.
$ git clone $URL
$ cd $PROJECT_NAME
$ git reset --hard $SHA1
Aby ponownie wrócić do ostatniego zatwierdzenia
$ git pull
--depth
co jest bardzo ważne w przypadku dużych repozytoriów. To rozwiązanie wymaga wyciągnięcia wszystkich obiektów, a następnie zresetowania do wcześniejszej wersji. Jest to bardzo czasochłonne i marnuje przepustowość sieci.
Klonowanie repozytorium git trafnie klonuje całe repozytorium: nie ma sposobu, aby wybrać tylko jedną wersję do sklonowania. Jednak po wykonaniu możesz sprawdzić git clone
konkretną wersję, wykonując tę czynność checkout <rev>
.
git clone
pobiera całe repozytorium. Gdy już go masz, możesz następnie pobrać konkretną wersję.
git clone --single-branch ...
Aby sklonować tylko jeden konkretny zatwierdzenie dla określonej gałęzi lub tagu użyj:
git clone --depth=1 --branch NAME https://github.com/your/repo.git
Niestety NAME
może to być tylko nazwa oddziału lub nazwa znacznika (nie zatwierdzaj SHA).
Pomiń --depth
flagę, aby pobrać całą historię, a następnie sprawdź tę gałąź lub tag:
git clone --branch NAME https://github.com/your/repo.git
Działa to z najnowszą wersją git (zrobiłem to z wersją 2.18.0
).
Jeśli masz na myśli, że chcesz pobrać wszystko od początku do określonego punktu, odpowiedź Charlesa Baileya jest idealna. Jeśli chcesz zrobić odwrotną stronę i odzyskać podzbiór historii cofający się od bieżącej daty, możesz użyć git clone --depth [N]
gdzie N to liczba obrotów historii, którą chcesz. Jednak:
--głębokość
Utwórz płytki klon z historią obciętą do określonej liczby wersji. Płytkie repozytorium ma wiele ograniczeń (nie można go klonować ani pobierać z niego, ani wypychać z niego ani do niego), ale jest wystarczające, jeśli interesuje Cię tylko najnowsza historia dużego projektu z długą historią i chciałbyś wysyłaj poprawki jako łatki.
Podsumowując (git v. 1.7.2.1):
git clone
tam, gdzie chcesz repo (dostaje wszystko na bieżąco - wiem, nie to, co jest potrzebne, my się tam dostaniemy) git checkout <sha1 rev>
pożądanej prędkościgit reset --hard
git checkout -b master
master
i przełącza się na nią.
git reset --hard
? Dokumenty tego mówią: „Resetuje indeks i działające drzewo. Wszelkie zmiany w śledzonych plikach w działającym drzewie od czasu <commit> [domyślna wartość HEAD, która jest teraz <sha1 rev>
] są odrzucane”. Ale w tym momencie nie dokonaliśmy żadnych zmian od klonowania, więc jaki jest cel? Czy to obcina obecną gałąź <sha1 rev>
?
TL; DR - po prostu utwórz znacznik w repozytorium źródłowym dla zatwierdzenia, do którego chcesz sklonować, i użyj znacznika w poleceniu fetch. Możesz usunąć tag z oryginalnego repozytorium później, aby go wyczyścić.
No cóż, jego 2014 rok i wygląda na to, że zaakceptowana przez Charlesa Baileya odpowiedź z 2010 roku jest już naprawdę i naprawdę nieaktualna, a większość (wszystkich?) Innych odpowiedzi dotyczy klonowania, którego wiele osób chce uniknąć.
Poniższe rozwiązanie osiąga to, czego szuka OP i wielu innych, co jest sposobem na utworzenie kopii repozytorium, w tym historii, ale tylko do pewnego zatwierdzenia.
Oto polecenia, których użyłem z git w wersji 2.1.2, aby sklonować lokalne repozytorium (tj. Repozytorium w innym katalogu) do pewnego momentu:
# in the source repository, create a tag against the commit you want to check out
git tag -m "Temporary tag" tmptag <sha1>
# create a new directory and change into that directory
cd somewhere_else;mkdir newdir;cd newdir
# ...and create a new repository
git init
# add the source repository as a remote (this can be a URL or a directory)
git remote add origin /path/to/original/repo
# fetch the tag, which will include the entire repo and history up to that point
git fetch origin refs/tags/tmptag
# reset the head of the repository
git reset --hard FETCH_HEAD
# you can now change back to the original repository and remove the temporary tag
cd original_repo
git tag -d tmptag
Mam nadzieję, że to rozwiązanie będzie działać jeszcze przez kilka lat! :-)
Możesz użyć po prostu git checkout <commit hash>
w tej sekwencji
bash
git clone [URLTORepository]
git checkout [commithash]
zatwierdzenie skrótu wygląda tak: „45ef55ac20ce2389c9180658fdba35f4a663d204”
Korzystanie z 2 powyższych odpowiedzi ( Jak sklonować repozytorium git z konkretną wersją / zmianą? I Jak sklonować repozytorium git z określoną zmianą / zmianą? ) Pomogło mi wymyślić definicję. Jeśli chcesz sklonować do pewnego momentu, to musi to być znacznik / gałąź, a nie tylko SHA, w przeciwnym razie FETCH_HEAD się myli. Zgodnie z zestawem pobierania git, jeśli użyjesz nazwy gałęzi lub tagu, otrzymasz odpowiedź, jeśli po prostu użyjesz SHA-1, nie otrzymasz odpowiedzi.
Oto co zrobiłem: - stwórz w pełni działający klon pełnego repozytorium, z faktycznego pochodzenia
cd <path to create repo>
git clone git@<our gitlab server>:ui-developers/ui.git
Następnie utwórz lokalny oddział w interesującym punkcie
git checkout 2050c8829c67f04b0db81e6247bb589c950afb14
git checkout -b origin_point
Następnie utwórz moje nowe puste repozytorium, z oryginalną kopią lokalną
cd <path to create repo>
mkdir reduced-repo
cd reduced-repo
git init
git remote add local_copy <path to create repo>/ui
git fetch local_copy origin_point
W tym momencie otrzymałem tę odpowiedź. Zwracam na to uwagę, ponieważ jeśli użyjesz SHA-1 zamiast gałęzi powyżej, nic się nie dzieje, więc odpowiedź oznacza, że zadziałało
/ var / www / html / ui-hacking $ git fetch plik_lokalny punkt_początkowy pilot: Zliczanie obiektów: 45493, gotowe. zdalne: Kompresowanie obiektów: 100% (15928/15928), gotowe. zdalne: Razem 45493 (delta 27508), ponownie wykorzystane 45387 (delta 27463) Otrzymywanie przedmiotów: 100% (45493/45493), 53,64 MiB | 50,59 MiB / s, gotowe. Rozwiązywanie delt: 100% (27508/27508), gotowe. Z / var / www / html / ui * gałąź origin_point -> FETCH_HEAD * [nowa gałąź] origin_point -> origin / origin_point
Teraz w moim przypadku musiałem odłożyć to z powrotem na gitlab, jako świeże repo, więc zrobiłem to
git remote add origin git@<our gitlab server>:ui-developers/new-ui.git
Co oznaczało, że mogłem odbudować moje repozytorium z punktu początkowego za pomocą git --git-dir=../ui/.git format-patch -k -1 --stdout <sha1> | git am -3 -k
zdalnego wybierania, a następnie użyć git push origin
do przesłania całej partii z powrotem do jej nowego domu.
Mam nadzieję, że komuś pomoże
git fetch local_copy origin_point
różni się twój od JamesGs git fetch origin refs/tags/tmptag
?
git fetch local_copy origin_point
Zostawiają cię w stanie pustym reduced-repo
katalogu, zawierająca tylko .git
. Tych instrukcji brakuje jeszcze coś ...
Moja wersja była kombinacją zaakceptowanych i najbardziej pozytywnych odpowiedzi. Ale jest trochę inaczej, ponieważ wszyscy używają SHA1, ale nikt nie mówi ci, jak go zdobyć
$ git init
$ git remote add <remote_url>
$ git fetch --all
teraz możesz zobaczyć wszystkie oddziały i zobowiązania
$ git branch -a
$ git log remotes/origin/master <-- or any other branch
Wreszcie znasz SHA1 pożądanego zatwierdzenia
git reset --hard <sha1>
Używam tego fragmentu kodu z GNU make do zamykania dowolnego tagu zmiany, gałęzi lub skrótu
został przetestowany na git w wersji 2.17.1
${dir}:
mkdir -p ${@D}
git clone --recursive --depth 1 --branch ${revison} ${url} ${@} \
|| git clone --recursive --branch ${revison} ${url} ${@} \
|| git clone ${url} ${@}
cd ${@} && git reset --hard ${revison}
ls $@
git clone https://github.com/ORGANIZATION/repository.git
(klonowanie repozytorium)
cd repository (navigate to the repository)
git fetch origin 2600f4f928773d79164964137d514b85400b09b2
git checkout FETCH_HEAD
# clone special tag/branch without history
git clone --branch=<tag/branch> --depth=1 <repository>
# clone special revision with minimal histories
git clone --branch <branch> <repository> --shallow-since=yyyy-MM-ddTHH:mm:ss # get the commit time
cd <dir>
git reset --hard <revision>
nie można uzyskać wersji bez historii, jeśli nie jest ustawiona uploadpack.allowReachableSHA1InWant=true
po stronie serwera, można natomiast utworzyć dla niej znacznik i sklonować znacznik specjalny.
git clone -o <sha1-of-the-commit> <repository-url> <local-dir-name>
git
używa tego słowa origin
zamiast powszechnie znanegorevision
Poniżej znajduje się fragment instrukcji $ git help clone
--origin <name>, -o <name>
Instead of using the remote name origin to keep track of the upstream repository, use <name>.
--depth=1
nie jest wymieniony w odpowiedzi, więc dlaczego miałbyś powiedzieć, że ta odpowiedź zadziałała, jeśli dodałeś więcej rzeczy, które nie zostały tutaj wymienione? Cieszę się, że ci się udało, ale ta odpowiedź jest myląca i nawet częściowo nie odpowiada na pytanie. Stąd opinie negatywne.
git clone <url> <local_dir_name>
, po prostu spróbuj sam. Jedyną różnicą jest to, że zdalny (pokazany za pomocą git remote
) będzie nazywany jakąś tajemniczą sekwencją sha1 zamiast zwyczajowej nazwy „origin”. Innymi słowy, <sha1-of-the-commit>
wspomniana w tej odpowiedzi nie ma żadnego wpływu na to, które wersje są pobierane z serwera lub który oddział zostanie sprawdzony.
git clone -o 896066ee1cf4d653057dac4e952f49c96ad16fa7 https://github.com/torvalds/linux.git linux --depth=1
. To daje mi rewizję, 8a28d674
a nie, 896066ee
jak twierdzisz i ta odpowiedź.
git clone -b 10.1 https://github.com/MariaDB/server.git --depth=1 mariadb-server-src