如何预钩gitflow修补程序完成? [英] How to pre-hook the gitflow hotfix finish?

查看:170
本文介绍了如何预钩gitflow修补程序完成?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想我正在使用 https://github.com/nvie/gitflow ,如果这是Smartgit GUI程序中的一个。



每次我提交一些内容时,我都会更新'build'编号。例如:2.6.0-77到2.6.0-78

这已经实现了钩住预先提交并递增内部版本号,但是如何创建一个钩子挂钩gitflow修补程序完成并增加修补程序版本号?示例:2.6.0-70到2.6.1-70



增加修补程序版本的代码已经完成。我们只需要运行:

githooks / updateVersion.sh patch



<然后,我们在项目中获得了2.6.0-70到2.6.1-70。此代码在此处执行: https://github.com/evandrocoan/.versioning



在那里,pre-commit,post-commit挂钩被实现。



如果不能完成,我们可以在pre-commit钩子上执行它?我们只需要知道我们什么时候提交普通的东西,以及何时提交了gitflow完成修补程序。 我也可以考虑阅读提交消息,然后确定
是否是普通提交(./githooks/updateVersion.sh build)或修补程序(./githooks/updateVersion.sh修补程序)。

我的意思是,在项目上创建一个模式,并且只在完成修补程序中使用该关键字,这将通过预提交钩子获取。类似的,总是要在完成修补程序这个单词中开始一个修补修补程序。

然后,同样可以应用于次要和主要版本,然后我们可以随时自动更新软件版本。



Obs



假设版本为Major.Minor.Patch-Build ,其中build是提交计数器,它在每次开发分支提交时都增加。



但这是一个错误的分支模型,我们不能将事情放入开发分支中,我们必须创建功能分支。
我们总是增加补丁编号,每个补丁发布。但不要触摸内部版本号。
然后我们应该增加内部版本号,每个功能完成。
每次发布开始时增加主要或次要数字,具体取决于主要功能或次要功能版本。

但是这会导致问题。如果我们创建了特征A,B和C,则完成特征A,然后递增构建编号,但是当我们完成特征B或C时,如果它们的构建编号已过期,是否会发生冲突。



解决方案是在每个功能完成前集成开发,他们可以在集成时获得正确的内部版本号,然后避免冲突。 b

I think I am using the "https://github.com/nvie/gitflow", if that is the one which comes within the Smartgit GUI program.

Every time I to commit something, I update the 'build' number. Example: 2.6.0-77 to 2.6.0-78

This is already implemented to hook the pre-commit and increment the build number, but how to create a hook to hook the gitflow hotfix finish and to increment the hotfix version number? Example: 2.6.0-70 to 2.6.1-70

The code to increment the hotfix version is already done. We just need to run: githooks/updateVersion.sh patch

Then, we got 2.6.0-70 to 2.6.1-70 over the project. This code is implemented here: https://github.com/evandrocoan/.versioning

There, the pre-commit, post-commit hooks are implemented.

If it cannot to be done, we could to do it on the pre-commit hook? We just need to know when we are committing something ordinary, and when we are committing the gitflow finish hotfix.

解决方案

I can also think about to read the commit message and then determine whether it is a normal commit (./githooks/updateVersion.sh build), or an hotfix (./githooks/updateVersion.sh patch).

I mean, to create a pattern over the project and only at the finish hotfix to use that keyword, which will be got by the pre-commit hook. Something like, always to start a finish hotfix within the words 'Finish hotfix'.

Then also, the same could be applied to minor and major releases, then we could always automatically update the software version.

Obs

This assumes a version were "Major.Minor.Patch-Build", where build is the commit counter which is incremented every develop branch commit.

But this is a wrong branching model, we cannot commit things into the develop branch, we must create feature branches. We always increment the Patch number, every hotfix Release. But do not touch the build number. Then we should increment the the build number, every Feature Finish. And increment the Major or Minor number every Release Start, depending it was major features or minor features release.

But this causes a problem. If we create Features A, B and C. Finish the feature A, then increment the build number but, when we finish the Feature B or C, if will give a conflict because their build numbers are out-of-date.

The solution is to integrate the development before every feature finish, them we can get the right build number while integrating, then we avoid conflicts.

这篇关于如何预钩gitflow修补程序完成?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆