Загрузите определенный тег с помощью Git

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

Будет клонировать репо и оставить вас на интересующем вас теге.

Документация для 1.8.5.2 состояний git clone.

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

Я не эксперт 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

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

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

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

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

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

• Список тегов:

  git tag
  
  0.0.1
  0.1.0
  

• Экспортировать тег:

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

• Примечание:

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

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

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

Кажется, это самый быстрый способ проверить код из удаленного репозитория, если у вас есть интерес только к самому последнему коду, а не к полному репозиторию. Таким образом, он напоминает команду svn co.

Используйте переключатель --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>

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

Если ваши теги сортируются с помощью команды 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 документацию по проверке, он обнаружил одну интересную вещь:

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

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

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

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

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

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

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

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

git fetch gitserver Fix_110:Fix_110

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

git fetch gitserver --dry-run Fix_110:Fix_110

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

git fetch gitserver remotetag:localtag

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

=

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

git rebase -i XXXXX 

требуется фиксация, и возникает вопрос: "Как вы можете изменить изменения, которые включают в себя ваше первое изменение программного обеспечения?" Поэтому, когда я начинаю работать, я делаю

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\`"

aka 'git последний тег checkout.

Это зависит от версии рода GNU, которая надлежащим образом обрабатывает ситуации, подобные указанному lOranger:

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, хотя это помещает ваш репозиторий в состояние "отсоединенный HEAD", у которого есть некоторые побочные эффекты:

$ 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

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

$ 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