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.5uż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, -rale 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 --hardlokalną 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
--depthco 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 clonekonkretną wersję, wykonując tę czynność checkout <rev>.
git clonepobiera 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 NAMEmoże to być tylko nazwa oddziału lub nazwa znacznika (nie zatwierdzaj SHA).
Pomiń --depthflagę, 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 clonetam, 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 --hardgit checkout -b mastermasteri 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 -kzdalnego wybierania, a następnie użyć git push origindo przesłania całej partii z powrotem do jej nowego domu.
Mam nadzieję, że komuś pomoże
git fetch local_copy origin_pointróżni się twój od JamesGs git fetch origin refs/tags/tmptag?
git fetch local_copy origin_pointZostawiają cię w stanie pustym reduced-repokatalogu, 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=truepo 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>
gitużywa tego słowa originzamiast 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=1nie 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ę, 8a28d674a nie, 896066ee jak twierdzisz i ta odpowiedź.
git clone -b 10.1 https://github.com/MariaDB/server.git --depth=1 mariadb-server-src