debian-mirror-gitlab/doc/user/project/merge_requests/versions.md

84 lines
3.5 KiB
Markdown
Raw Normal View History

2019-09-04 21:01:54 +05:30
---
2021-01-29 00:20:46 +05:30
stage: none
group: unassigned
2021-02-22 17:27:13 +05:30
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
2019-09-04 21:01:54 +05:30
type: reference, concepts
---
2016-09-29 09:46:39 +05:30
2019-09-04 21:01:54 +05:30
# Merge requests versions
2016-09-29 09:46:39 +05:30
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.
2016-11-03 12:29:30 +05:30
![Merge request versions](img/versions.png)
2019-09-04 21:01:54 +05:30
## Selecting a version
2016-09-29 09:46:39 +05:30
By default, the latest version of changes is shown. However, you
can select an older one from version dropdown.
2016-11-03 12:29:30 +05:30
![Merge request versions dropdown](img/versions_dropdown.png)
2019-09-04 21:01:54 +05:30
Merge request versions are based on push not on commit. So, if you pushed 5
2021-02-22 17:27:13 +05:30
commits in a single push, it displays as a single option in the dropdown. If you
pushed 5 times, that counts for 5 options.
2016-09-29 09:46:39 +05:30
2016-11-03 12:29:30 +05:30
You can also compare the merge request version with an older one to see what has
2016-09-29 09:46:39 +05:30
changed since then.
2016-11-03 12:29:30 +05:30
![Merge request versions compare](img/versions_compare.png)
2019-09-04 21:01:54 +05:30
Comments are disabled while viewing outdated merge versions or comparing to
versions other than base.
2016-11-03 12:29:30 +05:30
Every time you push new changes to the branch, a link to compare the last
changes appears as a system note.
2016-09-29 09:46:39 +05:30
2016-11-03 12:29:30 +05:30
![Merge request versions system note](img/versions_system_note.png)
2016-09-29 09:46:39 +05:30
2019-12-26 22:10:19 +05:30
## Find the merge request that introduced a change
2020-06-23 00:09:42 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/2383) in GitLab 10.5.
2019-12-26 22:10:19 +05:30
2021-02-22 17:27:13 +05:30
When viewing the commit details page, GitLab links to the merge request (or
2019-12-26 22:10:19 +05:30
merge requests, if it's in more than one) containing that commit.
This only applies to commits that are in the most recent version of a merge
2021-02-22 17:27:13 +05:30
request - if commits were in a merge request, then rebased out of that merge
request, they aren't linked.
2019-12-26 22:10:19 +05:30
2020-04-22 19:07:51 +05:30
## `HEAD` comparison mode for Merge Requests
2020-06-23 00:09:42 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27008) in GitLab 12.10.
2020-04-22 19:07:51 +05:30
Merge Requests, particularly the **Changes** tab, is where source code
is reviewed and discussed. In circumstances where the target branch was
merged into the source branch of the merge request, the changes in the
source and target branch can be shown mixed together making it hard to
understand which changes are being added and which already exist in the
target branch.
2020-05-24 23:13:21 +05:30
In GitLab 12.10, we added a comparison mode, which
2020-04-22 19:07:51 +05:30
shows a diff calculated by simulating how it would look like once merged - a more accurate
representation of the changes rather than using the base of the two
branches. The new mode is available from the comparison target drop down
by selecting **master (HEAD)**. In the future it will
2020-06-23 00:09:42 +05:30
[replace](https://gitlab.com/gitlab-org/gitlab/-/issues/198458) the
2020-04-22 19:07:51 +05:30
current default comparison.
![Merge request versions compare HEAD](img/versions_compare_head_v12_10.png)
2019-09-04 21:01:54 +05:30
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->