Bug fixes in a feature branch

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:

1. Roll back the merge and continue work on the feature branch until it is ready
2. Start a new branch to fix the bug.

Which one you choose depends on factors like:

• Can your customers see the bug? Make a bugfix or hotfix branch.
• Is the bug really bad and stop other progress on the development branch? Roll back the change.
• Is it only a minor issue with minimal external impact? Simply continue work on the feature branch and merge again when ready.

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:

How about finding the commit that introduced the bug, and creating a new branch rooted there? With this approach:

• There's no risk of creating broken references due to rebase operations
• Just from the ancestry of the development branch, the feature branch, and any other branch that may be affected, you can tell where you should merge your bugfix branch once it's done. This is true even if "feature" has merged with "development" several times since the introduction of the bug.
• If you identify the commit that introduced the bug, and root from there, developers will be able to tell where they need to merge the bugfix branch, even if they're not familiar with the repo layout
• You'll have a branch that you can merge without fear of pulling in unrelated subsequent changes. For example - let's say someone is working on "feature-beta" which is a sub-branch of "feature" that diverged shortly after the bug was introduced. They can pull in the bugfix branch easily, without worrying about also pulling in everything else that has occurred on "feature".
• This approach reduces the need to cherry-pick, which has the downside that it changes the name of commits (thus undermining one of git's great advantages, which is applying an unambiguous name to everything.)

If that feature branch is a public one (i.e pushed to a remote repo which is cloned / used by others), it is best to make a new branch and isolate the debug in said fix branch.
(instead of trying to rebase 'feature' branch on top of 'develop' branch).

The idea remains to not record intermediate debug commits directly in develop branch, but to record only the resulting commit that will fix the bug introduced by feature branch merge in the first place.