What do you do with your branch after a pull request on GitHub?

Question

My team is experimenting with using GitHub pull requests for code reviews. My only question is what do you do with the branch after you're done? I would think you'd want to delete the branch, but since GitHub hides branches that have been merged into your current branch, it seemed like maybe I should keep it.

Just curious on what your thoughts on best practices for this are.

Answer 1

The rule of thumb that we use (which is here some where on Stack Overflow) is "branches are for work, tags are for history".

Whenever a branch is merged (most likely into master) we tag the merge point using the name of the branch with the prefix "branch" (e.g. branch-topic). Then delete the branch. If we need to resurrect work at the branch point we have the tag to be able to do that.

There are of course exceptions. We have long running branches that we use for various kinds of continuing work. But in general, topic branches are deleted after merging.

On that note, those merges are always done with

merge --no-ff <branch>

This ensures that there is a merge point and a record of the merge occurring.

Answer 2

Note that since April, 10th 2013, "Redesigned merge button", the branch is deleted for you:

Deleting branches after you merge has also been simplified.
Instead of confirming the delete with an extra step, we immediately remove the branch when you delete it and provide a convenient link to restore the branch in the event you need it again.

That confirms the best practice of deleting the branch after merging a pull request.

Answer 3

I always delete branches that have been merged into master. A Git branch, after all, is a pointer to a commit, and that commit is now available in the history of another branch, so I don't need the branch anymore. (You can always recreate the branch by looking at the parents of the merge commit.)