Add ability to release directly from develop

[fabn]

In some personal projects (with no version file, or any other artifact to be generated) it could be useful to make a release directly from develop. For instance a git managed website doesn't need anything to be done into the release branch, so it could be useful release a new version without starting a release branch first. This would avoid useless empty merge commit into the repository history.

What do you think?

[orefalo]

You may use HotFixes to release directly to master

[fabn]

Maybe I wasn't clear in my request. However, I made some experiments, here is a small demo with a fake project https://github.com/fabn/fake-project/network. I was wrong about a point, if I execute these commands on a project

git flow release start xxx
git flow release finish xxx

they don't introduce useless commits, only some noise given by the fact that a commit named "merge branch 'release/xxx' exists in the repository. My point was that in some (simple) projects there is no work to be made in the release branch, so imho it would be nice to have an option (or a release subcommand) which avoid to type two commands when unnecessary. So instead of the two commands above making a release from the current develop branch we have to type something like

git flow release finish -f xxx # -f stands for force because no previous start was given

[kennethreitz]

Why not just git tag v1.0.0 and merge --no-ffinto master?

[fabn]

Yes, it would be an option to do that. But also the other gitflow features could be implemented with vanilla git commands, so my request is just for having a shortcut to do that.

[motlin]

+1 My project never has a QA since it's a library. If it passes all tests, we release.

[jeffkreeftmeijer]

I find myself wanting to do this from time to time. How about something like an instant_release? :)

[boryn]

+1 Yes, I would also like to go directly from develop branch to the production one without the release branch

[baby-gnu]

Hello,

+1

I use my branches like the following

• master: development
• features/<some name>/<rebased on SHA1>: new features, rebaseable from time to time (new branch name with abbreviated sha if published)
• fix/: fixes based on oldest supported release

I make tags named release/<version number> to keep the supported version and as base for DaggyFixes

When a new feature is ready, I rebased it on latest master to avoid fixing conflict "on master", then merge it to master.

To prepare a new release, if required, I create an rc/<version number> but it's rarely necessary.

When a new release is ready, I just tag a commit on master, If I have an rc/<version number>, I tag create the tag on HEAD of rc/<version number> and then merge it in master.

The "tagging before merge" join #206 #49 and #85