Commit 4b6a75bf authored by Craig Norris's avatar Craig Norris

Merge branch 'docs-aqualls-create2' into 'master'

More word and line revisions to Create docset

See merge request gitlab-org/gitlab!52850
parents 889e4ede 2e678d42
......@@ -13,12 +13,13 @@ with introducing a **Cherry-pick** button in merge requests and commit details.
## Cherry-picking a merge request
After the merge request has been merged, a **Cherry-pick** button will be available
After the merge request has been merged, a **Cherry-pick** button displays
to cherry-pick the changes introduced by that merge request.
![Cherry-pick Merge Request](img/cherry_pick_changes_mr.png)
After you click that button, a modal will appear showing a [branch filter search box](../repository/branches/index.md#branch-filter-search-box)
After you click that button, a modal displays a
[branch filter search box](../repository/branches/index.md#branch-filter-search-box)
where you can choose to either:
- Cherry-pick the changes directly into the selected branch.
......@@ -28,12 +29,12 @@ where you can choose to either:
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2675) in GitLab 12.9.
When you cherry-pick a merge commit, GitLab will output a system note to the related merge
request thread crosslinking the new commit and the existing merge request.
When you cherry-pick a merge commit, GitLab displays a system note to the related merge
request thread. It crosslinks the new commit and the existing merge request.
![Cherry-pick tracking in Merge Request timeline](img/cherry_pick_mr_timeline_v12_9.png)
Each deployment's [list of associated merge requests](../../../api/deployments.md#list-of-merge-requests-associated-with-a-deployment) will include cherry-picked merge commits.
Each deployment's [list of associated merge requests](../../../api/deployments.md#list-of-merge-requests-associated-with-a-deployment) includes cherry-picked merge commits.
NOTE:
We only track cherry-pick executed from GitLab (both UI and API). Support for [tracking cherry-picked commits through the command line](https://gitlab.com/gitlab-org/gitlab/-/issues/202215) is planned for a future release.
......@@ -44,15 +45,15 @@ You can cherry-pick a commit from the commit details page:
![Cherry-pick commit](img/cherry_pick_changes_commit.png)
Similar to cherry-picking a merge request, you can opt to cherry-pick the changes
Similar to cherry-picking a merge request, you can cherry-pick the changes
directly into the target branch or create a new merge request to cherry-pick the
changes.
Please note that when cherry-picking merge commits, the mainline will always be the
first parent. If you want to use a different mainline then you need to do that
When cherry-picking merge commits, the mainline is always the
first parent. If you want to use a different mainline, you need to do that
from the command line.
Here is a quick example to cherry-pick a merge commit using the second parent as the
Here's a quick example to cherry-pick a merge commit using the second parent as the
mainline:
```shell
......
......@@ -10,13 +10,13 @@ type: reference, concepts
Merge conflicts occur when two branches have different changes that cannot be
merged automatically.
Git is able to automatically merge changes between branches in most cases, but
there are situations where Git will require your assistance to resolve the
Git can merge changes between branches in most cases, but
occasionally Git requires your assistance to resolve the
conflicts manually. Typically, this is necessary when people change the same
parts of the same files.
GitLab will prevent merge requests from being merged until all conflicts are
resolved. Conflicts can be resolved locally, or in many cases within GitLab
GitLab prevents merge requests from being merged until all conflicts are
resolved. Conflicts can be resolved locally, or in many cases in GitLab
(see [conflicts available for resolution](#conflicts-available-for-resolution)
for information on when this is available).
......@@ -24,35 +24,30 @@ for information on when this is available).
NOTE:
GitLab resolves conflicts by creating a merge commit in the source branch that
is not automatically merged into the target branch. This allows the merge
commit to be reviewed and tested before the changes are merged, preventing
is not automatically merged into the target branch. The merge
commit can be reviewed and tested before the changes are merged. This prevents
unintended changes entering the target branch without review or breaking the
build.
## Resolve conflicts: interactive mode
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5479) in GitLab 8.11.
Clicking this will show a list of files with conflicts, with conflict sections
Clicking **Resolve Conflicts** displays a list of files with conflicts, with conflict sections
highlighted:
![Conflict section](img/conflict_section.png)
Once all conflicts have been marked as using 'ours' or 'theirs', the conflict
can be resolved. This will perform a merge of the target branch of the merge
request into the source branch, resolving the conflicts using the options
After all conflicts have been marked as using 'ours' or 'theirs', the conflict
can be resolved. Resolving conflicts merges the target branch of the merge
request into the source branch, using the options
chosen. If the source branch is `feature` and the target branch is `master`,
this is similar to performing `git checkout feature; git merge master` locally.
## Resolve conflicts: inline editor
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6374) in GitLab 8.13.
The merge conflict resolution editor allows for more complex merge conflicts,
which require the user to manually modify a file in order to resolve a conflict,
to be solved right form the GitLab interface. Use the **Edit inline** button
to open the editor. Once you're sure about your changes, hit the
**Commit to source branch** button.
Some merge conflicts are more complex, requiring you to manually modify a file to
resolve them. Use the merge conflict resolution editor to resolve complex
conflicts in the GitLab interface. Click **Edit inline** to open the editor.
After you're sure about your changes, click **Commit to source branch**.
![Merge conflict editor](img/merge_conflict_editor.png)
......@@ -66,13 +61,16 @@ GitLab allows resolving conflicts in a file where all of the below are true:
- The file, with conflict markers added, is not over 200 KB in size
- The file exists under the same path in both branches
If any file with conflicts in that merge request does not meet all of these
criteria, the conflicts for that merge request cannot be resolved in the UI.
If any file in your merge request containing conflicts can't meet all of these
criteria, you can't resolve the merge conflict in the UI.
Additionally, GitLab does not detect conflicts in renames away from a path. For
example, this will not create a conflict: on branch `a`, doing `git mv file1
file2`; on branch `b`, doing `git mv file1 file3`. Instead, both files will be
present in the branch after the merge request is merged.
example, this does not create a conflict:
1. On branch `a`, doing `git mv file1 file2`
1. On branch `b`, doing `git mv file1 file3`.
Instead, both files are present in the branch after the merge request is merged.
<!-- ## Troubleshooting
......
......@@ -9,8 +9,8 @@ type: reference, concepts
If a merge request is not yet ready to be merged, perhaps due to continued development
or open threads, you can prevent it from being accepted before it's ready by flagging
it as a **Draft**. This will disable the "Merge" button, preventing it from
being merged, and it will stay disabled until the "Draft" flag has been removed.
it as a **Draft**. This disables the **Merge** button, preventing it from
being merged. It stays disabled until the **Draft** flag has been removed.
![Blocked Merge Button](img/draft_blocked_merge_button_v13_2.png)
......@@ -22,7 +22,7 @@ To run pipelines for merged results, you must [remove the draft status](#removin
## Adding the "Draft" flag to a merge request
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32692) in GitLab 13.2, Work-In-Progress (WIP) merge requests were renamed to **Draft**. Support for using **WIP** will be removed in GitLab 14.0.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32692) in GitLab 13.2, Work-In-Progress (WIP) merge requests were renamed to **Draft**. Support for using **WIP** is scheduled for removal in GitLab 14.0.
> - **Mark as draft** and **Mark as ready** buttons [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/227421) in GitLab 13.5.
There are several ways to flag a merge request as a Draft:
......@@ -30,15 +30,15 @@ There are several ways to flag a merge request as a Draft:
- Click the **Mark as draft** button on the top-right corner of the merge request's page.
- Add `[Draft]`, `Draft:` or `(Draft)` to the start of the merge request's title. Clicking on
**Start the title with Draft:**, under the title box, when editing the merge request's
description will have the same effect.
description has the same effect.
- **Deprecated** Add `[WIP]` or `WIP:` to the start of the merge request's title.
**WIP** still works but was deprecated in favor of **Draft**. It will be removed in the next major version (GitLab 14.0).
**WIP** still works but was deprecated in favor of **Draft**. It is scheduled for removal in the next major version (GitLab 14.0).
- Add the `/draft` (or `/wip`) [quick action](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics)
in a comment in the merge request. This is a toggle, and can be repeated
to change the status back. Note that any other text in the comment will be discarded.
to change the status back. Note that any other text in the comment is discarded.
- Add `draft:`, `Draft:`, `fixup!`, or `Fixup!` to the beginning of a commit message targeting the
merge request's source branch. This is not a toggle, and doing it again in another
commit will have no effect.
commit has no effect.
## Removing the "Draft" flag from a merge request
......@@ -48,10 +48,10 @@ Similar to above, when a Merge Request is ready to be merged, you can remove the
- Click the **Mark as ready** button on the top-right corner of the merge request's page.
- Remove `[Draft]`, `Draft:` or `(Draft)` from the start of the merge request's title. Clicking on
**Remove the Draft: prefix from the title**, under the title box, when editing the merge
request's description, will have the same effect.
request's description, has the same effect.
- Add the `/draft` (or `/wip`) [quick action](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics)
in a comment in the merge request. This is a toggle, and can be repeated
to change the status back. Note that any other text in the comment will be discarded.
to change the status back. Note that any other text in the comment is discarded.
- Click on the **Resolve Draft status** button near the bottom of the merge request description,
next to the **Merge** button (see [image above](#draft-merge-requests)).
Must have at least Developer level permissions on the project for the button to
......@@ -60,8 +60,8 @@ Similar to above, when a Merge Request is ready to be merged, you can remove the
## Including/excluding WIP merge requests when searching
When viewing/searching the merge requests list, you can choose to include or exclude
WIP merge requests by adding a "WIP" filter in the search box, and choosing "Yes"
(to include) or "No" (to exclude).
WIP merge requests. Add a **WIP** filter in the search box, and choose **Yes**
to include, or **No** to exclude.
![Filter WIP MRs](img/filter_wip_merge_requests.png)
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment