Without merge commits you can never have more than 1 long-lived branch because said long-lived branches will not have any common ancestors which makes pulling changes between them a nightmare (literally every file will be in conflict)...

I like linear histories too, but if you have a production branch and a development branch you need merge commits between them.

long lived branches are an anti pattern so this sounds like a plus to me

I’d rather wait until a project is finished, than to push incomplete changes that (I hope) aren’t reachable.

But a long-lived branch needs to be rebased before review, because conflict resolutions need to be reviewed. In fact reviewing the version without the conflict resolutions is a waste of time, because that version probably won’t ever be deployed.

I don't think either of those is necessarily true. I don't ever need to merge long lived branches if I don't want to. And I definitely don't ever merge my production branches with... anything. They are always just a fast-forward from another branch.

In my case I have 2 branches - production and development which map to different cloud environments. Pushing to development branch will run CI/CD to auto-deploy to development cloud, and pushing to production will run CI/CD to auto-deploy to production cloud. This particular software is also classified as a medical device under FDA which means there are regulations about what can be deployed to production and when. Hence, I cannot just fast forward production from another branch without first getting FDA approval. I can, however, cherry pick certain kinds of bug fixes into production without FDA approval, and then later (after FDA approval) merge the other approved changes into production as well. In this case fast forwarding isn't possible because of the cherry picks so we are using just normal merge commits.

Do you have a better git workflow in mind than what is described above?