It isn't just that there are more than two ways to do production git - it's that there are much better ways for you to use git in development before you send out a pull request.

As I develop, I do all my work on a "private" branch that no one else is expected to see. I make very frequent commits which only include the names of the files changed, using some automatic tool like git-infer or git-split.

Sometimes, if I am making a tricky change, I might commit every time I make a tiny delta and the unit tests still pass. Sometimes, if it's routine work, I will only commit a few times an hour.

Once I have the code exactly the way I like it, I then use my rebase skills to organize these dozens of tiny commits into a few very clear and carefully segmented commits. (Someone I worked with called these "manicured" once and I was very flattered.)

In responding to code reviews, I push a series of tiny fixup commits onto the end of the branch, and when the pull request is accepted, I rebase one last time to get a perfectly clean commit record.

And in no case do I ever, ever have any merge commits. They really serve no purpose at all, except to confuse your git tools and cloud your git history, because merge commits are the only commits with two parents.

The theoretical reason for merge commits is to deal with very long-running feature branches (which I think is a bad idea anyway), but even for that, it's much better to keep rebasing your feature branch against main so you are never too far from HEAD, rather than keep an increasingly aged feature branch with the miserable prospect of a punishing hours-long merge at the end of all your work.

Again, I want to re-emphasize that other people only see the final, cleaned up commits, but my fast-and-loose style in my private branches makes for extremely rapid development, and also, prevents terrible tragedies like "I had it all working and then I made a tiny change and now it's all broken and I can't make it work again".