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/namegit 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.
For completion, merge & squash from CLI:
git merge --squash /your/branch/name/Personally, I'd do this with
git rebase -iand squash manually but we can decide as a team which we prefer. Better than no decision. :)