Recently, I completed a pull request and merged my branch into staging
once approved. In the past, I've seen some developers delete their branch after merging and others don't do this. I've historically been pretty bad at this myself and was wondering what the team thinks about this.
I think that deleting branches after a successful merge should be a practice followed by everyone on the team. There are a lot of good reasons to do this and there's really no reason not to, IMHO. Currently, on staging
, there are 229 branches! (git branch --all | wc -l
) Of those 229, 69 of them show as "merged" (git branch --all --merged | wc -l
). Running git branch --all
is far less useful in this state.
This is where I'm also looking for team input. The easiest thing would be to always click the Delete Branch button after merging on Github's web interface. Then it would just be a matter of running git prune
locally to remove deadwood. If you're cool, you'd:
git merge /your/branch/name
git branch -dr /your/branch/name
This could also be something we trigger off of a successful pull-request (i.e. ready to merge) with automation but that's a bit outside my wheelhouse.
Eventually, we'd want to run a git --remote prune origin
to purge any deadwood on the remote and devs could git fetch --prune
to sync up.
Agreed and I do this myself already