bash 寻找一种使用 git flow 自动化“凹凸版本”的方法

Looking for a way automate the "bump version" with git flow

提问by spdaly

I have been using git flow for a couple of months and it has worked very well. I would like to automate the "bump version" operation.

我已经使用 git flow 几个月了，效果很好。我想自动化“凹凸版”操作。

The project is PHP and the footer.php has a token to replace with the current release tag. I am certain that with some awk'ing of git log and the PHP file everything should work out, but I assume someone has done this before...

该项目是 PHP 并且 footer.php 有一个令牌来替换当前的发布标签。我确信通过 git log 和 PHP 文件的一些 awk'ing 一切都应该解决，但我假设有人以前做过这个......

Any ideas?

有任何想法吗？

采纳答案by AD7six

You could use the semver gem, which adds a file .semverto the root of your git repo. Semantic version numbersare a recommendation for having structured/consistent/meaningful version numbers, the gem just makes it easy to implement.

您可以使用semver gem，它将文件添加.semver到您的 git 存储库的根目录。语义版本号是对结构化/一致/有意义的版本号的推荐，gem 只是使它易于实现。

So, all you'd need to do is add:

所以，你需要做的就是添加：

semver inc major|minor|patch

into your workflow (manually or scripted) so that the .semver gets updated during a release.

进入您的工作流程（手动或脚本），以便 .semver 在发布期间得到更新。

If you don't want the ruby dependency, semver is pretty simple, so a bit of sed experimentation will likely yield a working solution.

如果你不想要 ruby​​ 依赖，semver 非常简单，所以一些 sed 实验可能会产生一个可行的解决方案。

回答by peritus

There's also bumpversion(more info at https://github.com/peritus/bumpversion) that aims to replace that sed magic.

还有旨在取代 sed 魔法的颠簸版本（更多信息，请访问https://github.com/peritus/bumpversion）。

Install with pip install bumpversion, tell it which files contain your version number and whether you want to commit and tag that. It's also highly configurable (with semantic versioning as default), so you can add a declarative config file of how to bump versions for this software project to your vcs of choice and others can also bump versions.

使用 安装pip install bumpversion，告诉它哪些文件包含您的版本号以及您是否要提交和标记它。它也是高度可配置的（默认使用语义版本控制），因此您可以添加一个声明性配置文件，说明如何将此软件项目的版本升级到您选择的 vcs，其他人也可以升级版本。

回答by Peter van der Does

In my forked project of git-flow I actually implemented hooks and filters, a request that many made in the original project but so far has not been implemented. With those you can automatically update version numbers in your project. The forked project can be found here https://github.com/petervanderdoes/gitflow

在我的 git-flow 分叉项目中，我实际上实现了钩子和过滤器，这是许多在原始项目中提出但到目前为止尚未实现的请求。有了这些，您可以自动更新项目中的版本号。分叉的项目可以在这里找到 https://github.com/petervanderdoes/gitflow

For some Bash scripts on version bumping you can check out two gists I created https://gist.github.com/2877083or https://gist.github.com/2878492

对于版本碰撞的一些 Bash 脚本，您可以查看我创建的两个要点 https://gist.github.com/2877083或 https://gist.github.com/2878492

回答by Dave Hillier

Semver webpage states:

Semver 网页指出：

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards-compatible manner, and
• PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

给定版本号 MAJOR.MINOR.PATCH，增加：

• 进行不兼容的 API 更改时的主要版本，
• 以向后兼容的方式添加功能时的 MINOR 版本，以及
• PATCH 版本，当您进行向后兼容的错误修复时。

预发布和构建元数据的附加标签可作为 MAJOR.MINOR.PATCH 格式的扩展。

Gitflow uses a naming convention for branches, bug fixes live on branches prefixed with hotfix/and new features are prefixed with feature/.

Gitflow 使用分支命名约定，错误修复存在于以hotfix/为前缀的分支上，新功能以feature/.

When any branch of this type is merged into release branch this causes the PATCHto increase. If a feature has been merged the MINOR field should be increased.

当这种类型的任何分支合并到发布分支时，这会导致PATCH增加。如果已合并要素，则应增加 MINOR 字段。

Given a specific revision, you should be able to figure of if either of the branches have been merged and which field to bump.

给定一个特定的修订版本，您应该能够确定是否已经合并了任何一个分支以及要碰撞的字段。

The hard part is figuring out a breaking change. In the past I've considered using reflection on compiled code to determine if the API has changed, however, I figure it would be much easier to perhaps just use a keyword in commit messages to designate breaking changes.

困难的部分是找出一个突破性的变化。过去，我曾考虑对已编译的代码使用反射来确定 API 是否已更改，但是，我认为在提交消息中仅使用关键字来指定破坏性更改会容易得多。

回答by Danny Schoemann

Here is the code we use to increment the version number in constants.h:

下面是我们用来在 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    

回答by Hymanotonye

You can also take a look at my repo for bumpversion its currently made for python setup files which can be modified Using-bumpversion-package

您还可以查看我的 repo 以获取当前为 python 设置文件制作的bumpversion，可以使用-bumpversion-package对其进行修改

回答by user

You can automate the version bumping every commit. Here you can find it done using the shell script and the built-in git hook: https://github.com/addonszz/Galileo/tree/develop/githooks

您可以自动执行每次提交的版本碰撞。在这里你可以找到它使用 shell 脚本和内置的 git 钩子完成：https: //github.com/addonszz/Galileo/tree/develop/githooks

The shell scrip to run is: https://github.com/evandrocoan/.versioning/blob/master/scripts/updateVersion.sh

要运行的 shell 脚本是：https: //github.com/evandrocoan/.versioning/blob/master/scripts/updateVersion.sh

The problem about automate every thing is how to know whether you are updating the Major, Minor, Patch or Build, when you are committing everything.

自动化每件事的问题在于，当您提交所有内容时，如何知道您是在更新主要、次要、补丁还是内部版本。

I mean, for build you could automate every development branch commit, as done in the above link.

我的意思是，对于构建，您可以自动化每个开发分支提交，如上面的链接中所做的那样。

The patch, you can hook every git flow hotfix finish. The above link just lacks to hook the hotfix finish to increment the patch version running: ./githooks/updateVersion.sh patch

这个补丁，你可以钩住每一个 git flow hotfix 完成。上面的链接只是缺少挂钩修补程序完成以增加运行的补丁版本： ./githooks/updateVersion.sh patch

But the minor and major there is no trick, they are all done within the feature finish release.

但是minor和major没有什么窍门，它们都是在feature完成发布的时候完成的。

Obs

观察者

I found a solution to hooking the pre-hotfix-commits, it is on the question: How to pre-hook the gitflow hotfix finish?

我找到了一个挂钩 pre-hotfix-commits 的解决方案，问题是： How to pre-hook the gitflow hotfix finish?

回答by atripes

If I understand your 'bump version' operation correctly, then you mean increasing the version number in an arbitrary number of files once you started a release with git flow release start x.x.x, where the version is also represented within the git tag.

如果我正确理解了您的“凹凸版本”操作，那么您的意思是在使用 开始发布后在任意数量的文件中增加版本号git flow release start x.x.x，其中版本也在 git 标签中表示。

Since the original git-flow from Driessen was discontinued, the unofficial successor seems to be Peter van der Does gitflow-avh(https://github.com/petervanderdoes/gitflow-avh/), which contains a great number of git flow hooks. See https://github.com/petervanderdoes/gitflow-avh/tree/develop/hooksfor a complete list.

由于 Driessen 的原始 git-flow 已停产，非官方的继任者似乎是 Peter van der Does gitflow-avh( https://github.com/petervanderdoes/gitflow-avh/)，其中包含大量 git flow hook。有关完整列表，请参阅https://github.com/petervanderdoes/gitflow-avh/tree/develop/hooks。

I did version bumping on post-flow-release-startwith this little script:

我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

It is a bit rigid, because the two files are hardcoded (README.md and package.json). You could do a search for the old version from the last tag and then repleace it for all configured files within a loop.

有点死板，因为这两个文件是硬编码的（README.md 和 package.json）。您可以从最后一个标签搜索旧版本，然后为循环中的所有配置文件替换它。

Caveats:
OSX requires a suffix for sed -i, you can use empty quotes though. Also, the extended regex param for sedis named differently on Linux.

注意事项：
OSX 需要后缀 for sed -i，但您可以使用空引号。此外，扩展的正则表达式参数sed在 Linux 上的命名不同。