There is no difference between PRs and MRs. The terminology "Pull request" is a reference to how git is used for example in kernel development. Say you are a developer, and I am the maintainer. For you to get changes incorporate, you would generate a diff patch and email it to me, so that I can review it, and request that I pull those changes from your repository if I think they are suitable. Hence "pull request", and the git command git pull-request.
A merge request is a reframing of this process. This is a result of the fact that we're not really asking for someone to pull from our repository, but rather asking that our changes be merged to the develop/master branch, often from a branch of the same repository. Hence, gitlab phrases the same process "merge request" rather than "pull request".
In both cases, the actual commands executed depends on the options selected. Both gitlab and github allow squashing, rebasing, and merging, and the commands are likely almost if not exactly identical.
I never used github by now, because our company is hosting a gitlab instance and in 4 out of 5 cases I use command line to do stuff. Maybe we switch to github in a few months, so I dived into this subject. As far as I understood the principle of github process is to fork a project and provide a pull request for the community project. I only wondered if there is any difference in the actual MERGE operation of the two branches.
Git is a distributed version control system, it doesn't care if you're working on a repo, a remote, a clone, or a fork (basically just a clone) when making merges. As long as you have common history, it will behave roughly the same. Also, the process you've described is as much a "gitlab process" as a "github process". If you're working on private repos, you probably won't be forking them. If public, likely yes.