Like most people have said here it depends on your project. However, I feel it would make more sense to share my approach.

So here's my workflow- there is a master branch, a development branch and other branches are 'featureX' or 'bugFixY'. master branch is always what is in production, tested and complete. 'development' is the branch closest to master but has changes that should be merged to master and deployed next. Anyone who starts working on a new feature should always branch out from development. Try not to fix things directly in development, a branch for every bug (unless its just way too small a fix).

Next, if a branchfeatureX gets ready and well-tested, I would merged it to branch development. So in a sense, development is also always production ready but has newer changes. Meanwhile before a deployment, if we have another branch bugFixY which is ready and tested, I would merge it in development. And once its time to deploy, I will simply merge development to master. It facilitates multiple fixes and features in one deployment while keeping it all unit sized and human-error proof.

I think this question is strongly related with this link.

In my actual job i merge with the master or in my case dev or prod branch when a bugfix or new feature is added. If i need to make some bugfixes or adding new features then the project manager decides when to merge to the final branch.

But i think a nice point of view is that only make the merge when the code of the commits don't broke the code of the app, and only making commits wiith full changes.

It depends on which branch are you working at and also about your product itself.

If you are working on a really crucial feature or you are solving a bug or a security problem you will probably create a branch make a pull request and then merge it.

However if you are working on a improvement I would wait to have the minimum viable product and then merge it.

How often depends on your actual project and its releases. A good recommendation may be to merge it when an improvement or a significative feature has been implemented or a bug has been fixed. A good recommendation that I always follow is to merge with the --no-ff flag in order to keep my history clean and readable