Есть также бампверсия (дополнительная информация по адресу https://github.com/peritus/bumpversion ), который стремится заменить эту магию sed.

Установите с помощью pip install bumpversion, сообщите ему, какие файлы содержат номер вашей версии и хотите ли вы зафиксировать и пометить его. Он также легко настраивается (с семантическим версионированием по умолчанию), так что вы можете добавить декларативный конфигурационный файл о том, как отбрасывать версии для этого программного проекта в ваш vcs выбора и другие могут также отбрасывать версии.

В моем раздвоенном проекте git-flow я фактически реализовал крючки и фильтры, запрос, который многие сделали в оригинальном проекте, но до сих пор не был реализован. С их помощью вы можете автоматически обновлять номера версий в вашем проекте. Раздвоенный проект можно найти здесь https://github.com/petervanderdoes/gitflow

Для некоторых скриптов Bash на версии bumping вы можете проверить два GiST, которые я создал https://gist.github.com/2877083 или https://gist.github.com/2878492

Веб-страница Semver утверждает:

Задан номер версии MAJOR.НЕЗНАЧИТЕЛЬНЫЙ.Заплатка, инкремент:

• основная версия при внесении несовместимых изменений API,
• минорная версия, когда вы добавляете функциональность обратно совместимым способом, и
• версия патча, когда вы делаете обратно совместимые исправления ошибок.

Дополнительные метки для метаданных предварительного выпуска и сборки доступны в виде продолжение до майора.НЕЗНАЧИТЕЛЬНЫЙ.ЗАПЛАТКА формат.

Gitflow использует соглашение об именовании ветвей, исправления ошибок живут на ветвях с префиксом hotfix/, а новые функции имеют префикс feature/.

Когда любая ветвь этого типа объединяется в ветвь выпуска, это приводит к увеличению PATCH. Если объект был объединен, то второстепенное поле должно быть увеличено.

Учитывая конкретную ревизию,вы должны быть в состоянии вычислить, если любая из ветвей была объединена и какое поле для удара.

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

Вот код, который мы используем для увеличения номера версии в константах.h:

constants='../Include/constants.h'

# Get the current build number
currentbuild=`grep PRODUCT_BUILD $constants|sed 's/[^0-9]//g'`
currentversion=`grep PRODUCT_VERSION $constants|sed 's/[^.0-9]//g'`

echo "currentbuild=$currentbuild and currentversion=$currentversion"
newver=$((1+$currentbuild))

# Update the build number on-disk:
cp $constants /tmp/constants
if sed -e "/PRODUCT_BUILD/ s/[0-9][0-9]*/${newver}/" < /tmp/constants > $constants
then    
    echo "Updated build number from $currentversion.$currentbuild to $currentversion.$newver."
    cd ../Include
    # Check it into version control
    svn ci -m "updated build number to ${currentversion}.${newver} for $buildid in $buildroot"
else
    echo "There was a problem updating $constants to build $newver"
fi    

Вы также можете взглянуть на мой РЕПО для bumpversion его в настоящее время сделано для файлов установки python, которые могут быть изменены с помощью-bumpversion-package

Если я правильно понимаю вашу операцию 'bump version', то вы имеете в виду увеличение номера версии в произвольном количестве файлов, как только вы начали выпуск с git flow release start x.x.x, где версия также представлена в теге git.

Поскольку первоначальный git-поток из Дриссена был прекращен, неофициальным преемником, по-видимому, является Питер ван дер Дос gitflow-avh (https://github.com/petervanderdoes/gitflow-avh/), который содержит большое количество крючков git flow. Видеть https://github.com/petervanderdoes/gitflow-avh/tree/develop/hooks для полного списка.

Я сделал версию натыкаясь на post-flow-release-start с этим маленьким скриптом:

VERSION=$1

# Get rid of version prefix
STRIPPED_VERSION=`echo $VERSION | cut -d'v' -f 2`
sed -i '' -E "s/^([ |#|[:alpha:]]*)\[.*\]$/\1[$STRIPPED_VERSION]/1" ./README.md
sed -i '' -E "s/^([\t| ]*\"version\": )\".*\"/\1\"$STRIPPED_VERSION\"/1" ./package.json
git commit -a -m "version $STRIPPED_VERSION"

exit 0

Это немного жестко, потому что два файла жестко закодированы (README.md и пакет.формат JSON). Вы можете выполнить поиск старой версии из последнего тега,а затем повторить его для всех настроенных файлов в цикле.

Предостережения:
OSX требует суффикс для sed -i, хотя вы можете использовать пустые кавычки. Кроме того, расширенное регулярное выражение param for sed в Linux называется иначе.

Вы можете автоматизировать версию, натыкающуюся на каждый коммит. Здесь вы можете найти это сделано с помощью скрипта оболочки и встроенного git-крючка: https://github.com/addonszz/Galileo/tree/develop/githooks

Оболочка сума для запуска является: https://github.com/evandrocoan/.versioning/blob/master/scripts/updateVersion.sh

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

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

Патч, вы можете подключить каждый git поток исправление готово. Приведенной выше ссылки просто не хватает, чтобы подключить исправление готово для увеличения версии патча работает: ./githooks/updateVersion.sh patch

Но минор и Мажор тут ни при чем, все они сделаны в рамках feature finish release.

Obs

Я нашел решение, чтобы зацепить pre-hotfix-commits, это по вопросу: как это сделать? предварительно подключить исправление GitFlow finish?