I am cleaning up our git repository and there is a feature branch which contains a prototype of an interesting feature which the management decided not to include soon in the product.

What do you do in such a situation with the feature branch? Is that a situation where the github gist functionality might be helpful?

  • Leave it in the feature branch until you decide if and when you're going to use it? Commented Mar 21, 2016 at 15:03
  • 3
    I'm assuming by "clean up", you mean "delete branches". If there's still value in having the branch around, why do you need to delete it?
    – Thomas Owens
    Commented Mar 21, 2016 at 15:04
  • 2
    Please clarify what your goal is. Do you want to have less branches? Why? Are you afraid people will be confused by un-merged branches?
    – sleske
    Commented Mar 21, 2016 at 15:12
  • 1
    Thanks for the comments. Yes I am afraid that a) branches are getting outdated and more importantly b) people are getting confused if there are two many branches I am afraid.
    – user695652
    Commented Mar 21, 2016 at 15:49

3 Answers 3


You should probably not completely nuke this work from history and it should be clear for anyone else what this prototype is about and what to do about it. So, you have to keep and document it.

For example, if you have a developer guide, a bug tracker, a todo list, ... add an entry for that branch to keep a reference about the feature. Later, someone can check through the unmerged features and decide again if they are worth integrating. Alternatively, or additionally, use...

Annotated tags

It can make sense to prefer having branches only for actively developed work and use tags for trees that are not going to change anytime soon. So if you replace your branch by an annotated tag, you (1) remove a branch and (2) have an opportunity to document it:

git checkout branch
git tag -a unmerged/featureA
# Write in editor
git checkout master
git branch -D branch 

Ideally, write a bunch of automated tests for this feature, then commit it to master without any way to access it externally (so no UI, and no public API for it) and then continuous integration will ensure the code for that feature remains functional until you finally get around to exposing it. No dangling branches to worry about.

Of course, this is only a good idea if it's extremely likely the feature will get used someday, it's extremely likely the requirements for it will not change drastically before that happens, and you can write meaningful unit/integration tests for it without exposing access to it. If any of those do not apply, then you'll probably have to or want to rewrite a lot of the code anyway when the feature becomes desirable. In that case the current branch will only be useful if you think simply looking at it or selectively copying bits of it will help when it's time to rewrite it, in which case I'd leave that branch as-is (or convert it to a tag) for future reference without any attempt to keep it mergeable over time.


If you are absolutely certain that you will never need it again and it should go away, then delete all tags and branches pointing to it, and git will eventually garbage collect the "loose" commits.

If you want to keep it but not have a loose branch (which indicates development work) then convert the branch to a tag.

You may also simply fork or clone the repository to an archival location where people can go if they for any reason need the old functionality. You can then prune the working repository to what you actually need. I used this for a CVS->Subversion->Git conversion with a lot of old binary artifacts we did not need. Having the full converted repository in back storage, allowed us to safely trim the future repository heavily to remove the binary artifacts and move some files in their future locations while retaining history.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.