in our project we use GIT as SCM. As usal we create seperate branches for new features, complex bugfixes, next version etc. . When (e.g.) a new features are fully implemented they are merged into master which is our "next version" branch (and is merged into trunk and live during later testing / deploying). So after a new feature branch is merged into master it's "dead". At the moment I delete the "dead" branches to keep the branchlist small and cleary. But as I noticed at the last delete I do this at the cost of loosing the branchs history.
My question now is: Whats the best way to deal with "dead" branches?
I'd say that branches that have been merged to master, i.e. listed by
git branch --merged
can and should be safely deleted with
git branch -d <merged_branch>
git push --delete origin <merged_branch>
One of the points of Git is that it is so easy to create (and merge) branches. You should "branch early and often". But to let all those old deleted branches lie around is messy. The important historical information is in the commits and their relationships to each other.
Remember that the auto generated message for a merge commit contains the name of the branch. So there is normally no problem in determining the original branch name (in case it contained some interesting information).
Branches that have not been merged are another matter:
git branch --no-merged
They cannot be deleted with -d, but must be deleted with -D, so it's hard to do by mistake. Personally, I eventually delete those too, but I wait a lot longer.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With