Commit 4bf9b765 authored by Amy Qualls's avatar Amy Qualls

Merge branch 'selhorn-mr-edits' into 'master'

Edited for style and redid screenshot

See merge request gitlab-org/gitlab!57035
parents df50b565 e43bdad3
......@@ -7,12 +7,10 @@ type: index, reference
# Merge requests **(FREE)**
Whenever you need to merge one branch into another branch with GitLab, you
must create a merge request (MR).
Merge requests (MRs) are the way you check source code changes into a branch.
Using merge requests, you can visualize and collaborate on proposed changes to
source code. Merge requests display information about the proposed code changes,
including:
When you open a merge request, you can visualize and collaborate on the code changes before merge.
Merge requests include:
- A description of the request.
- Code changes and inline code reviews.
......@@ -20,55 +18,50 @@ including:
- A comment section for discussion threads.
- The list of commits.
Based on your workflow, after review you can merge a merge request into its
target branch.
To get started, read the [introduction to merge requests](getting_started.md).
## Use cases
## Merge request workflows
A. Consider you're a software developer working in a team:
For a software developer working in a team:
1. You checkout a new branch, and submit your changes through a merge request
1. You gather feedback from your team
1. You work on the implementation optimizing code with [Code Quality reports](code_quality.md)
1. You verify your changes with [Unit test reports](../../../ci/unit_test_reports.md) in GitLab CI/CD
1. You avoid using dependencies whose license is not compatible with your project with [License Compliance reports](../../compliance/license_compliance/index.md) **(ULTIMATE)**
1. You request the [approval](merge_request_approvals.md) from your manager **(STARTER)**
1. You checkout a new branch, and submit your changes through a merge request.
1. You gather feedback from your team.
1. You work on the implementation optimizing code with [Code Quality reports](code_quality.md).
1. You verify your changes with [Unit test reports](../../../ci/unit_test_reports.md) in GitLab CI/CD.
1. You avoid using dependencies whose license is not compatible with your project with [License Compliance reports](../../compliance/license_compliance/index.md).
1. You request the [approval](merge_request_approvals.md) from your manager.
1. Your manager:
1. Pushes a commit with their final review
1. [Approves the merge request](merge_request_approvals.md) **(STARTER)**
1. Sets it to [merge when pipeline succeeds](merge_when_pipeline_succeeds.md)
1. Your changes get deployed to production with [manual actions](../../../ci/yaml/README.md#whenmanual) for GitLab CI/CD
1. Your implementations were successfully shipped to your customer
B. Consider you're a web developer writing a webpage for your company's website:
1. You checkout a new branch, and submit a new page through a merge request
1. You gather feedback from your reviewers
1. Your changes are previewed with [Review Apps](../../../ci/review_apps/index.md)
1. You request your web designers for their implementation
1. You request the [approval](merge_request_approvals.md) from your manager **(STARTER)**
1. Once approved, your merge request is [squashed and merged](squash_and_merge.md), and [deployed to staging with GitLab Pages](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/)
1. Your production team [cherry picks](cherry_pick_changes.md) the merge commit into production
1. Pushes a commit with their final review.
1. [Approves the merge request](merge_request_approvals.md).
1. Sets it to [merge when pipeline succeeds](merge_when_pipeline_succeeds.md).
1. Your changes get deployed to production with [manual actions](../../../ci/yaml/README.md#whenmanual) for GitLab CI/CD.
1. Your implementations were successfully shipped to your customer.
For a web developer writing a webpage for your company's website:
1. You checkout a new branch and submit a new page through a merge request.
1. You gather feedback from your reviewers.
1. You preview your changes with [Review Apps](../../../ci/review_apps/index.md).
1. You request your web designers for their implementation.
1. You request the [approval](merge_request_approvals.md) from your manager.
1. Once approved, your merge request is [squashed and merged](squash_and_merge.md), and [deployed to staging with GitLab Pages](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/).
1. Your production team [cherry picks](cherry_pick_changes.md) the merge commit into production.
## Merge request navigation tabs at the top
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33813) in GitLab 12.6. This positioning is experimental.
So far, the navigation tabs present in merge requests to display **Discussion**,
**Commits**, **Pipelines**, and **Changes** were located after the merge request
In GitLab 12.5 and earlier, navigation tabs in merge requests (**Discussion**,
**Commits**, **Pipelines**, and **Changes**) were located after the merge request
widget.
To facilitate this navigation without having to scroll up and down through the page
to find these tabs, based on user feedback, we're experimenting with a new positioning
of these tabs. They are now located at the top of the merge request, with a new
**Overview** tab, containing the description of the merge request followed by the
widget. Next to **Overview**, you can find **Pipelines**, **Commits**, and **Changes**.
To facilitate navigation without scrolling, and based on user feedback, the tabs are
now located at the top of the merge request tab. A new **Overview** tab was added,
and next to **Overview** are **Commits**, **Pipelines**, and **Changes**.
![Merge request tab positions](img/merge_request_tab_position_v12_6.png)
![Merge request tab positions](img/merge_request_tab_position_v13_11.png)
Please note this change is currently behind a feature flag which is enabled by default. For
This change is behind a feature flag that is enabled by default. For
self-managed instances, it can be disabled through the Rails console by a GitLab
administrator with the following command:
......@@ -76,23 +69,9 @@ administrator with the following command:
Feature.disable(:mr_tabs_position)
```
## Creating merge requests
Learn [how to create a merge request](creating_merge_requests.md).
## Reviewing and managing merge requests
See the features at your disposal to [review and manage merge requests](reviewing_and_managing_merge_requests.md).
## Testing and reports in merge requests
Learn about the options for [testing and reports](testing_and_reports_in_merge_requests.md) on the changes in a merge request.
## Authorization for merge requests
There are two main ways to have a merge request flow with GitLab:
1. Working with [protected branches](../protected_branches.md) in a single repository
1. Working with forks of an authoritative project
## Related topics
[Learn more about the authorization for merge requests.](authorization_for_merge_requests.md)
- [Create a merge request](creating_merge_requests.md)
- [Review and manage merge requests](reviewing_and_managing_merge_requests.md)
- [Authorization for merge requests](authorization_for_merge_requests.md)
- [Testing and reports](testing_and_reports_in_merge_requests.md)
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment