Search code examples
gitversion-controlbranch

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 more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz

Any issues here?

Solution

  • 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.