Как проверить удаленный тег git
когда я проверяю удаленный тег git, используйте следующую команду:
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.
2 ответов
давайте начнем с объяснения того, что такое тег в git
бирка использована для того чтобы обозначить и отметить специфическое фиксация в истории.
Он обычно используется для обозначения точек выпуска (например. В1.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-*'
как создать теги?
существует 2 способа создания тега:
# normal tag
git tag
# annotated tag
git tag -a
разница между 2 заключается в том, что при создании аннотированного тега вы можете добавлять метаданные, как у вас есть в git commit:
имя, e-mail, Дата, комментарий и подпись
Как удалить теги?
# delete any given tag
git tag -d <tag name>
# Don't forget to remove the deleted tag form the server with push tags
как клонировать определенный тег?
в порядке возьмите ocntent данного тега, который вы можете использовать .
Как объяснено, теги abover похожи на любые другие коммиты, поэтому мы можем использовать checkout и вместо использования SHA-1 просто замените его на tag_name
Вариант 1:
# Update the local gir repo with the latest tags from all remotes
git fetch --all
# checkout the specific tag
git checkout tags/<tag> -b <branch>
Вариант 2:
С помощью команды clone
так как поддержка git shalow clone добавить --branch команде клонирования мы можем использовать имя тега вместо имени филиала. Git знает, как" перевести " данный SHA-1 на соответствующий commit
# Clone a specific tag name
git clone <url. --branch=<tag_name>
git clone --branch=
--branchтакже может принимать теги и отсоединять головку при фиксации в результирующем репозитории.
(этот ответ занял некоторое время, чтобы написать, и codeWizard это правильно по цели и сути, но не полностью завершено, поэтому я все равно опубликую это.)
нет такой вещи, как "удаленный тег Git". Есть только "теги". Я указываю на все это, чтобы не быть педантичным,1 но потому, что есть много путаницы об этом со случайными пользователями Git, и документация Git не очень полезна2 для начинающих. (Неясно, происходит ли путаница из-за плохой документации, или плохая документация приходит, потому что это по своей сути несколько запутанно, или что.)
здесь are "удаленные ветви", более правильно называемые" ветви удаленного отслеживания", но стоит отметить, что это на самом деле локальные объекты. Однако нет удаленных тегов (если вы (повторно) не изобрели их). Есть только локальные теги, поэтому вам нужно получить тег локально, чтобы использовать он.
общая форма имен для конкретных коммитов-которую 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/ при обращении к местной ветви или tag-и на самом деле вы должны пропустить refs/heads/ при проверке местного филиала! Вы можете сделать это, когда результат однозначен или-как мы только что отметили-когда вы должны это сделать (for 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-"удаленный"-и поговорить с ним. В начале этого разговора 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/* - т. е. каждая ветка на пульте дистанционного управления-и измените ее название на 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, т. е. он переносит все теги (но не обновляет код тег если у вас уже есть тег с таким именем, независимо от того, что тег пульта дистанционного управления говорит Edit, Jan 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. То есть + флаг force на refspec означает "заменить значение моей ссылки на то, которое мой Git получает от своего Git".
автоматические теги во время выборки
по историческим причинам,3 если вы не используете , ни , git fetch принимает специальные меры. Помните, что мы сказали выше, что пульт дистанционного управления начинается с отображения на локальном Git все его ссылок, хочет ли ваш местный Git видеть их или нет.4 ваш Git принимает к сведению все теги, которые он видит на данный момент. затем, когда он начинает загружать любые объекты фиксации, он должен обрабатывать все, что он извлекает, если один из этих фиксаций имеет тот же идентификатор, что и любой из этих тегов, git добавит этот тег-или эти теги, если несколько тегов имейте этот ID-в свой репозиторий.
Edit, Jan 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/ и так далее большую часть времени. Но когда!--106-->не могу вы?
полный (или почти полный, в любом случае) ответ the gitrevisions документация. Git будет разрешить имя для фиксации ID через шесть-шаг последовательность приведена в ссылке. Любопытно, что теги переопределяют ветви: если есть тег xyzzy и филиала xyzzy, и они указывают на разные изменения, то:
git rev-parse xyzzy
даст вам идентификатор, на который указывает тег. Однако-и это то, чего не хватает из gitrevisions-git checkout предпочитает названия ветвей, поэтому git checkout xyzzy поставит вас на ветку, не обращая внимания на бирку.
в случае двусмысленности вы почти всегда можете записать имя ref, используя его полное имя,refs/heads/xyzzy или refs/tags/xyzzy. (Обратите внимание, что это тут работы с git checkout, но, возможно, неожиданным образом:git checkout refs/heads/xyzzy вызывает проверку отделенной головы, а не проверку филиала. Вот почему вы просто должны отметить, что git checkout сначала будет использовать короткое имя в качестве имени ветки: вот как вы проверяете ветку xyzzy даже если тег xyzzy существует. Если вы хотите проверить тег, вы можете использовать refs/tags/xyzzy.)
потому что (как gitrevisions Примечания) Git попробует refs/name, вы также можно просто написать tags/xyzzy для идентификации фиксации с тегом xyzzy. (Если кому-то удалось написать допустимую ссылку с именем xyzzy на $GIT_DIR, однако, это разрешится как $GIT_DIR/xyzzy. Но обычно только различные *HEAD имена должны быть в $GIT_DIR.)
1Ладно, ладно, "не просто быть педантичным". :-)
2некоторые сказали бы "очень не-полезно", и я бы склонен согласиться, на самом деле.
3по сути, git fetch, и вся концепция пультов и refspecs, был немного поздним добавлением к Git, происходит во время ГИТ 1.5. До этого были только некоторые специальные случаи ad-hoc, и tag-fetching был одним из них, поэтому он получил дедушку через специальный код.
4если это поможет, подумайте о удаленном Git как флешером, в сленговом значении.