什么时候是删除 Git 特性分支的合适时机？

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.

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.

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.

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.

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