102

I don't want to end up with 82 feature branches hanging around, so I'm wondering what the potential drawbacks are to simply deleting the feature branch as soon as I merge it to master.

Workflow:

git co -b feat-xyz
hack hack
git ci
hack some more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz

Any issues here?

Improve this question
6
  • 1
    I would say no issues because if you really need them you can always resurrect the deleted branch later.
    – slebetman
    Commented Aug 2, 2010 at 23:09
  • @slebetman As far as I know a deleted branch can not be resurrected. However if the branch was fully merged into master before deleting it, there should not be any need of the branch any longer.
    – Simeon
    Commented Apr 18, 2017 at 10:25
  • 1
    @Simeon Yes you can. Git never deletes commits so when you delete your branch you are just deleting it's name. To resurrect a deleted branch you just need to remember the last thing you committed to that branch and you can search git reflog for it. Then checkout the hash
    – slebetman
    Commented Apr 18, 2017 at 15:13
  • @slebetman that will only be true if the branch was eventually merged. if the commits are left behind, they will eventually become unreachable and will be subject to garbage collection after certain amount of time. even the entries in the reflog will eventually be purged, you have about 90 days by default.
    – goldenratio
    Commented Feb 1, 2018 at 5:10
  • @goldenratio: Any reference for that?
    – slebetman
    Commented Feb 1, 2018 at 8:07

5 Answers 5

Reset to default
109

I delete after merge, but I always do a git merge --no-ff, to avoid fast forwarding so that the branch history is visible on the graph. I like to have the history of where the feature branch departed from the development branch and where it joined back:

Merging with or without fast-forwards

This is taken from A successful Git branching model by Vincent Driessen, a very nice workflow to use with git which I apply for most of my projects.

Improve this answer
3
  • This is another nice way to preserve history, because you can select the commits that are reachable from the feature but not from master: rev^1..rev^2. The down side is that it screws up any rebasing you might want to do from your master branch (e.g., if you want to keep master rebased onto upstream remote, which is very common).
    – masonk
    Commented Aug 3, 2010 at 12:27
  • 1
    I didn't have that problem. Our team sync through github, and I don't usually need to rebase, but I don't think it is a downside here. Even if you rebase your develop and feature branch, the branching stays visible on the graph, and what matters is what is in the feature branch relative to the development, not the commit where you originally departed when you created that branch.
    – lkraider
    Commented Aug 3, 2010 at 21:27
  • @Ikraider, thanks for the reminder. I saw that article when I was first learning git, it makes more sense to me now. I rebase my feature branches, but I merge --no-ff back onto master because like you say you can see the history.
    – bstpierre
    Commented Aug 4, 2010 at 4:19
69

Delete after merge is the usual way. This is why git branch -d yourbranchname checks to make sure that the branch is fully merged before it will delete.

There are a few reasons that I can think of to keep a branch around: you might want to hold onto it in case you have bugs coming back once it hits production, or you might want a historical record.

In either case, you have the option of tagging the head of the branch before you delete it. A tag is like a branch in that it is a pointer to a commit, except for a few minor differences:

  1. porcelain usually doesn't display tags in exploratory commands like git show-branch or tab-auto complete in checkout,
  2. checking one out puts you in a detached (non-ref) HEAD
  3. you can leave a "tagging message", which causes the tag to be saved as an object in the object store like a commit.

This way you preserve history, and if you ever do need to bug fix, I recommend just creating a new branch off of master for the fix.

Improve this answer
2
  • 1
    Checking a tag out does set HEAD, but does not automatically create a branch. A HEAD on a commit without a branch is what makes it detached.
    – Binarian
    Commented Jul 16, 2017 at 11:41
  • 1
    You're right, it sets HEAD to a commit id rather than a ref. That part of my OP is incorrect. I should update it.
    – masonk
    Commented Jul 16, 2017 at 12:29
12

Typical workflow will be 

 // Create new branch
 $ git checkout -b myfeature
 // and then do some changes and commit them

 // Switch to master branch
 $ git checkout master

 // Merge myfeature to master. --no-ff will always keep branch information.
 $ git merge --no-ff myfeature

 // Delete myfeature branch
 $ git branch -d myfeature

 // Push the changes
 $ git push origin master
Improve this answer
7

I can think of two reasons why you might want to keep a feature branch around for a bit:

  • There is a chance it will get kicked back to you for more work by upstream.
  • Other developers possibly wanting that feature without wanting everything else in master.

In practice, most of the time deleting after merge is just fine.

Improve this answer
1

i think that is the typical workflow (deleting after merge)

EDIT So, rather than merge, at least for short lived branches, i think the idea is to rebase them on to the master. then you end up with a linear change history, and the entire branch becomes part of the main trunk. in this case you have all the changes there so you clearly don't need a copy.

Improve this answer
4
  • So there really is no point in keeping the branch around, right?
    – bstpierre
    Commented Aug 2, 2010 at 23:06
  • 1
    I strongly recommend avoiding "rebase". Rebasing is generally harmful, only useful in some cases.
    – Dietrich Epp
    Commented Aug 3, 2010 at 1:16
  • 9
    Rebasing is a perfectly reasonable workflow for your local, private branches. It's very common to keep in sync with upstream work by rebasing for instance ("rebasing down"). It's much less common, and usually harmful, to rebase up*. second's answer doesn't really make sense, because whether you are rebasing or merging in upstream changes, you still have to push that stuff "up" somehow. Even on your local branch, you'll have to merge in your feature to master at some point. The advantage of staying rebased on your features is that this merge becomes fast forward.
    – masonk
    Commented Aug 3, 2010 at 4:05
  • 1
    There's something to watch out for with rebasing branches, though, which bit me recently. It's obvious now, but I went for months on a long-lived branch, always rebasing the entire thing against master. It ended up around 600 nice, granular commits, but master had been wildly refactored and wholly changed about many times. By rebasing the entire branch every time, I was cutting its older commits from their connection to master commits that made sense to them. Now I much prefer to merge in master when needed. I'll only rebase if the history of the branch will absolutely not be affected.
    – Gary Fixler
    Commented Apr 15, 2013 at 9:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.