Как управлять номером версии в Git?

давайте представим blerp инструмент командной строки поддерживается на git. Этот инструмент имеет (скрытый) --version опция, которая возвращает его версия (скажем 0.1.2) и --commit который возвращает номер фиксации, из которого он был построен.

и версия, и номер фиксации жестко закодированы в базе кода.

теперь я делаю исправление, затем фиксирую и перестраиваю свою программу. Я еще увижу 0.1.2 хотя эта новая версия отличается от оригинальной 0.1.2. Только фиксация скажет мне, что это не тот же 0.1.2. Это исправление стоит другого номера версии?

одно из решений заключается в том, что каждый раз, когда я делаю фиксацию, я увеличиваю номер жестко закодированной версии (что подразумевает всегда изменять минимум 2 файла для каждой фиксации). Это решение привязки, и оно не работает, когда разработчики работают над различными активными ветвями. Если Боб работает на feature foo из версии 0.1.2 и Алиса работает над функцией bar из той же версии. Как они увеличивают свой номер версии? Боб может использовать нечетное, а Алиса четное. Что, если Ева работает над третьим фильмом?

другим решением может быть использование тегов Git для автоматического создания номера версии. Скрипт может найти ближайший тег, начинающийся с v например v0.1.2 и используйте имя тега в качестве номера версии плюс первые n цифр текущей фиксации (v0.1.2 (build 4acd21)). Это работает хорошо, если рабочий каталог чист. Можно себе представить, чтобы добавить * перед номером сборки, чтобы указать, что рабочий каталог не чист. Основная проблема с этим решением заключается в том, что если кто-то экспортирует источники, он не сможет построить blerp.

какая возможная альтернатива может решить эту проблему?

4 ответов


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

Как вы упомянули, эта команда не будет работать без репозитория Git (.папка git) и Git установлен. Но это почти невообразимый разработчик сегодня без git, но со всеми другими установленными инструментами.


Алексей Киселев и Дарио уже намекали на ответ, но я постараюсь объяснить это подробно.

Схемы Управления Версиями

существует два типа схем управления версиями:

  1. внутренний номер версии: это может быть увеличено много раз в день (например, номер контроля версий)
  2. выпущенная версия: это меняется реже (например, семантическое управление версиями)

люди используют другой схемы согласно их потребности, но семантическое управление версиями довольно широко используется и автором Том Престон-Вернер, соучредитель GitHub.

Семантическое Управление Версиями

семантическое управление версиями следует шаблону X.Y.Z

или более читаемым будет [major].[minor].[patch]-[build/beta/rc]

Е. Г. 1.2.0-beta

major or X может быть увеличен, если есть серьезные изменения в программном обеспечении, например, обратная несовместимость API освобождать.

minor or Y увеличивается, если вводятся API с обратной совместимостью.

patch or Z увеличивается после исправления ошибок.

как мы достигаем этого с помощью Git?

с помощью тегов:

теги в Git можно использовать для добавления номера версии.

git tag -a "v1.5.0-beta" -m "version v1.5.0-beta"

добавляет тег версии v1.5.0-beta для вашего текущего репозитория Git. Каждая новая фиксация после этого будет автоматически увеличиваться путем добавления фиксации номер и фиксация хэша к этому тегу. Это могут быть представления с помощью .

v1.5.0-beta-1-g0c4f33f здесь -1- - это номер фиксации и 0c4f33f аббревиатура хэша фиксации. The g префикс обозначает "git".

полная информация может быть просмотрена с помощью:

git show v1.0.5-beta


как вы говорите, проблемы управления версиями обычно решаются в git с помощью branch и tags(как семантическое управление версиями pattern).

лучший способ-использовать git отслеживать только изменения в кодовой базе, игнорируя (используя .gitignore file) создает файлы и поддерживает чистый репозиторий.

строит результатов (предварительно скомпилированные файлы, исполняемые файлы, файлы распространения, молнии, exe...) могут зависеть от переменные среды (платформа, системная арка и т. д.) и должны храниться отдельно в реестре.

если кодовая база очень большая и трудно поддерживать, возможно, вам следует рассмотреть, чтобы разделить ее на более мелкие компоненты (или git submodule), чтобы избежать перекрестных зависимостей во время разработки.


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