Ответ 1

Начнем с объяснения, что такое тег в git

Тег используется для маркировки и пометки определенного коммита в истории.
Обычно используется для обозначения точек выпуска (например, v1.0 и т.д.).

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

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

Сначала убедитесь, что тег существует локально, выполнив

# --all will fetch all the remotes.
# --tags will fetch all tags as well
git fetch --all --tags --prune

Затем проверьте тег, запустив

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

Вместо origin используйте префикс tags/.

В этом примере у вас есть 2 тега версии 1.0 & В версии 1.1 вы можете оформить заказ одним из следующих способов:

git checkout A  ...
git checkout version 1.0  ...
git checkout tags/version 1.0  ...

Все вышеперечисленное будет делать то же самое, поскольку тег является только указателем на данный коммит.

происхождение: https://backlog.com/git-tutorial/img/post/stepup/capture_stepup4_1_1.png

Как просмотреть список всех тегов?

# list all tags
git tag

# list all tags with given pattern ex: v-
git tag --list 'v-*'

Как создать теги?

Есть два способа создать тег:

# lightweight tag 
git tag 

# annotated tag
git tag -a

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

Как удалить теги?

# delete any given tag
git tag -d <tag name>

# Don't forget to remove the deleted tag form the server with push tags

Как клонировать определенный тег?

Чтобы получить содержимое данного тега, вы можете использовать команду checkout.
Как объяснялось выше, теги похожи на любые другие коммиты, поэтому мы можем использовать checkout и вместо использования SHA-1 просто заменить его на tag_name

Вариант 1:

# Update the local git repo with the latest tags from all remotes
git fetch --all

# checkout the specific tag
git checkout tags/<tag> -b <branch>

Вариант 2:

Использование команды клонирования

Поскольку git поддерживает мелкое клонирование, добавляя --branch к команде клонирования, мы можем использовать имя тега вместо имени ветки. Git знает, как "перевести" данный SHA-1 в соответствующий коммит

# Clone a specific tag name using git clone 
 git clone <url> --branch=<tag_name>

git clone --branch=

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

Как вставить метки?

git push --tags

Чтобы вставить все теги:

git push --tags 

Для добавления аннотированных тегов и текущих тегов цепочки истории используйте ::

git push --follow-tags

Этот флаг --follow-tags выдвигает оба коммита и только теги, которые оба:

• Аннотированные теги (так что вы можете пропустить локальные/временные теги сборки)
• Доступные теги (предок) из текущей ветки (расположенной в истории)

Из Git 2.4 вы можете установить его, используя конфигурацию

git config --global push.followTags true

Ответ 2

(Этот ответ занял некоторое время, и ответ codeWizard правильный по цели и сути, но не полностью завершен, поэтому я все равно отправлю его.)

Нет такой вещи, как "удаленный тег Git". Есть только "теги". Я указываю, что все это не должно быть педантичным, ¹ но из-за большой беспорядки в этом случае со случайными Git пользователями, а документация Git не очень полезна ² для начинающих. (Неясно, возникает ли путаница из-за плохой документации или плохой документации, потому что это по своей сути несколько запутанно, или что.)

Есть "удаленные ветки", более правильно называемые "ветки удаленного отслеживания", но стоит отметить, что они на самом деле являются локальными объектами. Однако удаленных тегов нет (если вы их не изобретете). Есть только локальные теги, поэтому вам нужно локально получить тег, чтобы использовать его.

Общий вид имен для конкретных коммитов, который Git вызывает ссылки, - это любая строка, начинающаяся с refs/. Строка, начинающаяся с refs/heads/, называет ветку; строка, начинающаяся с refs/remotes/, именует ветку удаленного слежения; и строка, начинающаяся с refs/tags/, называет тег. Имя refs/stash - это ссылка на stash (как используется git stash, обратите внимание на отсутствие конечной косой черты).

Есть несколько необычных имен особых случаев, которые не начинаются с refs/: HEAD, ORIG_HEAD, MERGE_HEAD и CHERRY_PICK_HEAD, в частности, также являются именами, которые могут ссылаться на определенные коммиты (хотя HEAD обычно содержит имя ветки, т.е. содержит ref: refs/heads/branch). Но в целом ссылки начинаются с refs/.

Одна вещь Git делает это запутанным, так это то, что она позволяет опустить refs/, а часто и слово после refs/. Например, вы можете опустить refs/heads/ или refs/tags/ при обращении к локальной ветке или тегу, и на самом деле вы должны опустить refs/heads/ при проверке локальной ветки! Вы можете делать это каждый раз, когда результат однозначен или, как мы только что отметили, - когда вы должны это сделать (для git checkout branch).

Верно, что ссылки существуют не только в вашем собственном репозитории, но и в удаленных репозиториях. Однако Git дает вам доступ к удаленным репозиториальным ссылкам только в очень определенное время: а именно во время операций fetch и push. Вы можете также использовать git ls-remote или git remote show, чтобы увидеть их, но fetch и push - более интересные точки контакта.

Refspecs

Во время fetch и push, Git использует строки, он вызывает refspecs для передачи ссылок между локальным и удаленным репозиториями. Таким образом, именно в эти моменты и через refspecs два хранилища Git могут синхронизироваться друг с другом. После того, как ваши имена синхронизированы, вы можете использовать одно и то же имя, которое использует кто-то с удаленным. Однако в fetch есть некоторая специальная магия, которая влияет на имена ветвей и тегов.

Вы должны думать о git fetch как о том, как ваш Git вызывать (или, возможно, текстовое сообщение) еще один Git -the "remote" - и иметь беседу с ним. В начале этого разговора удаленный список перечисляет все свои ссылки: все в refs/heads/ и все в refs/tags/, а также любые другие ссылки, которые он имеет. Ваш Git сканирует их и (на основе обычного fetch refspec) переименовывает свои ветки.

Посмотрим на обычный refspec для удаленного имени с именем origin:

$ git config --get-all remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
$ 

Этот refspec инструктирует ваше Git использовать каждое имя, соответствующее refs/heads/* -ie, каждой ветки на удаленном компьютере, и изменить его имя на refs/remotes/origin/*, т.е. сохранить совпадающую часть одинаковой, изменив имя ветки (refs/heads/) к имени ветки удаленной отслеживания (refs/remotes/, в частности, refs/remotes/origin/).

Именно через этот refspec ветки origin становятся ветвями удаленного отслеживания для удаленных origin. Имя ветки становится именем ветки удаленной отслеживания, включая имя пульта, в данном случае origin. Знак плюса + в начале refspec устанавливает флаг "force", т.е. Ваша ветка удаленного отслеживания будет обновлена ​​в соответствии с именем удаленной ветки, независимо от того, что требуется для ее соответствия. (Без + обновления ветвей ограничены изменениями "быстрой перемотки вперед", а обновления тегов просто игнорируются с Git версии 1.8.2 или около того - до этого применяются те же самые правила быстрой перемотки.)

Метки

Но как насчет тегов? Там нет refspec для них - по крайней мере, не по умолчанию. Вы можете установить один, и в этом случае форма refspec зависит от вас; или вы можете запустить git fetch --tags. Использование --tags имеет эффект добавления refs/tags/*:refs/tags/* в refspec, т.е. Он выводит все теги (, но не обновляет ваш тег, если у вас уже есть тег с этим именем, независимо от того, что говорит удаленный тег Изменить, январь 2017: с Git 2.10, тестирование показывает, что --tags принудительно обновляет теги из удаленных тегов, как если бы refspec читал +refs/tags/*:refs/tags/*; это может быть разница в поведении от более раннего версия Git).

Обратите внимание, что здесь нет переименования: если у удаленного origin есть тэг xyzzy, а вы его нет, а вы git fetch origin "refs/tags/*:refs/tags/*", вы получаете refs/tags/xyzzy, добавленный в ваш репозиторий (указывая на то же сообщение, что и на пульте дистанционного управления). Если вы используете +refs/tags/*:refs/tags/*, то ваш тег xyzzy, если он у вас есть, заменяется на один из origin. То есть флаг силы + в refspec означает "заменить мое ссылочное значение на то, что мой Git получает из их Git".

Автоматические теги во время выборки

По историческим причинам ³ если вы не используете ни параметр --tags, ни параметр --no-tags, git fetch выполняет специальные действия. Помните, что мы сказали выше, что пульт начинает с отображения на ваш локальный Git всех его ссылок, хочет ли ваш локальный Git их видеть или нет. ⁴ Ваш Git принимает к сведению все теги, которые он видит в этот момент. Затем, когда он начинает загружать любые объекты фиксации, он должен обрабатывать все, что он извлекает, если один из этих коммитов имеет тот же идентификатор, что и любой из этих тегов, Git добавит этот тег или те теги, если несколько тегов иметь этот идентификатор в вашем репозитории.

Изменить, январь 2017: тестирование показывает, что поведение в Git 2.10 теперь: Если их Git предоставляет тэг с именем T, и у вас нет тега с именем T, а идентификатор фиксации, связанный с T, предка одного из своих ветвей, который исследует ваш git fetch, ваш Git добавляет T к вашим тегам с помощью или без --tags. Добавление --tags заставляет ваш Git получать все свои теги, а также принудительно обновлять.

Нижняя строка

Возможно, вам придется использовать git fetch --tags для получения своих тегов. Если их имена тегов конфликтуют с вашими существующими именами тегов, вы можете (в зависимости от версии Git) даже удалять (или переименовывать) некоторые из ваших тегов, а затем запускать git fetch --tags, чтобы получить их теги. Поскольку теги, в отличие от удаленных веток, не имеют автоматического переименования, ваши имена тегов должны совпадать с именами тегов, поэтому у вас могут быть проблемы с конфликтами.

В большинстве обычных случаев простой git fetch выполнит эту работу, доведя свои коммиты и соответствующие теги, а так как они - кто бы они ни были - будут отмечать фиксации в момент публикации этих коммитов, вы будете не отставайте от своих тегов. Если вы не создадите свои собственные теги и не смешиваете их репозиторий и другие репозитории (через несколько пультов), у вас не будет никаких коллизий имен тегов, поэтому вам не придется беспокоиться об удалении или переименовании тегов, чтобы получить их теги.

Когда вам нужны квалифицированные имена

Я упомянул выше, что вы можете опускать refs/ почти всегда, а refs/heads/ и refs/tags/ и т.д. большую часть времени. Но когда вы не можете?

Полный (или почти полный) ответ находится в документации gitrevisions. Git разрешит имя идентификатора фиксации, используя шестиступенчатую последовательность, указанную в ссылке. Любопытно, что теги перекрывают ветки: если есть тег xyzzy и ветвь xyzzy, и они указывают на разные коммиты, то:

git rev-parse xyzzy

предоставит вам идентификатор, на который указывает тег. Однако - это то, что отсутствует в gitrevisions - git checkout, предпочитает имена ветвей, поэтому git checkout xyzzy помещает вас в ветвь, не обращая внимания на тег.

В случае двусмысленности вы почти всегда можете указать имя ссылки, используя свое полное имя, refs/heads/xyzzy или refs/tags/xyzzy. (Обратите внимание, что это работает с git checkout, но, возможно, непредвиденным образом: git checkout refs/heads/xyzzy вызывает проверку отдельно стоящего HEAD, а не проверку ветки. Вот почему вы просто должны отметить, что git checkout будет использовать краткое имя как имя ветки сначала: как вы проверяете ветвь xyzzy, даже если тег xyzzy существует. Если вы хотите проверить тег, вы можете использовать refs/tags/xyzzy.)

Потому что (как примечания gitrevisions) Git попробует refs/name, вы также можете просто написать tags/xyzzy, чтобы идентифицировать отмеченный тегом xyzzy. (Если кому-то удалось написать действительную ссылку с именем xyzzy в $GIT_DIR, однако, это будет разрешено как $GIT_DIR/xyzzy. Но обычно только различные имена *HEAD должны быть в $GIT_DIR.)

¹ Хорошо, ладно, "не просто быть педантичным".: -)

² Некоторые говорили бы "очень не полезно", и на самом деле я бы согласился.

³ В принципе, git fetch и вся концепция пультов и refspecs были немного поздним дополнением к Git, происходящим во время Git 1.5. Раньше были только специальные специальные случаи, и одним из них была привязка к тегам, поэтому он получил внушительный код через специальный код.

⁴ Если это помогает, подумайте о дистанционном Git как flasher, в сленге значение.

Ответ 3

Чтобы получить конкретный код тега, попробуйте создать новую ветку, добавьте в нее код тега. Я сделал это командой: $git checkout -b newBranchName tagName