tags:

views:

123

answers:

4

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?

+1  A: 

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.

second
So there really is no point in keeping the branch around, right?
bstpierre
I strongly recommend avoiding "rebase". Rebasing is generally harmful, only useful in some cases.
Dietrich Epp
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
+2  A: 

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.

Karl Bielefeldt
+4  A: 

Delete after merge is the usual way. This is why git branch -d 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 doesn't set HEAD (you will be in a detached HEAD), and 3) you can leave a "tag" note on top of the note on the commit that it points at.

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.

masonk
+5  A: 

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.

lkraider
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
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
@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