169 lines
5.1 KiB
Markdown
169 lines
5.1 KiB
Markdown
# Merge Requests
|
|
|
|
Merge requests allow you to exchange changes you made to source code and
|
|
collaborate with other people on the same project.
|
|
|
|
## Authorization for merge requests
|
|
|
|
There are two main ways to have a merge request flow with GitLab:
|
|
|
|
1. Working with [protected branches][] in a single repository
|
|
1. Working with forks of an authoritative project
|
|
|
|
[Learn more about the authorization for merge requests.](merge_requests/authorization_for_merge_requests.md)
|
|
|
|
## Cherry-pick changes
|
|
|
|
Cherry-pick any commit in the UI by simply clicking the **Cherry-pick** button
|
|
in a merged merge requests or a commit.
|
|
|
|
[Learn more about cherry-picking changes.](merge_requests/cherry_pick_changes.md)
|
|
|
|
## Merge when build succeeds
|
|
|
|
When reviewing a merge request that looks ready to merge but still has one or
|
|
more CI builds running, you can set it to be merged automatically when all
|
|
builds succeed. This way, you don't have to wait for the builds to finish and
|
|
remember to merge the request manually.
|
|
|
|
[Learn more about merging when build succeeds.](merge_requests/merge_when_build_succeeds.md)
|
|
|
|
## Resolve discussion comments in merge requests reviews
|
|
|
|
Keep track of the progress during a code review with resolving comments.
|
|
Resolving comments prevents you from forgetting to address feedback and lets
|
|
you hide discussions that are no longer relevant.
|
|
|
|
[Read more about resolving discussion comments in merge requests reviews.](merge_requests/merge_request_discussion_resolution.md)
|
|
|
|
## Resolve conflicts
|
|
|
|
When a merge request has conflicts, GitLab may provide the option to resolve
|
|
those conflicts in the GitLab UI.
|
|
|
|
[Learn more about resolving merge conflicts in the UI.](merge_requests/resolve_conflicts.md)
|
|
|
|
## Revert changes
|
|
|
|
GitLab implements Git's powerful feature to revert any commit with introducing
|
|
a **Revert** button in merge requests and commit details.
|
|
|
|
[Learn more about reverting changes in the UI](merge_requests/revert_changes.md)
|
|
|
|
## Merge requests versions
|
|
|
|
Every time you push to a branch that is tied to a merge request, a new version
|
|
of merge request diff is created. When you visit a merge request that contains
|
|
more than one pushes, you can select and compare the versions of those merge
|
|
request diffs.
|
|
|
|
[Read more about the merge requests versions.](merge_requests/versions.md)
|
|
|
|
## Work In Progress merge requests
|
|
|
|
To prevent merge requests from accidentally being accepted before they're
|
|
completely ready, GitLab blocks the "Accept" button for merge requests that
|
|
have been marked as a **Work In Progress**.
|
|
|
|
[Learn more about settings a merge request as "Work In Progress".](merge_requests/work_in_progress_merge_requests.md)
|
|
|
|
## Ignore whitespace changes in Merge Request diff view
|
|
|
|
If you click the **Hide whitespace changes** button, you can see the diff
|
|
without whitespace changes (if there are any). This is also working when on a
|
|
specific commit page.
|
|
|
|
|
|
|
|
>**Tip:**
|
|
You can append `?w=1` while on the diffs page of a merge request to ignore any
|
|
whitespace changes.
|
|
|
|
## Tips
|
|
|
|
Here are some tips that will help you be more efficient with merge requests in
|
|
the command line.
|
|
|
|
> **Note:**
|
|
This section might move in its own document in the future.
|
|
|
|
### Checkout merge requests locally
|
|
|
|
A merge request contains all the history from a repository, plus the additional
|
|
commits added to the branch associated with the merge request. Here's a few
|
|
tricks to checkout a merge request locally.
|
|
|
|
Please note that you can checkout a merge request locally even if the source
|
|
project is a fork (even a private fork) of the target project.
|
|
|
|
#### Checkout locally by adding a git alias
|
|
|
|
Add the following alias to your `~/.gitconfig`:
|
|
|
|
```
|
|
[alias]
|
|
mr = !sh -c 'git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2' -
|
|
```
|
|
|
|
Now you can check out a particular merge request from any repository and any
|
|
remote. For example, to check out the merge request with ID 5 as shown in GitLab
|
|
from the `upstream` remote, do:
|
|
|
|
```
|
|
git mr upstream 5
|
|
```
|
|
|
|
This will fetch the merge request into a local `mr-upstream-5` branch and check
|
|
it out.
|
|
|
|
#### Checkout locally by modifying `.git/config` for a given repository
|
|
|
|
Locate the section for your GitLab remote in the `.git/config` file. It looks
|
|
like this:
|
|
|
|
```
|
|
[remote "origin"]
|
|
url = https://gitlab.com/gitlab-org/gitlab-ce.git
|
|
fetch = +refs/heads/*:refs/remotes/origin/*
|
|
```
|
|
|
|
You can open the file with:
|
|
|
|
```
|
|
git config -e
|
|
```
|
|
|
|
Now add the following line to the above section:
|
|
|
|
```
|
|
fetch = +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
|
|
```
|
|
|
|
In the end, it should look like this:
|
|
|
|
```
|
|
[remote "origin"]
|
|
url = https://gitlab.com/gitlab-org/gitlab-ce.git
|
|
fetch = +refs/heads/*:refs/remotes/origin/*
|
|
fetch = +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
|
|
```
|
|
|
|
Now you can fetch all the merge requests:
|
|
|
|
```
|
|
git fetch origin
|
|
|
|
...
|
|
From https://gitlab.com/gitlab-org/gitlab-ce.git
|
|
* [new ref] refs/merge-requests/1/head -> origin/merge-requests/1
|
|
* [new ref] refs/merge-requests/2/head -> origin/merge-requests/2
|
|
...
|
|
```
|
|
|
|
And to check out a particular merge request:
|
|
|
|
```
|
|
git checkout origin/merge-requests/1
|
|
```
|
|
|
|
[protected branches]: protected_branches.md
|