What to do with experimental non-merged git branches?

Question

What are the current best practices with git branches that have been created to test out a solution to a bug and have not been merged because the review process show that they are wrong or there are better solutions to the problem?

An example. Project fizzbuzz has a bug report that reports a crash on empty fields.

I create a new branch handle-empty-fields and make two commit to that branch, "solving" the problem.
Then I submit that branch to the fizzbuzz project manager, linking it in the bug report.
Somebody finds an error in my fix, writes another patch and that patch get accepted.

Now the code in the handle-empty-fields my code is useless: it is not correct and cannot be applied any longer to the code, but it has been referenced in that bug report.

What should I do? Keep the branch? I will quickly end up with dozens of abandoned branch and git has no way to mark a branch as abandoned or closed. Remove the branch? But then people looking at that bug report will find it and get 404.

People are often suggested not to rebase their repositories because that will cause problems to other devs, especially downstream devs. What are the suggestions for feature or bug-fix branches?

Update: it looks like github never deletes the commits contained in pull requests. So, if you push your changes an turn them into a pull request, you can later delete the branch without losing any of your changes. Well, while github is still working ;).

Related question: https://stackoverflow.com/questions/1307114/how-can-i-archive-git-branches — Michał Politowski, Feb 24 '14 at 09:30

score 16 · Answer 1 · answered Jan 24 '12 at 15:55

16

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"

answered Jan 24 '12 at 15:55

Abizern

129,329
36
198
252

This is a nice idea. Not perfect because it just moves the problem from the branch list to the tag list, but at least the tag list is consulted rarely while the branch list is something one usually see very often. – gioele Jan 25 '12 at 06:41
To add to this: You could adopt some naming convention for tags, such as prefixing tag names for short-lived branches with "branch-". Then you can filter the tag list, or just sort it. – sleske Jun 11 '12 at 08:13

score 12 · Accepted Answer · answered Jun 21 '12 at 17:40

12

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.

answered Jun 21 '12 at 17:40

Michał Politowski

3,922
3
30
40

Would these kind of refs be pushed to remote repos? – gioele Jun 21 '12 at 20:48
@gioele They would be pushable, as any ref is pushable. But they would not be pushed by default, an appropriate refspec would be necessary on the command line or in the config. – Michał Politowski Jun 21 '12 at 21:47

sleske · Answer 3 · 2012-06-21T09:01:18.470

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.).

The problem with filtering is that I will probably be the only one with such a filtering script installed, everybody else will see all those useless branches. — gioele, Jan 24 '12 at 15:53

score 1 · Answer 4 · answered Jan 24 '12 at 15:34

This is only my point of view, but I suppose you may feel free to drop any branch that has no usefull code in it. In the worst scenario, if someone, some day will look at the bug report and will find that the link to the refused bug fix is broken... well, I don't think it looks like a big problem for anyone.

What to do with experimental non-merged git branches?

4 Answers4

Linked