diff options
Diffstat (limited to 'doc/user/project/merge_requests/getting_started.md')
| -rw-r--r-- | doc/user/project/merge_requests/getting_started.md | 70 |
1 files changed, 29 insertions, 41 deletions
diff --git a/doc/user/project/merge_requests/getting_started.md b/doc/user/project/merge_requests/getting_started.md index b1a57d9c3e6..f25228729cf 100644 --- a/doc/user/project/merge_requests/getting_started.md +++ b/doc/user/project/merge_requests/getting_started.md @@ -1,6 +1,6 @@ --- stage: Create -group: Source Code +group: Code Review info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments type: index, reference description: "Getting started with Merge Requests." @@ -60,7 +60,7 @@ request's page at the top-right side: - [Close issues automatically](#merge-requests-to-close-issues) when they are merged. - Enable the [delete source branch when merge request is accepted](#deleting-the-source-branch) option to keep your repository clean. - Enable the [squash commits when merge request is accepted](squash_and_merge.md) option to combine all the commits into one before merging, thus keep a clean commit history in your repository. -- Set the merge request as a [**Draft**](work_in_progress_merge_requests.md) to avoid accidental merges before it is ready. +- Set the merge request as a [**Draft**](drafts.md) to avoid accidental merges before it is ready. After you have created the merge request, you can also: @@ -84,7 +84,7 @@ See also other [features associated to merge requests](reviewing_and_managing_me Choose an assignee to designate someone as the person responsible for the first [review of the merge request](reviewing_and_managing_merge_requests.md). Open the drop down box to search for the user you wish to assign, -and the merge request will be added to their +and the merge request is added to their [assigned merge request list](../../search/index.md#issues-and-merge-requests). #### Multiple assignees **(PREMIUM)** @@ -110,7 +110,7 @@ dropdown menu. It is also possible to manage multiple assignees: - When creating a merge request. -- Using [quick actions](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics). +- Using [quick actions](../quick_actions.md#issues-merge-requests-and-epics). ### Reviewer @@ -122,17 +122,19 @@ Requesting a code review is an important part of contributing code. However, dec your code and asking for a review are no easy tasks. Using the "assignee" field for both authors and reviewers makes it hard for others to determine who's doing what on a merge request. -GitLab Merge Request Reviewers easily allow authors to request a review as well as see the status of the -review. By selecting one or more users from the **Reviewers** field in the merge request's right-hand -sidebar, the assigned reviewers will receive a notification of the request to review the merge request. +The Merge Request Reviewers feature enables you to request a review of your work, and +see the status of the review. Reviewers help distinguish the roles of the users +involved in the merge request. In comparison to an **Assignee**, who is directly +responsible for creating or merging a merge request, a **Reviewer** is a team member +who may only be involved in one aspect of the merge request, such as a peer review. -This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review from a peer. - -To request it, open the **Reviewers** drop-down box to search for the user you wish to get a review from. +To request a review of a merge request, expand the **Reviewers** select box in +the right-hand sidebar. Search for the users you want to request a review from. +When selected, GitLab creates a [to-do list item](../../todos.md) for each reviewer. #### Approval Rule information for Reviewers **(PREMIUM)** -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/233736) in GitLab 13.8. For this version only, GitLab administrators can opt to [enable it](#enable-or-disable-approval-rule-information). +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/233736) in GitLab 13.8. > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/293742) in GitLab 13.9. When editing the **Reviewers** field in a new or existing merge request, GitLab @@ -162,6 +164,13 @@ the author of the merge request can request a new review from the reviewer: GitLab creates a new [to-do item](../../todos.md) for the reviewer, and sends them a notification email. +#### Approval status + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292936) in GitLab 13.10. + +If a user in the reviewer list has approved the merge request, a green tick symbol is +shown to the right of their name. + ### Merge requests to close issues If the merge request is being created to resolve an issue, you can @@ -198,9 +207,9 @@ is set for deletion, the merge request widget displays the > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. > - It's [deployed behind a feature flag](../../feature_flags.md), disabled by default. -> - It's disabled on GitLab.com. -> - It's not recommended for production use. -> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-branch-retargeting-on-merge). +> - [Became enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/320895) on GitLab 13.10. +> - It's recommended for production use. +> - To use it in GitLab self-managed instances, ask a GitLab administrator to [disable it](#enable-or-disable-branch-retargeting-on-merge). **(FREE SELF)** In specific circumstances, GitLab can retarget the destination branch of open merge request, if the destination branch merges while the merge request is @@ -221,6 +230,12 @@ GitLab retargets up to four merge requests when their target branch is merged in `master`, so you don't need to perform this operation manually. Merge requests from forks are not retargeted. +The feature today works only one a merge. Clicking the `Remove source branch` button +after the merge request was merged will not automatically retarget merge request. +The feature today works only on merge. Clicking the **Remove source branch** button +after the merge request was merged will not automatically retarget a merge request. +This improvement is [tracked as a follow-up](https://gitlab.com/gitlab-org/gitlab/-/issues/321559). + ## Recommendations and best practices for Merge Requests - When working locally in your branch, add multiple commits and only push when @@ -231,33 +246,6 @@ forks are not retargeted. reviews are faster and your changes are less prone to errors. - Do not use capital letters nor special chars in branch names. -## Enable or disable Approval Rule information **(PREMIUM SELF)** - -> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/293742) in GitLab 13.9. - -Merge Request Reviewers is under development and ready for production use. -It is deployed behind a feature flag that is **enabled by default**. -[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) -can opt to disable it. - -To enable it: - -```ruby -# For the instance -Feature.enable(:reviewer_approval_rules) -# For a single project -Feature.enable(:reviewer_approval_rules, Project.find(<project id>)) -``` - -To disable it: - -```ruby -# For the instance -Feature.disable(:reviewer_approval_rules) -# For a single project -Feature.disable(:reviewer_approval_rules, Project.find(<project id>)) -``` - ### Enable or disable branch retargeting on merge **(FREE SELF)** Automatically retargeting merge requests is under development but ready for production use. |