когда я проверяю удаленную команду git tag, используйте команду, как это:
git checkout -b local_branch_name origin/remote_tag_name
Я получил ошибку, как это:
error: pathspec `origin/remote_tag_name` did not match any file(s) known to git.
Я могу найти remote_tag_name, когда использую команду git tag.
Метка используется для маркировки и маркировки определенного коммита в истории. Обычно используется для маркировки точек высвобождения (например,. v1.0 и т. д.).
Хотя тег может выглядеть аналогично ветке, тег, однако, не изменяется . Он указывает непосредственно на определенный коммит в истории.
Вы не сможете оформить теги, если они не находятся локально в вашем хранилище, поэтому сначала вам нужно «привлечь» теги в локальный репозиторий.
Во-первых, убедитесь, что тег существует локально, выполнив
# --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-*'
Есть 2 способа создать тег:
# lightweight tag
git tag
# annotated tag
git tag -a
Разница между двумя заключается в том, что при создании аннотированного тега вы можете добавлять метаданные, как в git commit: имя, адрес электронной почты, дата, комментарий и подпись
# 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 поддерживает shallow clone , добавляя --branch
в команду clone, мы можем использовать имя тега вместо имени ветки. Git знает, как «перевести» данный SHA-1 в соответствующий коммит
# Clone a specific tag name using git clone
git clone <url> --branch=<tag_name>
Git Clone --branch = < name >
-- branch
также может принимать теги и отсоединять HEAD при этом коммите в результирующем хранилище.*
git push --tags
Чтобы нажать все теги:
git push --tags
Чтобы нажать аннотированные теги и теги текущей истории, используйте ::
git push --follow-tags
Этот флаг --follow-tags
нажимает оба коммита и только теги , которые оба:
Из Git 2.4 вы можете установить его, используя конфигурацию
git config --global push.followTags true
(Этот ответ занял некоторое время, и ответ codeWizard верен по цели и сущности, но не полностью завершен, поэтому я все равно опубликую это.)
Нет такой вещи, как «удаленный тег Git». Есть только "теги". Я указываю на то, что все это не педантично, 1 < / sup > но потому что есть много путаницы в этом со случайными пользователями Git, и документация Git не очень полезна 2 < / sup > для начинающих. (Неясно, возникает ли путаница из-за плохой документации, или плохая документация возникает, потому что это несколько сбивает с толку, или что.)
Есть "удаленные ветви", более правильно называемые "удаленными ветвями отслеживания", но стоит отметить, что это на самом деле локальные объекты. Однако нет удаленных тегов (если вы не изобретаете их). Есть только локальные теги, поэтому вам нужно получить тег локально, чтобы использовать его.
Общая форма для имен для определенных коммитов, которую Git вызывает ссылки , - это любая строка, начинающаяся с refs /
. Строка, которая начинается с refs / heads /
, называет ветку; строка, начинающаяся с refs / remotes /
, называет ветку удаленного отслеживания; и строка, начинающаяся с refs / tags /
, называет тег. Название refs / stash
является ссылкой на тайник (используется git stash
; обратите внимание на отсутствие следящего слеша).
Существуют некоторые необычные имена специальных случаев, которые не начинаются с refs /
: HEAD
, ORIG_HEAD
, MERGE_HEAD
и CHERRY_PICK_HEAD
, в частности, все также являются именами, которые могут относиться к конкретным коммитам (хотя HEAD
обычно содержит имя ветки, т.е.е.содержит < код > ref: refs / heads / branch < / code >). Но в целом ссылки начинаются с refs /
.
Одна вещь, которую Git делает, чтобы сделать это запутанным, состоит в том, что он позволяет вам опустить refs /
, и часто слово после refs /
. Например, вы можете опустить refs / heads /
илиrefs / tags /
при обращении к локальной ветке или тегу - и фактически вы должны опустить refs / heads /
при проверке локальной ветки! Вы можете делать это всякий раз, когда результат однозначен, или - как мы только что отметили - когда вы должны это сделать (для git checkout branch < / code >).
Это правда, что ссылки существуют не только в вашем собственном хранилище, но и в удаленных репозиториях. Однако Git дает вам доступ к ссылкам удаленного репозитория только в очень специфическое время, а именно во время операций fetch
и push
. Вы также можете использовать git ls-remote
или git remote show
, чтобы увидеть их, но fetch
и push
являются более интересными точками контакта.
Во время fetch
и push
Git использует строки, которые он вызывает refspecs , для передачи ссылок между локальным и удаленным хранилищем. Таким образом, именно в это время и через refspec два репозитория Git могут синхронизироваться друг с другом. Когда ваши имена синхронизированы, вы можете использовать то же имя, что и кто-то с пультом дистанционного управления. Здесь есть какая-то особая магия на «fetch», и она затрагивает как имена ветвей, так и имена тегов.
Вы должны думать о «git fetch» как о том, чтобы ваш Git вызывал (или, возможно, текстовое сообщение) другой Git - «удаленный» - и беседовал с ним. В начале этого разговора пульт перечисляет все свои ссылки: все в refs / heads /
и все в refs / tags /
, а также любые другие ссылки, которые у него есть. Ваш Git сканирует их и (на основе обычной выборки refspec) переименовывает их ветви.
Давайте посмотрим на обычный refspec для пульта дистанционного управления с именем origin
:
$ git config --get-all remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
$
Этот refspec предписывает вашему Git принимать каждое имя, соответствующее refs / heads / *
- т.е., каждая ветка на пульте дистанционного управления - и измените ее название на refs / remotes / origin / *
, т.е.сохраняйте согласованную часть одинаковой, изменяя имя ветки (refs / heads /
) на имя ветки удаленного отслеживания (refs / remotes /
, в частности,refs / remotes / origin /
).
Именно через эту спецификацию * ветви origin
становятся вашими ветвями удаленного отслеживания для удаленного origin
. Имя филиала становится именем филиала удаленного отслеживания, с именем удаленного, в данном случае origin
, включено. Знак плюс +
в передней части refspec устанавливает флаг «force», т.е., ваша ветка удаленного отслеживания будет обновлена в соответствии с именем ветки пульта дистанционного управления, независимо от того, что нужно, чтобы она соответствовала. (Без +
обновления ветки ограничиваются «ускоренными» изменениями, а обновления тегов просто игнорируются начиная с Git версии 1.8.2 или около того - до этого применялись те же правила ускоренной перемотки вперед.)
Но как насчет тегов? Для них нет refspec - по крайней мере, не по умолчанию. Вы можете установить один, и в этом случае форма refspec зависит от вас; или вы можете запустить git fetch --tags
. Использование --tags
приводит к добавлению refs / tags / *: refs / tags / *
в refspec, т.е. это приносит все теги (& Лт;s >но не обновляет ваш тег, если у вас уже есть тег с этим именем, независимо от того, что пульт 'тег говорит </ s > Редактировать, Январь 2017: по состоянию на Git 2.10, тестирование показывает, что --tags
принудительно обновляет ваши теги с пульта дистанционного управления 'с тегами, как будто в refspec указано + refs / tags / *: refs / tags / *
; это может быть различие в поведении более ранней версии Git).
Обратите внимание, что здесь нет переименования: если удаленный origin
имеет тег xyzzy
, а вы нет, и вы git fetch origin "refs / tags / *: refs / tags / xyzzy
добавлено в ваш репозиторий (указывая на тот же коммит, что и на пульте). Если вы используете + refs / tags / *: refs / tags / *
, то ваш тег xyzzy
, если он у вас есть, заменяется тегом из origin
. То есть флаг силы +
в refspec означает «заменить значение моей ссылки на значение, которое мой Git получает от своего Git».
По историческим причинам 3 < / sup > если вы не используете ни опцию --tags
, ни опцию --no-tags
, git fetch
предпринимает специальные действия. Помните, что мы говорили выше, что пульт дистанционного управления начинается с отображения в вашем локальном Git всех его ссылок, хочет ли ваш локальный Git их видеть или нет. 4 < / sup > Ваш Git принимает к сведению все теги, которые он видит на данный момент. < s > Затем, когда он начинает загружать любые объекты коммита, ему необходимо обрабатывать все, что он извлекает, если один из этих коммитов имеет тот же идентификатор, что и любой из этих тегов, git добавит этот тег - или эти теги, если несколько тегов имеют этот идентификатор - в ваш репозиторий.& Лт; / s >
Редактировать, Январь 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
вызывает отдельную проверку, а не проверку филиала. Вот почему вы просто должны отметить, что git checkout
сначала будет использовать короткое имя в качестве имени ветки: именно так вы проверяете ветку xyzzy
, даже если существует тег xyzzy
. Если вы хотите проверить тег, вы можете использовать refs / tags / xyzzy
.)
Потому что (как отмечает gitrevisions
) Git попробует refs / name < / code >, вы также можете просто написать
tags / xyzzy
, чтобы идентифицировать коммит с тегом xyzzy
. (Если кому-то удалось написать действительную ссылку с именем xyzzy
в $ GIT_DIR
, однако это будет разрешено как $ GIT_DIR / xyzzy
. Но обычно только различные имена * HEAD
должны быть в $ GIT_DIR
.)
1 < / sup > Хорошо, хорошо, "не просто быть педантичным". :-)
2 < / sup > Некоторые скажут «очень бесполезно», и я склонен согласиться, на самом деле.
3 < / sup > В основном, git fetch
и вся концепция пультов и refspecs были немного поздним дополнением к Git, происходящим во времена Git 1.5. До этого были только некоторые специальные специальные случаи, и один из них был с меткой, так что он получил внушение через специальный код.
4 < / sup > Если это поможет, подумайте о удаленном Git как о flasher в значении сленга.
Чтобы получить конкретный код тега, попробуйте создать новую ветку, добавьте в нее код тега.
Я сделал это по команде: $ git checkout -b newBranchName tagName