What to do with experimental non-merged git branches? What to do with experimental non-merged git branches? git git

What to do with experimental non-merged git branches?


The way I do it is to give it a tag. Use a full tag and give it a descriptive name. Then you can delete the branch, so it doesn't show up in your branch listings, but because it's tagged, the branch can still be recreated by checking out the branch. All the commits on the tag will still be available, and you won't lose any commits in a git gc Something like this, perhaps:

git tag -a partialBugfixXXX -m"Tagging a branch that went into fixing bug XXX"


git update-ref refs/Attic/handle-empty-fields refs/heads/handle-empty-fields

As an alternative to preserving dead branches in tags you could use a separate refs namespace. The upside is that the tag list stays uncluttered. A downside is moving from the porcelain to the plumbing level of git.


I think this will depend on the exact circumstances. Possible solutions:

  • Add a comment to the bug report, indicating that the branch mentioned turned out to be useless and was deleted. If you feel the branch had some value, briefly describe what you did. That way people get the necessary information even though the branch is gone.

  • Keep the branch, but somehow rename it to mark it as "abandoned". Add a comment to the bug report to indicate this (and change the link to the branch). You could for example have some convention like prefixing "OLD-" to branch names.

  • Tag the branch, then delete it (and again mention this in the bug db entry). That way the branch can be removed, but the commits are still accessible via the tag. Note that git offers simple name spaces for tags (and branches) - you can include a '/' in the name. You could just agree on a convention, such as using tags under "oldbranch/". (Adapted from Abizern's answer.)

  • Once the branch has been merged, you can just mention/link the merge commit in the bug report. Then the branch is probably less interesting, because it is contained in the merge commit.

Generally, you might want to adopt a special naming convention for bugfixing branches.

In my (personal) git repo, for every bug I find I first open a bug in the bug DB. If I then work on it, I create a branch whose name ends with the bug ID (e.g. "opencrash-342", "handle_empty_file-663"). That way the relation between bug DB and branches is obvious.

Also, if the list of branches gets too long, you can always filter by the appended ID (e.g. make a list of closed bugs, and some small script to filter these out of the output of "git log" etc.).