the best git flow I used is mixing rebase and merge on protected branches (master + release branches).it is quite simple:
you update your branch using rebase pull is defaulted to rebase and to update your branch from another branch you rebase it.
to deliver your work you merge (--no-ff) your branch to the corresponding protected branch after you rebased it from the target branch.
I implemented this flow in my company and it is prefect for us.
it allow you to have a clean and readable history with trace of deliveries (start of branch and it's delivery) that standard rebasing flow doesn't allow.
after I rolled it out in the company I discovered that the only got server allowing to enforce this flow is gitlab. they called it semi linear history.
after that I discovered that I am not the only one to use it.
look at it for more details:
fangpenlin.com/posts/2013/09/30/ke...
btw in the link I provided they suggest to push -f to update your remote branch after rebasing. I think that --force-with-lease is safer (in 2013 the option wasn't available)
when you take update via rebase and merge to incorporate you changes is that you are always playing your changes onto others branches and never incorporate others changes into yours (default pull using merge or merge from master or release branches onto yours to update it)
merging to deliver using --no-ff ensure you can follow the delivered work on master (or any release branch) using log --first-parent and prevent parent inversion because of fast forwards...
the best git flow I used is mixing rebase and merge on protected branches (master + release branches).it is quite simple:
btw in the link I provided they suggest to push -f to update your remote branch after rebasing. I think that --force-with-lease is safer (in 2013 the option wasn't available)
2 another important points
This also sounds like what we do at my company