Menu
We're using a A successful Git branching model by Vincent Driessen for our branching model. All's fine but I haven't really seen a particular issue brought up.
From what I've understood, when a new feature is required, you branch of the development and create a new feature branch. You would work on this and when you're done, you would merge this branch into the the development branch.
What if a developer makes a feature and then merges that feature back to development only to be found out that there's some bugs in the feature code. Where should this be fixed? Should a new fix/bugfix branch be started from development and the code be fixed there? I can't see another way.
How should one go about this?
Thanks
616
There's no such thing as “the” bugfix branch. It's common practice for a developer to create a branch whenever they're working on anything that they expect to result in a commit. That might be developing a new feature (this is often called a “feature branch”) or fixing a bug (a “bugfix branch”).
The topic branches created off the release branch to deal with issues are known as bugfix branches. Gitflow bugfix branches only interact with the release branch. The Gitflow bugfix branch should not be confused with the hotfix branch which interacts exclusively with the master branch.
Bugfixes generally describe issues that are found and resolved during production or testing phases or even after deployment as part of the normal release cycle of a product. Hotfixes are applied only after the product has been released and is live.
Remember that a model is just a model - it's about giving you a structure that makes you more efficient, not blindly following a set of rules. That means that you should feel free to tweak things and figure out what works in your situation, because it may not work in every situation.
I think you have a choice in this situation:
Which one you choose depends on factors like:
The difference between a feature branch and bugfix branch isn't important from Git's point of view. It only matters if you use those labels for internal documentation or other auditing purposes (e.g. to keep track of what is visible to external users).
Resist the temptation to work straight off the development branch even if you think the bugfix will be very quick - nothing is ever quite as simple as it seems, and you will give yourself a headache later if anything goes wrong.
Rough visual representation of your choices:
53
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
