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.

score 36 · Accepted Answer · edited Apr 12 '12 at 13:04

36

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.

edited Apr 12 '12 at 13:04

perimosocordiae

17,287
14
60
76

answered Oct 26 '11 at 16:28

Bill Door

18,272
3
32
37

2

Is a tag for every branch a bit redundant? The default merge message has the branch name in it? – onionjake Aug 08 '13 at 01:17
branch names are recorded in the bug system or any where else we would like. Viewing the changes is as easy as checking out the tag for the merged branch. – Bill Door Aug 08 '13 at 22:06
How can we properly delete the branch? – alper Jul 08 '21 at 20:53

score 27 · Answer 2 · answered Apr 12 '13 at 11:42

27

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

new merge button

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.

answered Apr 12 '13 at 11:42

VonC

1,262,500
529
4,410
5,250

I was about to ask this question and my SO-fu was just good enough to find this old question and answer. However, to be pedantic, about the specifics, @bill-door suggests performing the merge of the branch as a "marker," not unlike a record-only merge in SVN (but with less specific purpose as in SVN). I think you is suggesting to just delete the branch locally *without* a merge, after all the changes are on master and a fetch/pull should bring them in, i.e., `git branch -D topic-branch`. Correct? – javafueled Jan 09 '20 at 16:02
2

@javafueled I agree. You also have a delete branhc button on a PR branch as seen in https://help.github.com/en/github/administering-a-repository/deleting-and-restoring-branches-in-a-pull-request – VonC Jan 09 '20 at 16:04
github's Delete branch however is the remote side of the discussion. I'm thinking about the local side. – javafueled Jan 10 '20 at 01:21
1

@javafueled Once done on the remote side, you can easily prune them locally: https://stackoverflow.com/a/34969746/6309 – VonC Jan 10 '20 at 06:35

score 16 · Answer 3 · answered Oct 26 '11 at 14:23

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

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

3 Answers3

Linked