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-fieldsand 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 ;).
git update-ref refs/Attic/handle-empty-fields refs/heads/handle-empty-fieldsAs 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.