Menu
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?
489
They are a great way to work on different features and fixes while isolating the new code from the main codebase. Repos often have a main branch for the main codebase and developers create other branches to work on different features. Once work is completed on a feature, it is often recommended to delete the branch.
Tagging is also the key to solve your original problem: if you establish that any branch merged to the "work" branches can and should be deleted, and that any one that is merged to a version tag, "production", etc.
When you're done with a branch and it has been merged into master, delete it. A new branch can be made off of the most recent commit on the master branch. Also, while it is ok to hang onto branches after you've merged them into the master they will begin to pile up.
Simply put, the branch should only last a couple of days. Any longer than two days, and there is a risk of the branch becoming a long-lived feature branch (the antithesis of trunk-based development).
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:
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.
107
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
