When is the right time to delete a git feature branch?

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 mo开发者_开发知识库re
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz

Any issues here?

---

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:

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.

---

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.

---

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

---

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.

---

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.