Вы можете выбрать политику, аналогичную самой Git (см. Ее теги в репозитории GitHub ):
v1.7.2-rc0
v1.7.2-rc1
v1.7.2-rc2
v1.7.2-rc3
v1.7.2
Идея (как описано в Выбор хорошей версииполитика нумерации ) может идти по следующим направлениям:
Ветка 'master
' будет содержать код, помеченный как готовый к работе в данный момент, 'master
'должен быть всегда компилируемым.
Код в ветви' master
'должен иметь четный номер тега.
Для номера версии он будет создан с помощью команды git description, так как он является сортировкойстандарта де-факто.
См. Канонические номера версий с Git :
git describe –tags –long
Это дает вам строку типа (в случаеодин из моих проектов)
2.1pre5-4-g675eae1
, который отформатирован как
{last reachable tag name}-{# of commits since that tag}-#{SHA of HEAD}
Это дает вам «канонический номер версии» (орфографияисправлено), которое монотонно увеличивается за счет коммитов и уникально для нескольких репозиториев разработки.Если мы все находимся в одном и том же HEAD, он вернет одно и то же значение.Если у всех нас будет один и тот же самый последний тег, но у нас разные коммиты, SHA будет другим.
Вы можете стремиться к тому, чтобы на master
были только номера версий, такие как
* 1041.*
(т. Е. Только коммит с тегами)
Но идея заключается в том, что этот тип номера версии (тег + SHA) полностью однозначен.