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.


  • Merging changes from master into all branches using Git?
  • “if” versus “switch”
  • How to pick a commit in sub-branch and merge it into main branch?
  • Git: set the tip of a branch to a particular commit
  • How to set a folder to be used in different branches in git?
  • how to create a git branch that is independent of the master branch?
  • 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?

  • Capistrano -“ Cannot allocate memory - git” while deployment
  • Git log with netbeans GUI
  • gitignore settings included in commit
  • How to show date's day part with a leading zero in Git log with --date=local?
  • How to restrict branch deletion access in gitolite
  • git pull to branch_1 and merge into current branch simultaneously
  • 5 Solutions collect form web for “When is the right time to delete a git feature branch?”

    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 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:

    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.

    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.

    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 think that is the typical workflow (deleting after merge)

    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.

    Git Baby is a git and github fan, let's start git clone.