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

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

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

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

состояния веб-страницы Semver:

учитывая номер версии MAJOR.НЕЗНАЧИТЕЛЬНЫЙ.Патч, увеличьте:

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

дополнительные метки для метаданных pre-release и build доступны как расширения ОСНОВНОЙ.НЕЗНАЧИТЕЛЬНЫЙ.Формат патча.

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 крючки. Вижу https://github.com/petervanderdoes/gitflow-avh/tree/develop/hooks полный список.

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

VERSION=

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

exit 0

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

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

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

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

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

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

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

но минор и майор нет трюка,все они сделаны в выпуске feature finish.

Obs

Я нашел решение для подключения pre-hotfix-фиксирует, это на вопрос: как предварительно подключить исправление GitFlow?