Существует ли стандартное соглашение об именах для тегов git? [закрыто]


229

Я видел много проектов, использующих v1.2.3в качестве соглашения об именах теги в git. Я также видел некоторое использование 1.2.3. Есть ли официально одобренный стиль, или есть ли веские аргументы для их использования?


19
С 43 ответами и подсчетом, я задаюсь вопросом, можно ли перефразировать и вновь открыть этот очень ценный вопрос, с каким-нибудь ответом, объединяющим все пункты в хорошем резюме и находящимся на вершине? @ PeterEisentraut, кажется, является наиболее полным; в то время как принятый ответ банкомат кажется немного вводящим в заблуждение. (Я думаю, что сам буду использовать v1.2.3 для тегов, после прочтения всех пунктов.)
HostileFork говорит, что не доверяйте SE

1
Так что для исправления кода. Похоже, что лучшие практики принадлежат на softwareengineering.stackexchange.com или codereview.stackexchange.com
Тиммерман,

Взгляните на semver.org (семантическое управление версиями), которое должно дать вам некоторые идеи.
vonbrand

мой опыт подсказывает мне использовать немного другую схему. 1. Подкаталог: тег Git должен начинаться, по крайней мере, с v/тегов этой группы в пространстве имен. 2. в идеале тег должен также содержать аббревиатуру, которая однозначно идентифицирует приложение. например v/myapp/1.0. Это облегчает объединение репозитория git: в случае объединения приложений теги не будут конфликтовать в пространстве имен тегов.
19

Ответы:


166

Версия 1.0.0 Semantic Versioning , созданная Томом Престоном-Вернером из GitHub, имела под-спецификацию, решающую эту проблему:

Спецификация маркировки (SemVerTag)

Эту под спецификацию СЛЕДУЕТ использовать, если вы используете систему контроля версий (Git, Mercurial, SVN и т. Д.) Для хранения своего кода. Использование этой системы позволяет автоматизированным инструментам проверять ваш пакет и определять соответствие SemVer и выпущенные версии.

  1. При маркировке выпусков в системе управления версиями тег для версии ДОЛЖЕН быть «vX.YZ», например, «v3.1.0» .

Однако после обсуждения это было удалено и больше не присутствует в последней версии спецификации SemVer (2.0.0 на момент написания). Более поздняя ветка обсуждения в том же месте углубилась и привела к новой «v1.2.3» семантической версии? будучи добавлено в FAQ в SemVer в masterотрасли, хотя на момент написания (более 2 лет) это изменение до сих пор нет в официально опубликованной спецификации.


9
Спасибо. Это очень близко. Я хочу , чтобы он бы квалифицирован , почемуv должен быть там же.
troelskn

3
@troelskn @mojombo == Том Престон-Вернер
Peritus

4
Обновленная ссылка: github.com/mojombo/semver.org/issues/1
Джош Ли

41
Semantic Versioning 1.0.0 использует формат "v1.2.3". Семантическое управление версиями 2.0.0-rc.1, вероятно, использует формат "1.2.3". Статья спецификации тегов (SemVerTag) была удалена из спецификации. Больше здесь: semver.org
petrnohejl

9
Этот ответ сделан, когда существовал старый semver (версия 1.0). В настоящее время префикс 'v' удален из semver v2.0. Подробнее см. Пост ниже.
Виталий

111

По-видимому, существует два доминирующих соглашения (при условии, что вы также придерживаетесь некоторого разумного стандарта для нумерации самих выпусков):

  • v1.2.3
  • 1.2.3

Преимущества в том v1.2.3, что документация Git (а также документация Mercurial) использует этот формат в своих примерах, и что некоторые «авторитеты», такие как ядро Linux и сам Git , используют его. (Упомянутое Семантическое Управление версиями использовало это, но больше не использует.)

Преимущества 1.2.3состоят в том, что gitweb или GitHub могут автоматически предлагать загрузку формы из архива или архива packagename-$tag.tar.gz(и я думаю, что вполне установлено, что тарбол не должен называться package-v1.2.3.tar.gz). Кроме того, вы можете использовать git describeнепосредственно для создания номеров версий тарбол. Для легких проектов без формального процесса выпуска эти возможности могут быть весьма удобными. Следует также отметить, что семантическое управление версиями ни в коем случае не является единственным или общепринятым стандартом нумерации версий. И известные проекты, такие как GNOME, а также бесчисленное множество других проектов действительно используют 1.2.3именование тегов.

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


Обновление: Как уже упоминалось в этом комментарии, GitHub теперь предлагает имя тарбола с убранным 'v' из тега.


13
Что касается GitHub и генерации тарбола: это больше не актуально. Они снимают букву «V» с тега.
Герман Биер

6
Префикс 'v' также весьма полезен при сортировке тегов в алфавитном порядке. Другие теги могут также существовать; будь то официально в главном репозитории или локально отслеживать работу разработчика. С префиксами 'v' теги выпуска формируют свою собственную группу, а не разбросаны по всему остальному пространству имен.
Роби

1
Обновлен ответ, чтобы отразить, что SemVer больше не используется v.
Адам Спирс

80

Причина предыдущего 'v' является исторической. Старые SCCS (cvs, rcs) не могли различить идентификатор тега и номер редакции. Идентификаторы тегов были ограничены, чтобы не начинаться с числового значения, чтобы можно было обнаружить номера ревизий.


5
+1: Хороший первый ответ и имя из одной из моих любимых книг :-) Возможно, ваш следующий ответ будет на более актуальный вопрос.
Johnsyweb

1
... но если это верно только для старых SVCS, что если смысл этого ответа на вопрос о современном Git?
MestreLion

3
это все еще полезно в git, так что вы можете легко отличить теги версий от других типов тегов (теги полезны для многих других вещей)
Benja

19

Не то, что я знаю о.
Но Git не разрешит тег и ветку с одним и тем же именем одновременно, поэтому, если у вас есть ветка " 1.1" для 1.1работ, не ставьте тег " 1.1", используйте, например, " v1.1"


8
Используйте для веток 1.1.x. Вот и все.
Виталий

1
хороший улов, спасибо.
Р.Я.

10

Новые менеджеры пакетов советуют помечать версии без префиксов v(например, composer для проектов PHP). SemVer 2.0 не имеет ничего о спецификации тегов. Это сделано намеренно, чтобы избежать конфликтов. Однако рекомендуется добавлять префикс vв документацию и текстовые ссылки. В качестве примера формат v1.0.4вместо полного version 1.0.4или ver. 1.0.4достаточно многословный и элегантный в документации.


22
«Рекомендуется…». Посоветовали, кто и где мы можем увидеть этот совет в его первоначальном контексте?
bignose

8

Мы используем ветки и теги для специфической для релиза работы, за которой следует фактическая версия, соответственно:

o---o-----o---o---o--- ...   master
     \   /       /
      \ /       /
       o-------o--- ...      1.6 branch

Каждый разработчик принимает умственное решение о том, применима ли работа, которую он собирается совершить, просто к выполнению, или она также имеет отношение к отрасли. Вы можете видеть, что изменения, внесенные в ветку, объединяются обратно в master, но некоторые изменения в master никогда не будут выполняться в ветке (то есть в этом примере не предназначенные для выпуска 1.6).

Когда мы готовы к выпуску, мы помечаем его, а затем объединяем обратно в последний раз и называем тег тем же именем, что и ветвь, но с дополнительным идентификатором о том, какая это конкретная версия, например «1.6-release». или "1.6-бета" или "1.6-RC2" и так далее.

... ------o---o---o--o---o--- ...   master
         /       /
        /       /
... ---o------(*)--- ...      1.6 branch
          1.6-release

Спасибо - это хороший ответ для описания того, как вы делаете ветвление, но на самом деле я просто имел в виду, есть ли какая-то конкретная (техническая) причина для использования определенной схемы именования в git. Тем не менее, я получаю удовольствие от хороших диаграмм;)
troelskn

Ах, понял! Извините за неправильное понимание вашего вопроса. Нет, нет конкретной технической причины для использования определенного имени, кроме человеческого общения. Вы можете назвать свои ветви и теги практически как угодно.
Джон Феминелла

Ваша ветка релиза 1.6 называется "веткой 1.6"? Я думал, что пробелы не поддерживаются в именах веток.
Сис Тиммерман

8

Я не знаю никаких стандартов. Я просто выбираю имена своих тегов, чтобы

VERSION = `git describe --tags`

в моих сборочных скриптах. Таким образом, соглашение об именовании тегов на самом деле зависит от соглашения о присвоении имен проекта.


1
git description --tags:>
Дэмиен Кэрол

1

Я не знаю ни одной лучшей практики. Вот несколько ссылок:

Как правило, управление версиями ( 0.0.1, v0.2.1, ...) , может быть , рука об руку с какой - то вопрос отслеживания можно считать правдоподобным подход. (.. хотя я обычно использую vимена тегов с префиксом .. см. также ответ @VonC)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.