我已经使用 git flow 几个月了,效果很好。我想自动化“凹凸版”操作。
该项目是 PHP 并且 footer.php 有一个标记来替换当前的发布标记。我确信通过 git log 和 PHP 文件的一些 awk'ing 一切都应该解决,但我假设有人之前已经这样做了......
有任何想法吗?
我已经使用 git flow 几个月了,效果很好。我想自动化“凹凸版”操作。
该项目是 PHP 并且 footer.php 有一个标记来替换当前的发布标记。我确信通过 git log 和 PHP 文件的一些 awk'ing 一切都应该解决,但我假设有人之前已经这样做了......
有任何想法吗?
您可以使用semver gem,它将一个文件添加.semver
到您的 git repo 的根目录中。语义版本号是具有结构化/一致/有意义的版本号的建议,gem 只是使其易于实现。
因此,您需要做的就是添加:
semver inc major|minor|patch
进入您的工作流程(手动或脚本),以便在发布期间更新 .semver。
如果你不想要 ruby 依赖,semver 非常简单,所以一些 sed 实验可能会产生一个可行的解决方案。
还有旨在取代 sed 魔法的bumpversion(更多信息在https://github.com/peritus/bumpversion )。
使用 安装pip install bumpversion
,告诉它哪些文件包含您的版本号以及您是否要提交和标记它。它也是高度可配置的(默认使用语义版本控制),因此您可以添加一个声明性配置文件,说明如何将此软件项目的版本升级到您选择的 vcs 中,其他人也可以升级版本。
在我的 git-flow 分支项目中,我实际上实现了钩子和过滤器,许多人在原始项目中提出了一个请求,但到目前为止还没有实现。有了这些,您可以自动更新项目中的版本号。分叉项目可以在这里找到 https://github.com/petervanderdoes/gitflow
对于版本碰撞的一些 Bash 脚本,您可以查看我创建的两个要点 https://gist.github.com/2877083或 https://gist.github.com/2878492
Semver 网页指出:
给定版本号 MAJOR.MINOR.PATCH,增加:
- 进行不兼容的 API 更改时的主要版本,
- 以向后兼容的方式添加功能时的次要版本,以及
- 进行向后兼容的错误修复时的补丁版本。
预发布和构建元数据的附加标签可作为 MAJOR.MINOR.PATCH 格式的扩展。
Gitflow 使用分支的命名约定,错误修复以前缀为前缀的分支hotfix/
,新功能以feature/
.
当这种类型的任何分支合并到发布分支时,这会导致PATCH
增加。如果一个特征已被合并,则应增加 MINOR 字段。
给定一个特定的修订版,您应该能够确定是否已合并任何一个分支以及要碰撞的字段。
困难的部分是找出一个突破性的变化。过去,我考虑过对编译后的代码使用反射来确定 API 是否已更改,但是,我认为在提交消息中使用关键字来指定重大更改会容易得多。
您还可以查看我的存储库,了解它目前为 python 设置文件制作的可以修改Using-bumpversion-package
下面是我们用来在 constants.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
如果我正确理解了您的“bump version”操作,那么您的意思是在您开始发布版本后在任意数量的文件中增加版本号git flow release start x.x.x
,其中版本也表示在 git 标记中。
由于 Driessen 的原始 git-flow 已停产,非官方的继任者似乎是 Peter van der Does 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 和 package.json)。您可以从最后一个标签中搜索旧版本,然后将其替换为循环中的所有配置文件。
注意事项:
OSX 需要后缀sed -i
,但您可以使用空引号。此外,扩展的正则表达式参数sed
在 Linux 上的命名方式不同。
您可以自动化每次提交的版本。在这里你可以使用 shell 脚本和内置的 git 钩子找到它: https ://github.com/addonszz/Galileo/tree/develop/githooks
要运行的 shell 脚本是: https ://github.com/evandrocoan/.versioning/blob/master/scripts/updateVersion.sh
自动化每件事的问题是,当您提交所有内容时,如何知道您是在更新主要、次要、补丁还是构建。
我的意思是,对于构建,您可以自动化每个开发分支提交,如上面的链接中所做的那样。
该补丁,您可以钩住每个 git flow hotfix 完成。上面的链接只是缺少挂钩修补程序完成以增加正在运行的补丁版本:
./githooks/updateVersion.sh patch
但是minor和major并没有什么技巧,它们都是在功能完成发布之内完成的。
我找到了挂钩 pre-hotfix-commits 的解决方案,这是一个问题: 如何预先挂钩 gitflow 修补程序完成?