DISCLAIMER: Expressed views on this blog are my own.
I had no idea until my internship that you could deviate from the master branch with multiple branches with different changes then modify the master branch and then merge master's changes into the branches and eventually merge youre features on to master. Well, I knew you could create multiple branches, I just never figured that I'd want to modify the master branch once I'd made a branch from it. I now appreciate how git makes life easier especially with its demarcations of conflicts between branches you are attempting to merge.
Basically the structure can be like this:
Master
Feature_1
Feature_2
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:
Master
Dev
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.
