Как вы достигаете числовой схемы управления версиями с Git?

Моя организация рассматривает возможность перехода от SVN к Git. Один аргумент против перемещения выглядит следующим образом:

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

У нас есть дистрибутив SDK, основанный на платформе NetBeans. Поскольку изменения SVN являются простыми числами, мы можем использовать их для расширения номеров версий наших плагинов и SDK-сборок. Как мы справляемся с этим, когда переходим к Git?

Возможные решения:

  • Использование номера сборки из Hudson (проблема: вы должны проверить Hudson, чтобы соотнести это с реальной версией Git)
  • В ручном режиме версия для ночной и стабильной (проблема: кривая обучения, человеческая ошибка)

Если кто-то другой столкнулся с подобной проблемой и решил ее, нам бы хотелось услышать, как это сделать.

120 голосов | спросил Erlend 28 MarpmWed, 28 Mar 2012 22:18:32 +04002012-03-28T22:18:32+04:0010 2012, 22:18:32

5 ответов


135

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

git tag -a v2.5 -m 'Version 2.5'

Нажмите теги вверх по течению - это не делается по умолчанию:

git push --tags

Затем используйте команду описать :

git describe --tags --long

Это дает вам строку формата:

v2.5-0-gdeadbee
^    ^ ^^
|    | ||
|    | |'-- SHA of HEAD (first seven chars)
|    | '-- "g" is for git
|    '---- number of commits since last tag
|
'--------- last tag
ответил Jon Purdy 28 MarpmWed, 28 Mar 2012 22:55:25 +04002012-03-28T22:55:25+04:0010 2012, 22:55:25
34

Это придумало для меня несколько проектов. Лучшим решением, которое я получил до сих пор, является создание номера версии следующим образом:

x.y. <число коммитов> .r <git-hash>

Как правило, он создается нашей системой сборки, используя комбинацию некоторого статического файла или тега для получения основных номеров версий, git rev-list HEAD | wc -l (это было быстрее, чем использование git log) и git rev-parse HEAD. Были следующие рассуждения:

  1. Нам нужна была возможность выполнения высокоуровневого управления версиями (т. е. x.y)
  2. Когда выполнялась параллельная разработка, нам не нужно было генерировать тот же номер версии.
  3. Мы хотели легко отследить, откуда появилась версия.
  4. Когда параллельные линии были объединены, мы хотели, чтобы новая версия разрешалась выше любой из ветвей.

Число 2 невидимо для большинства людей, но действительно важно, а действительно сложно с распределенным контролем источника. SVN помогает в этом, предоставляя вам один номер ревизии. Оказывается, подсчет фиксации как можно ближе, а магическое решение №4. В присутствии ветвей это еще не уникально, и в этом случае мы добавляем хеш, который аккуратно решает и # 3.

Большая часть из них заключалась в том, чтобы разместить развертывание через пипс Python. Это гарантировало, что pip install может быть немного странным во время параллельной разработки (т. Е. Пакеты от людей в разных ветвях будут смешиваться, но детерминированным образом), но после слияния все разобралось. Запрет на наличие выставленной перебазы или поправки, это работало довольно хорошо для вышеуказанных требований.

В случае, если вам интересно, мы решили поставить r перед хэшем из-за какой-то странности с тем, как упаковка Python обрабатывает буквы в номерах версий (т.е. ae меньше 0, что делает «1.3.10. a1234 "<" 1,3.10 "<" 1.3.10.1234 ").

ответил Jayson 5 J0000006Europe/Moscow 2012, 02:57:11
8

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

Посмотрите на процесс использования «git-describe» с помощью GIT-VERSION-GEN и того, как вы можете добавить это через свой процесс сборки, когда вы помечаете свой выпуск.

Вот хороший блог, который дает пример того, как получить то, что вы хотите:

http://cd34.com/blog/programming/используя-ГИТ-чтобы генерировать-ан-автомат-номер-версии /

ответил SoftwareCarpenter 28 MarpmWed, 28 Mar 2012 22:51:49 +04002012-03-28T22:51:49+04:0010 2012, 22:51:49
7

Это может быть немного перебор, но я дам вам знать, как мы это делаем.

Мы используем структуру ветвления, очень похожую на это .

Хадсон строит наши «разветвленные» ветви и увеличивает числа построений, начиная с 0. Номер сборки уникален для каждого проекта и помечен тегом в управлении версиями. Причина в том, что вы можете точно определить, из какого рода построить сборку 42, например (каждый проект может иметь несколько параллельных ветвей разработки, поскольку каждый проект может иметь несколько команд, работающих по различным аспектам проекта).

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

Пример: 2.1.0 build 1337

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

ответил Carl 29 MaramThu, 29 Mar 2012 03:48:54 +04002012-03-29T03:48:54+04:0003 2012, 03:48:54
-6

Pro Git в разделе 7.2 "Git Attributes" в Часть расширения «Ключевое слово» содержит хороший пример использования фильтров smudge и amp; clean для генерации ключевых слов в стиле RCS. Вы можете использовать тот же метод для вложения some-version-string в код, отформатированный и рассчитанный в соответствии с вашими правилами . Вы по-прежнему можете использовать git describe как точку зрения, но у вас есть возможность перейти к любой более подходящей форме и получить от v2.5-14-feebdaed, например , чистый 2.5.14

ответил Lazy Badger 29 MaramThu, 29 Mar 2012 01:34:34 +04002012-03-29T01:34:34+04:0001 2012, 01:34:34

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132