Скачать определенный тег в Git

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

клонирует РЕПО и оставит вас на интересующем вас теге.

документация для 1.8.0 git clone государства.

--branch также может принимать теги и отсоединять головку при фиксации в результирующем репозитории.

Я не эксперт git, но я думаю, что это должно работать:

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

или

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

второй вариант устанавливает новую ветвь на основе тега, что позволяет избежать "отсоединенной головы". (git-checkout manual)

каждое РЕПО git содержит всю историю изменений, поэтому клонирование РЕПО дает вам доступ к последней фиксации плюс все, что было раньше, включая тег, который вы ищете.

для проверки только данного тега для развертывания я использую, например:

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

Это, по-видимому, самый быстрый способ проверить код из удаленного репозитория, если вас интересует только самый последний код, а не полный репозиторий. Таким образом, он напоминает команду "svn co".

вы можете использовать архив git для загрузки шара tar для данного тега или фиксации id:

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

вы также можете экспортировать zip-архив тега.

1. список тэгов:

   git tag
   
   0.0.1
   0.1.0
   

2. экспорт тег:

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

3. Примечания:

   • вам не нужно указывать формат. Он будет подобран по имени выходного файла.
   • указание префикса сделает ваш код экспорт в a каталог (если вы включаете завершающий Слэш).

использовать --single-branch переключатель (доступно с Git 1.7.10). Синтаксис:

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

например:

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

преимущество: Git будет получать объекты и (нужно) разрешать дельты только для указанной ветви/тега - при проверке точно такого же количества файлов! В зависимости от исходного репозитория это сэкономит вам много места на диске. (Кроме того, это будет намного быстрее.)

сначала извлеките все теги в этом конкретном удаленном

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

или просто типа

git fetch <remote>

затем проверьте наличие доступных тегов

git tag -l

затем переключитесь на этот конкретный тег, используя команду ниже

git checkout tags/<tag_name>

надеюсь, это поможет вам!

Я проверил git проверка документации, Он показал одну интересную вещь:

git checkout-b , где - это имя фиксации с чего начать новую ветку; По умолчанию HEAD

поэтому мы можем упомянуть имя тега( поскольку тег-это не что иное, как имя фиксации), как, скажем:

>> git checkout-b 1.0.2_branch 1.0.2
позже, изменить некоторые файлы
>> git push --tags

P. S: в Git вы не можете обновить тег напрямую(поскольку тег-это просто метка для фиксации), вам нужно проверить тот же тег, что и ветвь, а затем зафиксировать его, а затем создать отдельный тег.

если ваши теги сортируются с помощью linux sort команда, используйте этот:

git tag | sort -n | tail -1

например. если git tag возвращает:

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

git tag | sort -n | tail -1 вывод:

v1.0.5

git tag | sort -n | tail -2 | head -1 вывод:

v1.0.4

(потому что вы попросили второй самый последний тег)

чтобы проверить тег, сначала клонируйте РЕПО, затем введите:

git checkout v1.0.4

..или какой тебе нужен ярлык.

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

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

Я только что сделал это. Сначала я убедился, что знаю написание имени тега.

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

это дало мне список тегов на моем сервере git на выбор. Оригинальный плакат уже знал имя своего тега, поэтому этот шаг не нужен для всех. Результат выглядел так, хотя реальный список был длиннее.

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

Я выбрал тег, который я хотел, и принес это и ничего больше, как следует.

git fetch gitserver Fix_110

затем я пометил это на своей локальной машине, дав моему тегу то же имя.

git tag Fix_110 FETCH_HEAD

Я не хотел клонировать удаленный репозиторий, как предлагали другие люди, поскольку проект, над которым я работаю, большой, и я хочу развиваться в хорошей чистой среде. Я чувствую, что это ближе к исходным вопросам "я пытаюсь выяснить, как загрузить конкретный тег", чем решение, которое предлагает клонировать весь репозиторий. Не понимаю, почему. любой должен иметь копию исходного кода Windows NT и Windows 8.1, если они хотят посмотреть исходный код DOS 0.1 (например).

Я также не хотел использовать CHECKOUT, как предлагали другие. Я проверил филиал и не хотел на это влиять. Мое намерение состояло в том, чтобы принести программное обеспечение, которое я хотел, чтобы я мог выбрать что-то вишневое и добавить это к моему развитию.

вероятно, есть способ получить сам тег, а не только копию фиксации это было помечено. Я должен был пометить принесенное обязательство сам. EDIT: Ах да, я нашел его сейчас.

git fetch gitserver Fix_110:Fix_110

где вы видите двоеточие, это remote-name: local-name, и здесь они являются именами тегов. Это выполняется без опрокидывания рабочего дерева и т. д. Кажется, что он просто копирует материал с пульта на локальную машину, чтобы у вас была своя копия.

git fetch gitserver --dry-run Fix_110:Fix_110

С -- dry-run опция добавлена позволит вам взглянуть на то, что команда будет делать, если вы хотите проверить его, что вы хотите. Так что я думаю простой

git fetch gitserver remotetag:localtag

реальный ответ.

=

отдельная заметка о тегах ... Когда я начинаю что-то новое, я обычно помечаю пустой репозиторий после git init, так как

git rebase -i XXXXX 

требует фиксации, и возникает вопрос "как вы перебазировать изменения, которые включают в свой первой смены программного обеспечения?- Значит, когда я начинаю работать, я делаю!--12-->

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

т. е. создайте фиксацию до моего первого реального изменения, а затем позже использовать

git rebase -i EMPTY 

если я хочу перебазировать всю свою работу,в том числе в первую смену.

работая над ответом Питера Джонсона, я создал для себя хороший маленький псевдоним:

alias gcolt="git checkout \`git tag | sort -V | tail -1\`"

Он же "git checkout последний тег".

Это зависит от версии GNU sort, которая соответствующим образом обрабатывает ситуации, подобные той, на которую указал Лорангер:

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

Если вы на mac,brew install coreutils а затем вместо этого вызовите gsort.

попробуй:

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

проверка тегов

Если вы хотите просмотреть версии файлов, на которые указывает тег, вы можете выполнить проверку git, хотя это помещает ваш репозиторий в состояние "отсоединенная голова", которое имеет некоторые побочные эффекты:

$ 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

в состоянии "отсоединенная голова", если вы внесете изменения, а затем создадите фиксацию, тег останется прежним, но ваш новый фиксатор не будет принадлежать какой-либо ветви и будет недоступен, за исключением точного хэша фиксации. Таким образом, если вам нужно чтобы внести изменения-скажем, вы исправляете ошибку в старой версии, например, - вы обычно хотите создать ветку:

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

Если вы сделаете это и сделаете фиксацию, ваша ветвь version2 будет немного отличаться от вашей v2.0.0 тег, так как он будет двигаться вперед с вашими новыми изменениями, поэтому будьте осторожны.

Я делаю это через 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 ; \

клон с опцией-b также помогает: git clone https://git01.codeplex.com/aspnetwebstack.git - b v2.0

следующий пост использует вышеуказанную опцию для загрузки asp.net mvc: http://vijayt.com/Post/Setting-up-aspnet-mvc-for-debugging-in-your-system