You will need to create a branching strategy that works best for your team, of course. But here is a quick example of how to follow a branching strategy workflow involving two types of branches: a develop/integration branch and a feature/topic branch.

Let's say you are working on a new feature. Suddenly, somebody finds a bug in the production and you are now tasked to fix that bug parallel to working on the new feature.

On the way of work on a topic branch to add functions, it becomes necessary to fix bugs.

Before starting on the bug fix, you can create a new branch off of the develop/integration branch. This new branch will isolate the bug fix from the new feature that you were working on.

You can start working independently from the addition of functions by creating a new topic branch for fixing bugs.

When you are ready to release the bug fix, merge the bug fix feature/topic branch into the develop/integration branch.

You can make it public by including it in the original branch

Then you can switch back to your original feature/topic branch and continue working on the new feature.

You can go back to the original branch to continue working on the addition of functions

On your feature/topic branch, you will notice that commit "X", which is the bug fix commit, is needed to continue implementing the new feature. In other words, you will have to synchronize your current branch with the changes on the develop/integration branch.

There are two options to go about doing this. The first is to merge the develop/integration branch that includes commit "X" with the current branch.

The second option is to rebase the current branch to the develop/integration branch that includes commit "X".

For this example, we will use the rebase approach.

Rebase a unified branch

Once you commit "X" on our current branch, you can safely proceed to work on your new feature.