[web] pull request -> merge request.

web/content/docs/devguide/development-workflows/branching-model.pandoc

@@ -34,4 +34,4 @@ First thing to do when you start working on your local repository is to create a
 
 Start committing changes in logical chunks. After you are happy with your implementation push your topic branch to your forked repository on GitLab.
 
-Open a *Pull Request* which will initiate the code review process.
+Open a [*Merge Request*](https://docs.gitlab.com/ee/user/project/merge_requests/) which will initiate the code review process.

web/content/docs/devguide/getting-started/get-the-source-code.pandoc

@@ -95,7 +95,7 @@ Now after you implemented the feature and committed your work you can push the n
 $ git push
 ```
 
-If your work is done submit a pull request.
+If your work is done submit a [merge request](https://gitlab.opengeosys.org/ogs/ogs/-/merge_requests/new).
 
 This workflow is summarized with this picture:
 

web/content/docs/devguide/testing/gitlab-ci.pandoc

@@ -13,7 +13,7 @@ weight = 1022
 
 [GitLab CI](https://docs.gitlab.com/ee/ci/) is a powerful [Continuous Integration](../../development-workflows/continuous-integration) system integrated into GitLab.
 
-The tasks of the CI system are configured in [scripts inside the OGS source code](https://gitlab.opengeosys.org/ogs/ogs/-/tree/gitlab-ci/scripts/ci). The entrypoint is defined in [.gitlab-ci.yml](https://gitlab.opengeosys.org/ogs/ogs/-/blob/gitlab-ci/.gitlab-ci.yml). Scripting and versioning the configuration together with the source code is very powerful, e.g. if you introduce a new OGS CMake configuration in a pull request even the change of the CI jobs configuration or jobs environment (Docker container definition) can be part of the pull request.
+The tasks of the CI system are configured in [scripts inside the OGS source code](https://gitlab.opengeosys.org/ogs/ogs/-/tree/gitlab-ci/scripts/ci). The entrypoint is defined in [.gitlab-ci.yml](https://gitlab.opengeosys.org/ogs/ogs/-/blob/gitlab-ci/.gitlab-ci.yml). Scripting and versioning the configuration together with the source code is very powerful, e.g. if you introduce a new OGS CMake configuration in a merge request even the change of the CI jobs configuration or jobs environment (Docker container definition) can be part of the merge request.
 
 ## GitLab Pipeline
 
@@ -27,7 +27,7 @@ Jobs are belong to a stage and each job will get a status (success, warnings, fa
 
 ## Automatic testing
 
-The master-branch of the the main repository as well as all pull requests on that repo are automatically tested. See [the pipelines page](https://gitlab.opengeosys.org/ogs/ogs/pipelines).
+The master-branch of the the main repository as well as all merge requests on that repo are automatically tested. See [the pipelines page](https://gitlab.opengeosys.org/ogs/ogs/pipelines).
 
 ### Skip automatic testing