Gitflow: ability to delete/remove release/hotfix/features easily

Created on 26 Aug 2010  ·  60Comments  ·  Source: nvie/gitflow

It would be great to have the ability to do something like git flow release delete v1.0.2, instead of git checkout develop && git branch -D release/v1.0.2 (which I'm not even sure correctly discards a release branch) and hoping no important steps were missed.

Feature

Most helpful comment

please, stop commenting just "+1", it's 2020 and Github already introduced emojis for this purpose 👍

All 60 comments

That would be a good extra command.

PS: It is indeed the correct way to delete a branch. (Remember, git-flow doesn't do any hidden magic, it's just an implementation of the rules from the original blog post!)

I would propose the following. If it is merged already in develop/master, but the branch pointer remains:

git flow release delete 1.0.2

To delete branched that are yet unmerged with develop/master (in order to avoid accidental deletion):

git flow release delete -f 1.0.2

Ah, indeed. I would be quite happy with that functionality of the feature.

I was unsure about that being the correct procedure because it seemed like when I tried it, the commits I'd made to the deleted branch got merged into develop anyways, which really annoyed me, but I managed to take care of it and move along. Just to be clear, this would/should completely remove the entire branch and all its commits, given the -f flag, correct?

Strictly speaking, it removes the _branch_ object, which points to a commit (which points to a commit, which points to a commit, etc.). As long as you have any other branches pointing at one of those commits (like origin/feature/foo maybe), the commits will stick around. Otherwise, they'll be garbage collected eventually. That's just Git behaviour.

Hmm, oh well. I must have screwed something up. Thanks for explaining, though!

+1 this feature. I'm trying to use git-flow to use the release candidates as our sprint deliverables, to be pushed to the testing environment, while maintaining master as the production codebase. In other words, in our environment, most release candidates will NOT be getting 'finished' to go to master - but all should be _able_ to... so once a production release has been identified, I'd like to end the other release branches...

+1

+1

+1

+1

+1

+1 and I decided to implement this on my fork, currently only in the develop branch. Also added the ability to remove the remote branch as well.

+1 for this, is this feature supported now?

+1

Used this thread to figure out how to do it but would prefer built in method

It's been 2 years now... any chance it will get done? It's a good feature, I think.

+1

+1

+1

Hello, it's already available in Peter van der Does fork with several other improvements.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+4 (myself and my team @ work)! ^_^

+1

+2

@nrvs lolz :D
:+1:

+1

:+1:

+1

:+1:

+1

+1

+1

+1

+1

+1

+1

This is implemented in avh edition.

+100500

+100501

+1

+1

+1

+1

+1

+1

Wow, can't believe this is still a thing. It's been almost 8 years waiting for this command.

+1

+1

wow, after nine years, this is still a thing
really need this feature

This is implemented in https://github.com/petervanderdoes/gitflow-avh It's backwards compatible with this version but adds many improvements and new features.

Disclaimer: I'm the project lead for Gitflow AVH Edition

+1

please, stop commenting just "+1", it's 2020 and Github already introduced emojis for this purpose 👍

@geoom
image

+1

Was this page helpful?
0 / 5 - 0 ratings

Related issues

RoLYroLLs picture RoLYroLLs  ·  4Comments

88Alex picture 88Alex  ·  17Comments

alanhogan picture alanhogan  ·  6Comments

erikhuizinga picture erikhuizinga  ·  4Comments

keithamus picture keithamus  ·  32Comments