I often see discussions about how to do branching in GIT properly. Rebase or not to rebase. Merge or not to merge. Use strict git-flow or use git-flow but with some exceptions and changes. And so on.
I think in all these debates people forget about one most important thing - we, software engineers, should produce great software. Of course, you can blindly adopt git-flow or any other methodology and fanatically follow it’s rules. But I’m not sure that this will make your software great.
To develop great software you should understand - WHY you do certain things and HOW they affects you. So, if you are using git-flow you should understand WHY you are using exactly this methodology (because it is very popular - incorrect answer) and HOW it impacts your development process and your product.
For example. I worked in a big team. We had a lot of commits per deploy. The system was big, important and it generated money, so it was extremely important to deploy only CLEAN and VERIFIED code. Of course we have had automatic tests, manual tests, code reviews and leads all the time, in "daemon" mode, reviewed commits in master. Also if something very bad happened in PROD it was vital to find and fix problem quickly. So we must were able to clearly see which commits where added to particular deploy.
When we switched from SVN to GIT, we initially did not have any rules HOW to do branching. But very quickly someone did mistake during merge and committed BAD code to master branch and this code hit PROD very badly. Leads spent few hours trying to understand in GIT commits history when things went wrong. Eventually problem was found and fixed, but it was not easy.
After this incident we invented code reviews and one rule for branching and commits:
"NO MATTER THAT, BUT COMMITS HISTORY IN MASTER BRANCH MUST BE CLEAN AND LINEAR".
Starting from that point we understood HOW we should do branching to produce great software and WHY.
I really liked the idea with linear commits history in master branch and from then I tried to adapt it in all my next projects and jobs. But, unfortunately, not always this simple idea got positive response from other developers and managers. I think this happened because projects were relatively small - few developers and few dozens commits per deploy. Yes, sometimes it was tricky to understand from commits history when code was changed and who changed it first and merged with bug, but seems like this problem just was not big enough.
In conclusion to make my point more clear simple example: