Assignee gitlab что это

Getting started with merge requests (FREE)

A merge request (MR) is the basis of GitLab as a tool for code collaboration and version control.

When working in a Git-based platform, you can use branching strategies to collaborate on code.

A repository is composed by its default branch, which contains the major version of the codebase, from which you create minor branches, also called feature branches, to propose changes to the codebase without introducing them directly into the major version of the codebase.

Branching is especially important when collaborating with others, avoiding changes to be pushed directly to the default branch without prior reviews, tests, and approvals.

When you create a new feature branch, change the files, and push it to GitLab, you have the option to create a merge request, which is essentially a request to merge one branch into another.

The branch you added your changes into is called source branch while the branch you request to merge your changes into is called target branch.

The target branch can be the default or any other branch, depending on the branching strategies you choose.

In a merge request, beyond visualizing the differences between the original content and your proposed changes, you can execute a significant number of tasks before concluding your work and merging the merge request.

You can watch our GitLab Flow video for a quick overview of working with merge requests.

How to create a merge request

Learn the various ways to create a merge request.

What you can do with merge requests

When you start a new merge request, you can immediately include the following options. You can also add them later by either selecting Edit on the merge request’s page at the top-right side, or by using keyboard shortcuts for merge requests:

Set a milestone to track time-sensitive changes.
Add labels to help contextualize and filter your merge requests over time. from your team. when they are merged.
Enable the delete source branch when merge request is accepted option to keep your repository clean.
Enable the squash commits when merge request is accepted 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 to avoid accidental merges before it is ready.

After you have created the merge request, you can also:

Add merge request dependencies to restrict it to be merged only when other merge requests have been merged.
Preview continuous integration pipelines on the merge request widget.
Preview how your changes look directly on your deployed application with Review Apps. .
Perform a Review to create multiple comments on a diff and publish them when you’re ready.
Add code suggestions to change the content of merge requests directly into merge request threads, and easily apply them to the codebase directly from the UI.
Add a time estimation and the time spent with that merge request with Time Tracking.

Many of these options can be set:

From the merge request page, with keyboard shortcuts.
When pushing changes from the command line, with Git push options.

WARNING: Requesting a code review is an important part of contributing code. However, deciding who should review 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.

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.

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 for each reviewer.

Merge requests to close issues

To create a merge request to close an issue when it’s merged, you can either:

In the issue, select Create a merge request. Then, you can either:

Create a new branch and a draft merge request in one action. The branch is named issuenumber-title by default, but you can choose any name, and GitLab verifies that it’s not already in use. The merge request inherits the milestone and labels of the issue, and is set to automatically close the issue when it is merged.
Create a new branch only, with its name starting with the issue number.

If the issue is confidential, you may want to use a different workflow for merge requests for confidential issues to prevent confidential information from being exposed.

Deleting the source branch

When creating a merge request, select the Delete source branch when merge request accepted option, and the source branch is deleted when the merge request is merged. To make this option enabled by default for all new merge requests, enable it in the project’s settings.

This option is also visible in an existing merge request next to the merge request button and can be selected or cleared before merging. It is only visible to users with the Maintainer role in the source project.

If the user viewing the merge request does not have the correct permissions to delete the source branch and the source branch is set for deletion, the merge request widget displays the Deletes source branch text.

Assignee, approver, reviewer, oh my!

Picture of Horst Gutmann

Horst Gutmann, software engineer from Graz , Austria .

I’m working daily with GitLab and absolutely love it. When it comes to all the different roles that a person can have around issues and merge requests, though, I sometimes get confused and so I thought I’d finally write them down so that even I can remember:

Assignee

Each merge request and issue can have one or multiple users assigned to it. That assignment can change during the life-time of that item but in both contexts these are the people to contact if there are questions about that MR or issue.

Merge request author

In the context of merge requests there is also always an author. That’s the user that initially created the merge request. As far as I can tell, this attribute of an MR cannot be changed while assignees can.

Approver/Reviewers

A reviewer is someone who you want to review your merge request. Actually, you want that they approve your merge request which makes them an “approver”. That’s confusing… let’s work with a little example:

Let’s say you’re the maintainer of ProjectX. This means that whenever a new merge request is opened, you should be automatically assigned as reviewer so that nobody can merge it without you giving it an approval first!

To do that, you create an “approval rule” within your project that set the number of approvals required to “1” and add yourself to the list of “approvers”.

OK, but that only decides who’s approval is required for an MR. If you want to explicitly request a review from someone, you can now add them to a merge request as a “reviewer”. Once you are added to an MR as a reviewer, you can also find that request in the quick menu in GitLab’s top bar:

Screenshot of the GitLab top bar with expanded merge-request menu

Once you are a review of an MR, you can easily navigate to it using the top bar menu

Code owner

Related to approvers are code owners. These are defined inside the CODEOWNERS file within the repository and indicate which people are responsible for which part of the repository. GitLab can add these people to the required approvers if code that’s under their responsibility would be changed by a MR. This feature can be configured for protected branches.

I think that’s basically it for now. Personally, I think the whole approver vs. reviewer naming is a bit unfortunate but otherwise everything is pretty clear once you’ve understood what each role is there for ��

Do you want to give me feedback about this article in private? Please send it to comments@zerokspot.com.

Alternatively, this website also supports Webmentions. If you write a post on a blog that supports this technique, I should get notified about your link ��

Comments

If you have a Mastodon account, you can also leave a comment by replying to this status.

You can also find this post linked to from the following pages:

(cc) 2003-2022 Horst Gutmann | /feeds

If not otherwise stated this work is licensed under a Creative Commons Attribution-Share Alike 3.0 Austria License.
The source code of this site is available on GitHub. The primary font used here is Liberation Mono by Red Hat.

GitLab Issues Functionalities

Please read through the GitLab Issue Documentation for an overview on GitLab Issues.

Issues Functionalities

The image bellow illustrates how an issue looks like:

Issue view

You can find all the information on that issue on one screen.

Issue screen

An issue starts with its status (open or closed), followed by its author, and includes many other functionalities, numbered on the image above to explain what they mean, one by one.

Many of the elements of the issue screen refresh automatically, such as the title and description, when they are changed by another user. Comments and system notes also appear automatically in response to various actions and content updates.

1. New Issue, close issue, edit

New issue: create a new issue in the same project
Close issue: close this issue
Edit: edit the same fields available when you create an issue.

2. Todos

Add todo: add that issue to your GitLab Todo list
Mark done: mark that issue as done (reflects on the Todo list)

3. Assignee

Whenever someone starts to work on an issue, it can be assigned to that person. The assignee can be changed as much as needed. The idea is that the assignee is responsible for that issue until it’s reassigned to someone else to take it from there.

Tip: if a user is not member of that project, it can only be assigned to them if they created the issue themselves.

3.1. Multiple Assignees (EES/EEP)

Issue Weights are only available in GitLab Enterprise Edition.

Often multiple people likely work on the same issue together, which can especially be difficult to track in large teams where there is shared ownership of an issue.

In GitLab Enterprise Edition, you can also select multiple assignees to an issue.

4. Milestone

Select a milestone to attribute that issue to.

5. Time Tracking (EES/EEP)

This feature is available only in GitLab Enterprise Edition.

Estimate time: add an estimate time in which the issue will be implemented
Spend: add the time spent on the implementation of that issue

6. Due date

When you work on a tight schedule, and it’s important to have a way to setup a deadline for implementations and for solving problems. This can be facilitated by the due date). Due dates can be changed as many times as needed.

7. Labels

Categorize issues by giving them labels. They help to organize team’s workflows, once they enable you to work with the GitLab Issue Board.

Group Labels, which allow you to use the same labels per group of projects, can be also given to issues. They work exactly the same, but they are immediately available to all projects in the group.

Tip: if the label doesn’t exist yet, when you click Edit, it opens a dropdown menu from which you can select Create new label.

8. Weight (EES/EEP)

Issue Weights are only available in GitLab Enterprise Edition.

Attribute a weight (in a 0 to 9 range) to that issue. Easy to complete should weight 1 and very hard to complete should weight 9.

9. Participants

People involved in that issue (mentioned in the description or in the discussion).

10. Notifications

Subscribe: if you are not a participant of the discussion on that issue, but want to receive notifications on each new input, subscribe to it.
Unsubscribe: if you are receiving notifications on that issue but no longer want to receive them, unsubscribe to it.

11. Reference

A quick «copy to clipboard» button to that issue’s reference, foo/bar#xxx , where foo is the username or groupname , bar is the project-name , and xxx is the issue number.

12. Title and description

Title: a plain text title describing the issue’s subject.
Description: a text field which fully supports GitLab Flavored Markdown.

13. @mentions

Mentions: you can either @mention a user or a group present in your GitLab instance and they will be notified via todos and email, unless that person has disabled all notifications in their profile settings.

To change your notification settings navigate to Profile Settings > Notifications > Global notification level and choose your preferences from the dropdown menu.

Tip: Avoid mentioning @all in issues and merge requests, as it sends an email notification to all the members of that project’s group, which can be interpreted as spam.

14. Related Merge Requests

Any merge requests mentioned in that issue’s description or in the issue thread.

15. Award emoji

Award an emoji to that issue.

Tip: Posting «+1» as comments in threads spam all participants of that issue. Awarding an emoji is a way to let them know you like it without spamming them.

Assignee gitlab что это