Pobierz określony tag za pomocą Git

Próbuję dowiedzieć się, w jaki sposób mogę pobrać konkretny tag repozytorium Git - jest to jedna wersja za bieżącą wersją.

Widziałem, że na stronie internetowej git był tag poprzedniej wersji, z nazwą obiektu czegoś o długiej liczbie szesnastkowej.

Ale nazwa strony to „ Tagged release 1.1.5” zgodnie z witryną.

Próbowałem takiego polecenia (ze zmienionymi nazwami):

git clone http://git.abc.net/git/abc.git my_abc

I dostałem coś - katalog, kilka podkatalogów itp.

Jeśli to całe repozytorium, jak mogę uzyskać wersję, której szukam? Jeśli nie, jak mogę pobrać tę konkretną wersję?

$ git clone

da ci całe repozytorium.

Po sklonowaniu możesz wyświetlić tagi za pomocą, $ git tag -la następnie pobrać konkretny tag:

$ git checkout tags/<tag_name>

Co więcej, sprawdź i utwórz gałąź (w przeciwnym razie będziesz w gałęzi nazwanej na podstawie numeru zmiany znacznika):

$ git checkout tags/<tag_name> -b <branch_name>

git clone --branch my_abc http://git.abc.net/git/abc.git

Sklonuje repozytorium i pozostawi Cię na tagu, który Cię interesuje.

Dokumentacja dla 1.8.0 stanów klonowania git .

--branch może również pobierać tagi i odłącza HEAD przy tym zatwierdzeniu w wynikowym repozytorium.

Do sprawdzenia tylko danego tagu do wdrożenia używam np .:

git clone -b 'v2.0' --single-branch --depth 1 https://github.com/git/git.git

To wydaje się być najszybszym sposobem na sprawdzenie kodu ze zdalnego repozytorium, jeśli interesuje go tylko najnowszy kod zamiast pełnego repozytorium. W ten sposób przypomina polecenie „svn co”.

Uwaga: Zgodnie z instrukcją Git przekazanie --depthflagi --single-branchdomyślnie oznacza .

--głębokość

Utwórz płytki klon z historią obciętą do określonej liczby zatwierdzeń. Sugeruje - pojedyncza gałąź, chyba że - nie podano jednej gałęzi, aby pobrać historie blisko wierzchołków wszystkich gałęzi. Jeśli chcesz płytko sklonować submoduły, przekaż również --shallow-submoduły.

Nie jestem ekspertem od gitów, ale myślę, że to powinno działać:

git clone http://git.abc.net/git/abc.git
cd abc
git checkout my_abc 

LUB

git clone http://git.abc.net/git/abc.git
cd abc
git checkout -b new_branch my_abc

Druga odmiana ustanawia nową gałąź opartą na znaczniku, co pozwala uniknąć „odłączonej HEAD”. (instrukcja git-checkout)

Każde repozytorium git zawiera całą historię zmian, więc klonowanie repozytorium daje dostęp do ostatniego zatwierdzenia, a także wszystkiego, co było wcześniej, w tym znacznika, którego szukasz.

Możesz użyć archiwum git, aby pobrać tar tar dla danego znacznika lub zatwierdzić identyfikator:

git archive --format=tar --remote=[hostname]:[path to repo] [tag name] > tagged_version.tar

Możesz także wyeksportować archiwum zip tagu.

1. Tagi listy:

   git tag
   
   0.0.1
   0.1.0
   

2. Wyeksportuj tag:

   git archive -o /tmp/my-repo-0.1.0.zip --prefix=my-repo-0.1.0/ 0.1.0
   

3. Uwagi:

   • Nie musisz określać formatu. Zostanie on pobrany z nazwy pliku wyjściowego.
   • Podanie prefiksu spowoduje, że kod zostanie wyeksportowany do katalogu (jeśli dołączasz ukośnik).

Użyj --single-branchprzełącznika (dostępny od Git 1.7.10) . Składnia jest następująca:

git clone -b <tag_name> --single-branch <repo_url> [<dest_dir>] 

Na przykład:

git clone -b 'v1.9.5' --single-branch https://github.com/git/git.git git-1.9.5

Korzyści: Git otrzyma obiekty i (musi) rozwiązać delty tylko dla określonej gałęzi / tagu - jednocześnie sprawdzając dokładnie taką samą liczbę plików! W zależności od repozytorium źródłowego pozwoli to zaoszczędzić dużo miejsca na dysku. (Plus będzie znacznie szybciej.)

najpierw pobierz wszystkie tagi z tego konkretnego pilota

git fetch <remote> 'refs/tags/*:refs/tags/*'

lub po prostu wpisz

git fetch <remote>

Następnie sprawdź dostępne tagi

git tag -l

następnie przełącz się na ten konkretny znacznik za pomocą polecenia poniżej

git checkout tags/<tag_name>

Mam nadzieję, że to ci pomoże!

Jeśli tagi można sortować za pomocą sortpolecenia linux , użyj tego:

git tag | sort -n | tail -1

na przykład. jeśli git tagzwraca:

v1.0.1
v1.0.2
v1.0.5
v1.0.4

git tag | sort -n | tail -1 wyświetli:

v1.0.5

git tag | sort -n | tail -2 | head -1 wyświetli:

v1.0.4

(ponieważ poprosiłeś o drugi najnowszy tag)

aby pobrać tag, najpierw sklonuj repozytorium, a następnie wpisz:

git checkout v1.0.4

... lub cokolwiek potrzebujesz.

Sprawdziłem dokumentację kasy git , ujawniła jedną interesującą rzecz:

git checkout -b <nazwa_gałęzi>> <start_point>, gdzie <start_point> jest nazwą zatwierdzenia, od którego ma rozpocząć się nowa gałąź; Domyślnie HEAD

Możemy więc wspomnieć o nazwie znacznika (ponieważ znacznik jest niczym innym jak nazwą zatwierdzenia), jak powiedzmy:

>> git checkout -b 1.0.2_branch 1.0.2
później, zmodyfikuj niektóre pliki
>> git push --tags

PS: W Git nie możesz aktualizować tagu bezpośrednio (ponieważ tag jest tylko etykietą do zatwierdzenia), musisz sprawdzić ten sam tag jako gałąź, a następnie zatwierdzić go, a następnie utworzyć osobny tag.

git fetch <gitserver> <remotetag>:<localtag>

===================================

Właśnie to zrobiłem. Najpierw upewniłem się, że znam pisownię nazwy tagu.

git ls-remote --tags gitserver; : or origin, whatever your remote is called

To dało mi listę tagów na moim serwerze git do wyboru. Oryginalny plakat znał już jego tag, więc ten krok nie jest konieczny dla wszystkich. Dane wyjściowe wyglądały tak, chociaż rzeczywista lista była dłuższa.

8acb6864d10caa9baf25cc1e4857371efb01f7cd    refs/tags/v5.2.2.2
f4ba9d79e3d760f1990c2117187b5010e92e1ea2    refs/tags/v5.2.3.1
8dd05466201b51fcaf4ca85897347d82fcb29518    refs/tags/Fix_109
9b5087090d9077c10ba22d99d5ce90d8a45c50a3    refs/tags/Fix_110

Wybrałem tag, który chciałem, i przyniosłem to, i nic więcej, jak następuje.

git fetch gitserver Fix_110

Następnie oznaczyłem to tagiem na moim komputerze lokalnym, nadając tagowi tę samą nazwę.

git tag Fix_110 FETCH_HEAD

Nie chciałem klonować zdalnego repozytorium, jak sugerowali inni, ponieważ projekt, nad którym pracuję, jest duży i chcę się rozwijać w ładnym, czystym środowisku. Wydaje mi się, że jest to bliższe oryginalnym pytaniom „Próbuję dowiedzieć się, jak pobrać SZCZEGÓŁOWY TAG” niż rozwiązanie sugerujące klonowanie całego repozytorium. Nie rozumiem, dlaczego ktoś powinien mieć kopię kodu źródłowego Windows NT i Windows 8.1, jeśli chce na przykład zobaczyć kod źródłowy DOS 0.1.

Nie chciałem też używać CHECKOUT, jak sugerowali inni. Sprawdziłem oddział i nie chciałem na to wpływać. Moim zamiarem było pobranie oprogramowania, które chciałem, aby móc wybrać coś i dodać to do mojego rozwoju.

Prawdopodobnie istnieje sposób, aby pobrać sam tag, a nie tylko kopię zatwierdzonego tagu. Sam musiałem oznaczyć pobrane zobowiązanie. EDYCJA: Ach tak, znalazłem to teraz.

git fetch gitserver Fix_110:Fix_110

Gdzie widzisz dwukropek, to jest nazwa-zdalna: nazwa-lokalna i tutaj są to nazwy znaczników. Działa to bez naruszania działającego drzewa itp. Wygląda na to, że kopiujesz rzeczy ze zdalnego na lokalny komputer, więc masz własną kopię.

git fetch gitserver --dry-run Fix_110:Fix_110

z dodaną opcją --dry-run pozwoli ci zobaczyć, co zrobi polecenie, jeśli chcesz zweryfikować, co chcesz. Myślę więc, że prosty

git fetch gitserver remotetag:localtag

to prawdziwa odpowiedź.

=

Oddzielna uwaga na temat tagów ... Kiedy zaczynam coś nowego, zwykle odtąd oznaczam puste repozytorium po git init

git rebase -i XXXXX 

wymaga zatwierdzenia, a powstaje pytanie „w jaki sposób wyliczyć zmiany obejmujące pierwszą zmianę oprogramowania?” Kiedy zaczynam pracę, robię to

git init
touch .gitignore
[then add it and commit it, and finally]
git tag EMPTY

tzn. utwórz zatwierdzenie przed moją pierwszą prawdziwą zmianą, a następnie użyj

git rebase -i EMPTY 

jeśli chcę zmienić podstawę całej mojej pracy, w tym pierwszej zmiany .

Opierając się na odpowiedzi Petera Johnsona, stworzyłem dla siebie ładny alias:

alias gcolt="git checkout $(git tag | sort -V | tail -1)"

aka „git checkout latest tag”.

Zależy to od rodzaju GNU, która odpowiednio radzi sobie z sytuacjami takimi, jak wskazał LOranger:

v1.0.1
...
v1.0.9
v1.0.10

Jeśli używasz komputera Mac, brew install coreutilszamiast tego zadzwoń do gsort.

próbować:

git clone -b <name_of_the_tag> <repository_url> <destination>

Sprawdzanie tagów

Jeśli chcesz wyświetlić wersje plików, na które wskazuje znacznik, możesz zrobić kasę git, ale powoduje to, że repozytorium znajduje się w stanie „odłączonej HEAD”, co ma pewne niepożądane skutki uboczne:

$ git checkout 2.0.0
Note: checking out '2.0.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final

$ git checkout 2.0-beta-0.1
Previous HEAD position was 99ada87... Merge pull request #89 from schacon/appendix-final
HEAD is now at df3f601... add atlas.json and cover image

W stanie „odłączony HEAD”, jeśli wprowadzisz zmiany, a następnie utworzysz zatwierdzenie, tag pozostanie taki sam, ale twój nowy zatwierdzenie nie będzie należeć do żadnej gałęzi i będzie nieosiągalny, z wyjątkiem dokładnego skrótu zatwierdzenia. Dlatego jeśli chcesz wprowadzić zmiany - na przykład naprawiasz błąd w starszej wersji - na ogół będziesz chciał utworzyć gałąź:

$ git checkout -b version2 v2.0.0
Switched to a new branch 'version2'

Jeśli to zrobisz i zatwierdzisz, twoja gałąź version2 będzie się nieznacznie różnić od tagu v2.0.0, ponieważ będzie postępować z nowymi zmianami, więc bądź ostrożny.

Robię to poprzez interfejs API github:

curl -H "Authorization: token %(access_token)s" -sL -o /tmp/repo.tar.gz "http://api.github.com/repos/%(organisation)s/%(repo)s/tarball/%(tag)s" ;\
tar xfz /tmp/repo.tar.gz -C /tmp/repo --strip-components=1 ; \