Как удалить merge request gitlab
Перейти к содержимому

Как удалить merge request gitlab

  • автор:

Как отменить merge, не потеряв код?

Разработку вел в master. Потом сделал валидацию в ветке validation и gui в ветке gui. Нужно было выложить на гитхаб разными ветками это. А я смерджил в master и validation и gui и только после этого отправил на гитхаб. Можно как то исправить? Мне важно что бы именно на гитхабе они отображались как разные ветки. Поэтому если есть способ на самом сайте их разделить визуально, при этом на компьютере оставив слитыми, то такой способ мне тоже подойдет. Код в этих ветках меня устраивает, и при слиянии не было никаких конфликтов. Хочу разделить, только потому что люди, которые будут изучать проект на гитхабе должны четко понимать, где закончилась ветка master. Т.е. только небольшая часть проекта должна быть в мастер. А у меня получилось, что весь проект в master.

Отслеживать
задан 8 мая 2016 в 5:58
Александр Елизаров Александр Елизаров
2,788 2 2 золотых знака 18 18 серебряных знаков 36 36 бронзовых знаков

3 ответа 3

Сортировка: Сброс на вариант по умолчанию

Во-первых, потерять код в git не так-то легко. Если что, у вас всегда есть git reflog , чтобы восстановить потерянный коммит. А ещё всегда можно сделать бэкап текущей ветки с помощью git branch backup (имя произвольное).

Дальше, нужно откатить ветку master до коммита перед слиянием: git reset —hard commit-name . Подробнее: Как вернуться (откатиться) к более раннему коммиту?

Просто так запушить ветку не получится, т.к. на гитхабе теперь есть коммиты, которых в вашей ветке нет, поэтому не получится автоматический fast-forward merge. Поможет git push -f . Эта команда заменяет содержимое удаленной ветки.

Осталось запушить остальные ветки. Чтобы каждый раз не указывать локальную и удаленную ветку, можете однажды назначить локальной ветке удаленную upstream-ветку:

git push -u origin master git push -u origin validation git push -u origin gui 

Можно запушить все ветки сразу (вообще все в refs/heads/ ):

git push -u --all origin Branch master set up to track remote branch master from origin. Branch validation set up to track remote branch validation from origin. Branch gui set up to track remote branch gui from origin. 

How to close a merge request in GitLab

You need at least reporter role in the GitLab project to be able to see the list of merge requests (MRs) and at least developer role to be able to open a MR and at least owner role to delete a MR.

This article is only applicable if there is an open Merge Request (MR) . See our previous articles about opening a MR and discussing a MR.

Step-by-step guide

  1. Make sure all threads are resolved in the discussion regarding your Merge Request (MR) .
    See our article on discussing MRs. The ‘Overview’ page ( 1 ) there should be no unresolved threads ( 2 ): MR unresolved thread
  2. You can review all the changes to merge.
    Therefore go the the ‘Changes’ page of the MR.
  3. Once you are satisfied, click Mark as ready ( 3 ) or edit the MR ( 3 ) and remove Draft: or WIP: from the title.
  4. Close the MR by merging it.
    All threads have been resolved ( 1 ) and the MR has been marked as ready ( 2 ). Now Merge ( 3 ) is available. When in the workflow you don’t need the branch anymore, leave the Delete source branch checkbox activated. This will be the case for feature-branches.
    This step integrates the changes in the MR into the target branch (most likely ‘master’). MR ready to merge

See also

  • How to open a merge request in GitLab
  • How to discuss a merge request in GitLab
  • Version control with git
  • Git / GitLab
  • How to set up or join a git repository

last modified by Moritz Schwarzmeier 25/11/2021

How to remove merge request from GitLab server

I created a merge request on gitlab (local) server. Now whenever I click on the merge request, the request times out with error 500. Before that I used to get an error code 504 and I applied the change mentioned in this gitlab support topic. All I want to do is remove the merge request. Is there a manual way of doing this?

7,179 7 7 gold badges 37 37 silver badges 55 55 bronze badges
asked Aug 25, 2015 at 2:33
3,830 6 6 gold badges 27 27 silver badges 31 31 bronze badges

4 Answers 4

Web UI Option

Today I discovered a way to do this with the Web UI.

So for Merge Request 14

On the bottom Right you should see a red Delete button.

Gitlab Delete Merge Request Screen Shot

PowerShell Option

Invoke-RestMethod -Method Delete -Uri ‘https://gitlab.example.com/api/v4/projects/PROJECT_ID_GOES_HERE/merge_requests/14’ -Headers @

1 1 1 silver badge
answered Apr 11, 2018 at 15:46
Eric D. Johnson Eric D. Johnson
10.9k 10 10 gold badges 40 40 silver badges 48 48 bronze badges

FYI: The Delete button is only available if you have permission Owner. Unfortunately not documented yet: GitLab permissions — docs.gitlab.com/ee/user/permissions.html but indirect permission hint here: Delete a merge request — docs.gitlab.com/ee/api/…

May 17, 2018 at 9:00

Good clarity @DoctorRudolf .Yeah, if you’re only at Master or Developer permissions levels you can’t delete via the web UI.

May 23, 2018 at 12:28

Maintainer level also doesn’t seem to have this option. Then again I’m not the admin of the GitLab instance so it might have been deactivated by the owner/admin.

Apr 20, 2022 at 5:39

Yes, there is. I could not find a way to remove the merge request in the user interface, but you can simply delete it from the database.

(Please note, that I only tested this on gitlab CE 8.4.0-ce.0 on Ubuntu 14.04.3 LTS.. Other versions may have a different database structure)

At a command prompt, execute the following command (as root):

sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -h /var/opt/gitlab/postgresql -d gitlabhq_production 

This will bring up a PostgreSQL command terminal. Next, you’ll have to find the merge request you’d like to delete. Type the following at the PostgreSQL command terminal:

select id, title from merge_requests; 

You’ll get a list of merge request ids and titles. Find the one you’d like to delete and note the id

OK, let’s say you’ve found the merge request you’d like to delete and the id is 5 . You’re simply going to delete all the data associated with that merge request using the following SQL commands. (Substitute 5 in the commands below with your actual merge request id )

delete from merge_requests where from merge_request_diffs where merge_request_id = 5; delete from notes where noteable_type = 'MergeRequest' and noteable_id = 5; 

You can now exit out of the PostgreSQL command terminal by typing:

Your merge request should now be gone from the web interface.

Merge requests (FREE)

To incorporate changes from a source branch to a target branch, you use a merge request (MR).

When you open a merge request, you can visualize and collaborate on the changes before merge. Merge requests include:

  • A description of the request.
  • Code changes and inline code reviews.
  • Information about CI/CD pipelines.
  • A comment section for discussion threads.
  • The list of commits.

For a quick overview of merge requests, view this GitLab Flow video.

Create a merge request

Learn the various ways to create a merge request.

View merge requests

You can view merge requests for your project, group, or yourself.

For a project

To view all merge requests for a project:

  1. On the top bar, select Main menu > Projects and find your project.
  2. On the left sidebar, select Merge requests.

Or, to use a keyboard shortcut, press g + m .

For all projects in a group

To view merge requests for all projects in a group:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Merge requests.

If your group contains subgroups, this view also displays merge requests from the subgroup projects.

Assigned to you

To view all merge requests assigned to you:

  1. On the top bar, put your cursor in the Search box.
  2. From the dropdown list, select Merge requests assigned to me.
  • To use a keyboard shortcut, press Shift + m .
  1. On the top bar, in the upper-right corner, select Merge requests ( ).
  2. From the dropdown list, select Assigned to you.

Filter the list of merge requests

  • Filtering by approved-by introduced in GitLab 13.0.
  • Filtering by reviewer introduced in GitLab 13.7.
  • Filtering by potential approvers was moved to GitLab Premium in 13.9.
  • Filtering by approved-by moved to GitLab Premium in 13.9.

To filter the list of merge requests:

  1. Above the list of merge requests, select Search or filter results. .
  2. From the dropdown list, select the attribute you wish to filter by. Some examples:
    • By environment or deployment date.
    • ID: Enter filter #30 to return only merge request 30.
    • User filters: Type (or select from the dropdown list) any of these filters to display a list of users:
      • Approved-By, for merge requests already approved by a user. (PREMIUM).
      • Approver, for merge requests that this user is eligible to approve. (For more information, read about Code owners). (PREMIUM)
      • Reviewer, for merge requests reviewed by this user.
  3. Select or type the operator to use for filtering the attribute. The following operators are available:
    • = : Is
    • != : Is not
  4. Enter the text to filter the attribute by. You can filter some attributes by None or Any.
  5. Repeat this process to filter by multiple attributes. Multiple attributes are joined by a logical AND .
  6. Select a Sort direction, either for descending order, or for ascending order.

GitLab displays the results on-screen, but you can also retrieve them as an RSS feed.

By environment or deployment date

To filter merge requests by deployment data, such as the environment or a date, you can type (or select from the dropdown list) the following:

  • Environment
  • Deployed-before
  • Deployed-after

NOTE: Projects using a fast-forward merge method do not return results, as this method does not create a merge commit.

When filtering by an environment, a dropdown list presents all environments that you can choose from:

Filter MRs by their environment

When filtering by Deployed-before or Deployed-after , the date refers to when the deployment to an environment (triggered by the merge commit) completed successfully. You must enter the deploy date manually. Deploy dates use the format YYYY-MM-DD , and must be quoted if you wish to specify both a date and time ( «YYYY-MM-DD HH:MM» ):

Filter MRs by a deploy date

Add changes to a merge request

If you have permission to add changes to a merge request, you can add your changes to an existing merge request in several ways, depending on the complexity of your change and whether you need access to a development environment:

  • Edit changes in the Web IDE in your browser with the . keyboard shortcut. Use this browser-based method to edit multiple files, or if you are not comfortable with Git commands. You cannot run tests from the Web IDE.
  • Edit changes in Gitpod, if you need a fully-featured environment to both edit files, and run tests afterward. Gitpod supports running the GitLab Development Kit (GDK). To use Gitpod, you must enable Gitpod in your user account.
  • Push changes from the command line, if you are familiar with Git and the command line.

Assign a user to a merge request

To assign the merge request to a user, use the /assign @user quick action in a text area in a merge request, or:

  1. On the top bar, select Main menu > Projects and find your project.
  2. On the left sidebar, select Merge requests and find your merge request.
  3. On the right sidebar, expand the right sidebar and locate the Assignees section.
  4. Select Edit.
  5. Search for the user you want to assign, and select the user.

The merge request is added to the user’s assigned merge request list.

Assign multiple users (PREMIUM)

Moved to GitLab Premium in 13.9.

GitLab enables multiple assignees for merge requests, if multiple people are accountable for it:

multiple assignees for merge requests sidebar

To assign multiple assignees to a merge request, use the /assign @user quick action in a text area, or:

  1. On the top bar, select Main menu > Projects and find your project.
  2. On the left sidebar, select Merge requests and find your merge request.
  3. On the right sidebar, expand the right sidebar and locate the Assignees section.
  4. Select Edit and, from the dropdown list, select all users you want to assign the merge request to.

To remove an assignee, clear the user from the same dropdown list.

Close a merge request

If you decide to permanently stop work on a merge request, GitLab recommends you close the merge request rather than delete it. The author and assignees of a merge request, and users with Developer, Maintainer, or Owner roles in a project can close merge requests in the project:

  1. Go to the merge request you want to close.
  2. Scroll to the comment box at the bottom of the page.
  3. Following the comment box, select Close merge request.

GitLab closes the merge request, but preserves records of the merge request, its comments, and any associated pipelines.

Delete a merge request

GitLab recommends you close, rather than delete, merge requests.

WARNING: You cannot undo the deletion of a merge request.

To delete a merge request:

  1. Sign in to GitLab as a user with the project Owner role. Only users with this role can delete merge requests in a project.
  2. Go to the merge request you want to delete, and select Edit.
  3. Scroll to the bottom of the page, and select Delete merge request.

Delete the source branch on merge

You can delete the source branch for a merge request:

  • When you create a merge request, by selecting Delete source branch when merge request accepted.
  • When you merge a merge request, if you have the Maintainer role, by selecting Delete source branch.

An administrator can make this option the default in the project’s settings.

Update merge requests when target branch merges (FREE SELF)

  • Introduced in GitLab 13.9.
  • Disabled on self-managed in GitLab 13.9.
  • Enabled on self-managed GitLab 13.10.

Merge requests are often chained together, with one merge request depending on the code added or changed in another merge request. To support keeping individual merge requests small, GitLab can update up to four open merge requests when their target branch merges into main . For example:

  • Merge request 1: merge feature-alpha into main .
  • Merge request 2: merge feature-beta into feature-alpha .

If these merge requests are open at the same time, and merge request 1 ( feature-alpha ) merges into main , GitLab updates the destination of merge request 2 from feature-alpha to main .

Merge requests with interconnected content updates are usually handled in one of these ways:

  • Merge request 1 is merged into main first. Merge request 2 is then retargeted to main .
  • Merge request 2 is merged into feature-alpha . The updated merge request 1, which now contains the contents of feature-alpha and feature-beta , is merged into main .

This feature works only when a merge request is merged. Selecting Remove source branch after merging does not retarget open merge requests. This improvement is proposed as a follow-up.

Move sidebar actions

Introduced in GitLab 14.10 with a flag named moved_mr_sidebar . Disabled by default.

FLAG: On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to enable the feature flag named moved_mr_sidebar . On GitLab.com, this feature is enabled in the following projects: gitlab-org/gitlab , gitlab-com/www-gitlab-com , and gitlab-org/customers-gitlab-com .

When this feature flag is enabled, in the upper-right corner, Merge request actions ( ) contains the following actions:

  • The notifications toggle
  • Mark merge request as ready or draft
  • Close merge request
  • Lock discussion
  • Copy reference

When this feature flag is disabled, these actions are in the right sidebar.

Merge request workflows

For a software developer working in a team:

  1. You check out a new branch, and submit your changes through a merge request.
  2. You gather feedback from your team.
  3. You work on the implementation optimizing code with Code Quality reports.
  4. You verify your changes with Unit test reports in GitLab CI/CD.
  5. You avoid using dependencies whose license is not compatible with your project with License Compliance reports.
  6. You request the approval from your manager.
  7. Your manager:
    1. Pushes a commit with their final review.
    2. Approves the merge request.
    3. Sets it to merge when pipeline succeeds.

    For a web developer writing a webpage for your company’s website:

    1. You check out a new branch and submit a new page through a merge request.
    2. You gather feedback from your reviewers.
    3. You preview your changes with Review Apps.
    4. You request your web designers for their implementation.
    5. You request the approval from your manager.
    6. Once approved, your merge request is squashed and merged, and deployed to staging with GitLab Pages.
    7. Your production team cherry-picks the merge commit into production.

    Related topics

    • Create a merge request
    • Review a merge request
    • Authorization for merge requests
    • Testing and reports
    • GitLab keyboard shortcuts
    • Comments and threads
    • Suggest code changes
    • CI/CD pipelines
    • Push options for merge requests

    Troubleshooting

    Rebase a merge request from the Rails console (FREE SELF)

    In addition to the /rebase quick action, users with access to the Rails console can rebase a merge request from the Rails console. Replace , , and with appropriate values:

    WARNING: Any command that changes data directly could be damaging if not run correctly, or under the right conditions. We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.

    u = User.find_by_username('') p = Project.find_by_full_path('') m = p.merge_requests.find_by(iid: iid>) MergeRequests::RebaseService.new(project: m.target_project, current_user: u).execute(m)

    Fix incorrect merge request status (FREE SELF)

    If a merge request remains Open after its changes are merged, users with access to the Rails console can correct the merge request’s status. Replace , , and with appropriate values:

    WARNING: Any command that changes data directly could be damaging if not run correctly, or under the right conditions. We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.

    u = User.find_by_username('') p = Project.find_by_full_path('') m = p.merge_requests.find_by(iid: iid>) MergeRequests::PostMergeService.new(project: p, current_user: u).execute(m)

    Running this command against a merge request with unmerged changes causes the merge request to display an incorrect message: merged into .

    Close a merge request from the Rails console (FREE SELF)

    If closing a merge request doesn’t work through the UI or API, you may want to attempt to close it in a Rails console session:

    WARNING: Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.

    u = User.find_by_username('') p = Project.find_by_full_path('') m = p.merge_requests.find_by(iid: iid>) MergeRequests::CloseService.new(project: p, current_user: u).execute(m)

    Delete a merge request from the Rails console (FREE SELF)

    If deleting a merge request doesn’t work through the UI or API, you may want to attempt to delete it in a Rails console session:

    WARNING: Any command that changes data directly could be damaging if not run correctly, or under the right conditions. We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.

    u = User.find_by_username('') p = Project.find_by_full_path('') m = p.merge_requests.find_by(iid: iid>) Issuable::DestroyService.new(container: m.project, current_user: u).execute(m)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *