git-tag - Интернет в облаке

ПРОГРАММА:

ИМЯ

git-tag - создать, перечислить, удалить или проверить объект тега, подписанный с помощью GPG

СИНТАКСИС

мерзавец день [-a | -s | -u ] [-f] [-m | -F ]
[ | ]
мерзавец день -d ...
мерзавец день [-n [ ]] -l [--содержит ] [--points-at ]
[--column [= ] | --no-column] [--create-reflog] [--sort = ]
[--format = ] [- [no-] объединено [ ]] [ ...]
мерзавец день -v ...

ОПИСАНИЕ

Добавьте ссылку на тег в refs / tags /, если -d / -l / -v не задано для удаления, перечисления или проверки
теги.

Если не указано -f, именованный тег еще не должен существовать.

Если один из -a, -s или -u передается, команда создает день объект и требует
сообщение тега. Если только -m или -F задан, запускается редактор для пользователя
введите сообщение тега.

Если М или -F дается и -a, -s и -u отсутствуют, подразумевается -a.

В противном случае создается просто ссылка на тег для имени объекта SHA-1 объекта фиксации.
(т.е. легкий тег).

Объект тега, подписанный GnuPG, будет создан при использовании -s или -u используется. Когда ты
не используется, идентификатор коммиттера для текущего пользователя используется для поиска ключа GnuPG для
подписание. Переменная конфигурации gpg.program используется для указания пользовательского двоичного файла GnuPG.

Объекты тегов (созданные с помощью -a, -s или -u) называются «аннотированными» тегами; они содержат
дата создания, имя теггера и адрес электронной почты, сообщение тегирования и необязательный GnuPG
подпись. В то время как «легкий» тег - это просто имя объекта (обычно фиксация
объект).

Аннотированные теги предназначены для выпуска, в то время как легкие теги предназначены для частных или
метки временных объектов. По этой причине некоторые команды git для именования объектов (например, git
description) по умолчанию игнорирует облегченные теги.

ДОПОЛНИТЕЛЬНЫЕ УСЛУГИ, НЕ ВКЛЮЧЕННЫЕ В ПАКЕТ

-а, --аннотировать
Создайте беззнаковый аннотированный объект тега

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

-u , --local-user =
Сделайте подписанный GPG тег, используя данный ключ.

-ф, --сила
Замените существующий тег с заданным именем (вместо сбоя)

-д, --удалить
Удалите существующие теги с заданными именами.

-v, --проверить
Проверьте подпись gpg для заданных имен тегов.

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

-l , --список
Перечислить теги с именами, соответствующими заданному шаблону (или все, если шаблон не задан).
Запуск «git tag» без аргументов также выводит список всех тегов. Узор - это ракушка
подстановочный знак (т. е. сопоставлен с использованием фнматч(3)). Могут быть даны несколько шаблонов; если любой из
они совпадают, тег отображается.

--sort =
Сортировать по заданному ключу. Префикс - для сортировки по убыванию значения. Ты
можно использовать --sort = опцию несколько раз, и в этом случае последний ключ становится
основной ключ. Также поддерживает "version: refname" или "v: refname" (имена тегов обрабатываются как
версии). На порядок сортировки "версия: имя ссылки" также может влиять
Переменная конфигурации "versionsort.prereleaseSuffix". Поддерживаемые ключи такие же
как и в git for-each-ref. По умолчанию для порядка сортировки используется значение, настроенное для
тег.сортировать переменная, если она существует, или лексикографический порядок в противном случае. Видеть git-конфигурация(1).

--column [= ], --no-column
Отображение списка тегов в столбцах. См. Параметр конфигурации column.tag.
синтаксис. - column и --no-column без параметров эквивалентны всегда и никогда
соответственно.

Эта опция применима только при перечислении тегов без строк аннотации.

--содержит [ ]
Список только тегов, которые содержат указанную фиксацию (HEAD, если не указан).

--points-at
Только перечислить теги данного объекта.

-м , --сообщение =
Используйте данное сообщение тега (вместо запроса). Если указано несколько параметров -m,
их значения объединены в отдельные абзацы. Подразумевается -a, если ни один из -a, -s или
-u дано.

-F , --file =
Возьмите сообщение тега из данного файла. Использовать - читать сообщение из стандарта
Вход. Подразумевает -a, если ни один из -a, -s или -u дано.

--cleanup =
Этот параметр устанавливает способ очистки сообщения тега. В может быть одним из дословно,
пробельные и полоса, полоса режим по умолчанию. В дословно режим не меняется
сообщение вообще, пробельные удаляет только начальные / конечные пробельные строки и полоса
удаляет как пробелы, так и комментарии.

--create-reflog
Создайте рефлог для тега.


Имя тега, который нужно создать, удалить или описать. Новое имя тега должно соответствовать всем
проверки, определенные git-check-ref-формат(1). Некоторые из этих проверок могут ограничивать
допустимые символы в имени тега.

,
Объект, на который будет ссылаться новый тег, обычно фиксация. По умолчанию HEAD.


Строка, которая интерполирует% (fieldname) из объекта, на который указывает ссылка, являющаяся
показано. Формат такой же, как у git для каждой ссылки(1). Если не указано иное,
по умолчанию% (refname: strip = 2).

- [no-] объединено [ ]
Перечислять только теги, подсказки которых достижимы или недоступны, если --не объединены используется, из
указанный коммит (ГОЛОВА если не указано).

КОНФИГУРАЦИЯ

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

[Пользователь]
SigningKey =

ОБСУЖДЕНИЕ

On Повторная маркировка
Что делать, если вы пометили неправильную фиксацию и хотите пометить заново?

Если вы никогда ничего не выталкивали, просто пометьте его заново. Используйте "-f" для замены старого. А также
все готово.

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

1. Вменяемая вещь. Просто признайте, что вы облажались, и назовите другое имя. У других есть
уже видел одно имя тега, и если вы сохраните то же имя, вы можете оказаться в ситуации
что у двух людей есть "версия X", но на самом деле у них различный «Х». Так что просто
назовите это «X.1» и покончите с этим.

2. Безумие. Вы действительно хотите назвать новую версию "X", даже хоть другие исследователи
уже видел старую. Так что просто используйте мерзавец день -f снова, как будто вы еще не
опубликовал старую.

Однако Git делает не (и не должно) менять теги за спиной пользователей. Итак, если кто-то
уже получил старый тег, делая мерзавец тянуть на вашем дереве не должно просто заставлять их перезаписывать
Старый.

Если кто-то получил от вас метку выпуска, вы не можете просто изменить метку для него,
обновляя свой собственный. Это большая проблема безопасности, поскольку люди ДОЛЖНЫ доверять
их имена тегов. Если вы действительно хотите совершить безумный поступок, вам нужно просто признаться в
это, и скажите людям, что вы напортачили. Вы можете сделать это, сделав очень общедоступным
объявление, говорящее:

Хорошо, я напортачил и выпустил более раннюю версию, помеченную как X. Я
затем что-то исправил и снова пометил * фиксированное * дерево как X.

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

git-тег -d X
git fetch тег происхождения X

чтобы получить обновленный тег.

Вы можете проверить, какой у вас тег, выполнив

git rev-parse X

который должен вернуть 0123456789abcdef .. если у вас новая версия.

Извините за причиненные неудобства.

Это кажется немного сложным? Это должен быть. Нет никакого способа, чтобы это было правильно
чтобы просто "исправить" это автоматически. Людям нужно знать, что их теги могли быть
изменилось.

On Автоматический после
Если вы следуете за чужим деревом, вы, скорее всего, используете удаленное отслеживание.
ветки (refs / Heads / origin в традиционном макете или refs / remotes / origin / master в
раздельно-выносная планировка). Обычно вам нужны теги с другого конца.

С другой стороны, если вы выполняете выборку, потому что вам нужно одноразовое слияние из
кто-то другой, вы обычно не хотите получать оттуда теги. Это бывает чаще
для людей, близких к верхнему уровню, но не ограничиваясь ими. Простые смертные, когда вытаскивают из каждого
другие не обязательно хотят автоматически получать частные теги точек привязки из
другой человек.

Часто сообщения "пожалуйста, потяните" в списке рассылки просто содержат две части информации:
URL репо и название ветки; это сделано, чтобы его можно было легко вырезать и наклеить в конце мерзавец
получать командная строка:

Линус, пожалуйста, потяните из

git: //git..../proj.git master

чтобы получать следующие обновления ...

будет выглядеть так:

$ git pull git: //git..../proj.git master

В таком случае вы не хотите автоматически подписываться на теги другого человека.

Одним из важных аспектов Git является его распределенная природа, что в значительной степени означает отсутствие
присущие системе "восходящий поток" или "нисходящий поток". На первый взгляд, приведенный выше пример
может показаться, что пространство имен тегов принадлежит высшему эшелону людей и
эти теги текут только вниз, но это не так. Это только показывает, что использование
шаблон определяет, кому чьи теги интересны.

Одноразовое вытягивание - это признак того, что история фиксации теперь пересекает границу между одним
круг людей (например, "люди, которые в первую очередь заинтересованы в сетевой части
ядро "), который может иметь собственный набор тегов (например," это третий релиз-кандидат
из сетевой группы, которая будет предложена для общего использования с выпуском 2.6.21 ") на
другой круг людей (например, «люди, которые интегрируют различные улучшения подсистем»). В
последние обычно не интересуются подробными тегами, используемыми внутри первой группы
(вот что значит «внутренний»). Поэтому желательно не следовать тегам
автоматически в этом случае.

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

On Датировка задним, более ранним числом Теги
Если вы импортировали некоторые изменения из другой VCS и хотите добавить теги для основных
выпусков вашей работы, полезно иметь возможность указать дату для вставки в
объект тега; такие данные в объекте тега влияют, например, на порядок тегов в
gitweb интерфейс.

Чтобы установить дату, которая будет использоваться в будущих объектах тегов, установите переменную среды
GIT_COMMITTER_DATE (см. Обсуждение возможных значений ниже; наиболее распространенная форма -
«ГГГГ-ММ-ДД ЧЧ: ММ»).

Например:

$ GIT_COMMITTER_DATE = "2006-10-02 10:31" git tag -s v1.0.1

ДАТА ФОРМАТЫ

Переменные среды GIT_AUTHOR_DATE, GIT_COMMITTER_DATE поддерживают следующую дату
форматы:

Внутренний формат Git
это , куда это количество
секунд с эпохи UNIX. положительное или отрицательное смещение
от UTC. Например, CET (что на 2 часа опережает UTC) составляет +0200.

RFC 2822
Стандартный формат электронной почты, описанный в RFC 2822, например, четверг, 07 апреля 2005 г.
22:13:13 +0200.

ISO 8601
Время и дата указаны в стандарте ISO 8601, например 2005-04-07T22: 13: 13. В
синтаксический анализатор также принимает пробел вместо символа T.

Внимание
Кроме того, часть даты принимается в следующих форматах: ГГГГ.ММ.ДД,
ММ / ДД / ГГГГ и ДД.ММ.ГГГГ.

Используйте git-tag онлайн с помощью сервисов onworks.net