Add ability to release directly from develop #133

Closed
fabn opened this Issue Jun 21, 2011 · 8 comments

Comments

Projects
None yet
8 participants

fabn commented Jun 21, 2011

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 commented Jun 22, 2011

You may use HotFixes to release directly to master

fabn commented Jun 25, 2011

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

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

fabn commented Jun 25, 2011

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 commented Jun 25, 2011

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

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

boryn commented Aug 24, 2011

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

baby-gnu commented Jul 4, 2012

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

@nvie nvie closed this Jul 9, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment