Basically the structure can be like this:
and you can switch between the two, which makes sense and then merge to master or merge the two branches or how ever your workflow goes.
Usually, I use this structure:
which made sense to me. Make all changes you want and then merge to master. Simple and it works.
Using the first structure means that you are compartmentalizing your features, which is probably better for big teams, as things can change and to do code reviews. To get rid of a feature, you could easily get rid of the branch without modifying anything more. Whereas, if you used it the way I always did, then you'd have to go into the code and start removing shit and breaking things until it worked or lazily leave it alone and go onto another feature.
I won't change to the features branch structure yet as I don't exactly need to at this point, but in the future I will.