kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

Browse source
This commit is contained in:
GitLab Bot 2022-08-29 18:09:53 +00:00
parent b6c37979bc
commit b4721adf3f
15 changed files with 592 additions and 422 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
GITALY_SERVER_VERSION
View file

@ -1 +1 @@
e64db386270cd47b44f88f04b139d34313d4780b
2f05fe7dc3ae746ebbc539ecf02be79f5e0965ef

8
config/feature_flags/development/rpm_packages.yml Normal file
View file

@ -0,0 +1,8 @@
---
name: rpm_packages
introduced_by_url: 'https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96019'
rollout_issue_url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/371863'
milestone: '15.4'
type: development
group: group::package
default_enabled: false

28
doc/development/contributing/style_guides.md
View file

@ -222,6 +222,34 @@ We're following [Ciro Santilli's Markdown Style Guide](https://cirosantilli.com/
See the dedicated [Documentation Style Guide](../documentation/styleguide/index.md).
### Guidelines for good practices
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36576/) in GitLab 13.2 as GitLab Development documentation.
*Good practice* examples demonstrate encouraged ways of writing code while
comparing with examples of practices to avoid. These examples are labeled as
*Bad* or *Good*. In GitLab development guidelines, when presenting the cases,
it's recommended to follow a *first-bad-then-good* strategy. First demonstrate
the *Bad* practice (how things *could* be done, which is often still working
code), and then how things *should* be done better, using a *Good* example. This
is typically an improved example of the same code.
Consider the following guidelines when offering examples:
- First, offer the *Bad* example, and then the *Good* one.
- When only one bad case and one good case is given, use the same code block.
- When more than one bad case or one good case is offered, use separated code
blocks for each. With many examples being presented, a clear separation helps
the reader to go directly to the good part. Consider offering an explanation
(for example, a comment, or a link to a resource) on why something is bad
practice.
- Better and best cases can be considered part of the good cases' code block.
In the same code block, precede each with comments: `# Better` and `# Best`.
Although the bad-then-good approach is acceptable for the GitLab development
guidelines, do not use it for user documentation. For user documentation, use
*Do* and *Don't*. For examples, see the [Pajamas Design System](https://design.gitlab.com/content/punctuation/).
## Python
See the dedicated [Python Development Guidelines](../python_guide/index.md).

43
doc/development/documentation/index.md
View file

@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
description: Learn how to contribute to GitLab Documentation.
---
# GitLab Documentation guidelines
# GitLab documentation
The GitLab documentation is [intended as the single source of truth (SSOT)](https://about.gitlab.com/handbook/documentation/) for information about how to configure, use, and troubleshoot GitLab. The documentation contains use cases and usage instructions for every GitLab feature, organized by product area and subject. This includes topics and workflows that span multiple GitLab features and the use of GitLab with other applications.
@ -380,6 +380,47 @@ is made, Danger Bot leaves a comment with further instructions about the documen
process. This is configured in the `Dangerfile` in the GitLab repository under
[/danger/documentation/](https://gitlab.com/gitlab-org/gitlab/-/tree/master/danger/documentation).
## Help and feedback section
This section ([introduced](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/319) in GitLab 11.4)
is displayed at the end of each document and can be omitted by adding a key into
the front matter:
```yaml
---
feedback: false
---
```
The default is to leave it there. If you want to omit it from a document, you
must check with a technical writer before doing so.
## Disqus
We have integrated the docs site with Disqus (introduced by
[!151](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/151)),
allowing our users to post comments.
To omit only the comments from the feedback section, use the following key in
the front matter:
```yaml
---
comments: false
---
```
We're hiding comments only in main index pages, such as [the main documentation index](../../index.md),
since its content is too broad to comment on. Before omitting Disqus, you must
check with a technical writer.
Note that after adding `feedback: false` to the front matter, it will omit
Disqus, therefore, don't add both keys to the same document.
The click events in the feedback section are tracked with Google Tag Manager.
The conversions can be viewed on Google Analytics by navigating to
**Behavior > Events > Top events > docs**.
## Automatic screenshot generator
You can now set up an automatic screenshot generator to take and compress screenshots with the

2
doc/development/documentation/site_architecture/index.md
View file

@ -33,7 +33,7 @@ Then you can use one of these approaches:
of the documentation in the external repository. The landing page is indexed and
searchable on <https://docs.gitlab.com>, but the rest of the documentation is not.
For example, the [GitLab Workflow extension for VS Code](../../../user/project/repository/vscode.md).
We do not encourage the use of [pages with lists of links](../structure.md#topics-and-resources-pages),
We do not encourage the use of [pages with lists of links](../topic_types/index.md#topics-and-resources),
so only use this option if the recommended options are not feasible.
## Monthly release process (versions)

398
doc/development/documentation/structure.md
View file

@ -1,395 +1,11 @@
---
stage: none
group: Style Guide
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
description: What to include in GitLab documentation pages.
redirect_to: 'topic_types/index.md'
remove_date: '2022-11-16'
---
# Documentation topic types (CTRT)
This document was moved to [another location](topic_types/index.md).
At GitLab, we have not traditionally used types for our content. However, we are starting to
move in this direction, and we now use four primary topic types (CTRT):
- [Concept](#concept)
- [Task](#task)
- [Reference](#reference)
- [Troubleshooting](#troubleshooting)
In general, each page in our docset contains multiple topics. (Each heading indicates a new topic.)
Each topic on a page should be a specific topic type. For example,
a page with the title `Pipelines` can include topics that are concepts and tasks.
A page might also contain only one type of information. These pages are generally one of our
[other content types](#other-types-of-content).
## Concept
A concept introduces a single feature or concept.
A concept should answer the questions:
- What is this?
- Why would I use it?
Think of everything someone might want to know if they've never heard of this concept before.
Don't tell them **how** to do this thing. Tell them **what it is**.
If you start describing another concept, start a new concept and link to it.
Concepts should be in this format:
```markdown
# Title (a noun, like "Widgets")
A paragraph that explains what this thing is.
Another paragraph that explains what this thing is.
Remember, if you start to describe about another concept, stop yourself.
Each concept should be about one concept only.
```
### Concept headings
For the heading text, use a noun. For example, `Widgets` or `GDK dependency management`.
If a noun is ambiguous, you can add a gerund. For example, `Documenting versions` instead of `Versions`.
Avoid these heading titles:
- `Overview` or `Introduction`. Instead, use a more specific
noun or phrase that someone would search for.
- `Use cases`. Instead, incorporate the information as part of the concept.
- `How it works`. Instead, use a noun followed by `workflow`. For example, `Merge request workflow`.
## Task
A task gives instructions for how to complete a procedure.
Tasks should be in this format:
```markdown
# Title (starts with an active verb, like "Create a widget" or "Delete a widget")
Do this task when you want to...
Prerequisites (optional):
- Thing 1
- Thing 2
- Thing 3
To do this task:
1. Location then action. (Go to this menu, then select this item.)
1. Another step.
1. Another step.
Task result (optional). Next steps (optional).
```
Here is an example.
```markdown
# Create an issue
Create an issue when you want to track bugs or future work.
Prerequisites:
- You must have at least the Developer role for the project.
To create an issue:
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Issues > List**.
1. In the top right corner, select **New issue**.
1. Complete the fields. (If you have reference content that lists each field, link to it here.)
1. Select **Create issue**.
The issue is created. You can view it by going to **Issues > List**.
```
### Task headings
For the heading text, use the structure `active verb` + `noun`.
For example, `Create an issue`.
If you have several tasks on a page that share prerequisites, you can use the title
`Prerequisites` and link to it.
## Reference
Reference information should be in an easily-scannable format,
like a table or list. It's similar to a dictionary or encyclopedia entry.
```markdown
# Title (a noun, like "Pipeline settings" or "Administrator options")
Introductory sentence.
| Setting | Description |
|---------|-------------|
| **Name** | Descriptive sentence about the setting. |
```
### Reference headings
Reference headings are usually nouns.
Avoid these heading titles:
- `Important notes`. Instead, incorporate this information
closer to where it belongs. For example, this information might be a prerequisite
for a task, or information about a concept.
- `Limitations`. Instead, move the content near other similar information.
If you must, you can use the title `Known issues`.
## Troubleshooting
Troubleshooting topics should be the last topics on a page.
Troubleshooting can be one of three categories:
- **An introductory topic.** This topic introduces the troubleshooting section of a page.
For example:
```markdown
## Troubleshooting
When working with <x feature>, you might encounter the following issues.
```
- **Troubleshooting task.** The title should be similar to a [standard task](#task).
For example, "Run debug tools" or "Verify syntax."
- **Troubleshooting reference.** This information includes the error message. For example:
```markdown
### The error message or a description of it
You might get an error that states <error message>.
This issue occurs when...
The workaround is...
```
If multiple causes or workarounds exist, consider putting them into a table format.
If you use the exact error message, surround it in backticks so it's styled as code.
If a page has more than five troubleshooting topics, put the content on a separate page that has troubleshooting information exclusively. Name the page `Troubleshooting <featurename>`.
### Troubleshooting headings
For the heading of a **Troubleshooting reference** topic:
- Consider including at least a partial error message.
- Use fewer than 70 characters.
If you do not put the full error in the title, include it in the body text.
### Related topics
If inline links are not sufficient, you can create a topic called **Related topics**
and include an unordered list of related topics. This topic should be above the Troubleshooting section.
```markdown
# Related topics
- [Configure your pipeline](link-to-topic)
- [Trigger a pipeline manually](link-to-topic)
```
## General heading text guidelines
In general, for heading text:
- Be clear and direct. Make every word count.
- Use articles and prepositions.
- Follow [capitalization](styleguide/index.md#capitalization) guidelines.
- Do not repeat text from earlier headings. For example, if the page is about merge requests,
instead of `Troubleshooting merge requests`, use only `Troubleshooting`.
See also [guidelines for headings in Markdown](styleguide/index.md#headings-in-markdown).
## Other types of content
There are other types of content in the GitLab documentation that don't
classify as one of the four primary [topic types](#documentation-topic-types-ctrt).
These include:
- [Tutorials](#tutorials)
- [Get started pages](#get-started)
- [Topics and resources pages](#topics-and-resources-pages)
In most cases, these pages are standalone.
### Tutorials
A tutorial is an end-to-end walkthrough of a complex workflow or scenario.
In general, you might consider using a tutorial when:
- The workflow requires a number of sequential steps where each step consists
of sub-steps.
- The steps cover a variety of GitLab features or third-party tools.
Tutorials are learning aids that complement our core documentation.
They do not introduce new features.
Always use the primary [topic types](#documentation-topic-types-ctrt) to document new features.
Tutorials should be in this format:
```markdown
# Title (starts with "Tutorial:" followed by an active verb, like "Tutorial: Create a website")
A paragraph that explains what the tutorial does, and the expected outcome.
To create a website:
1. [Do the first task](#do-the-first-task)
1. [Do the second task](#do-the-second-task)
Prerequisites (optional):
- Thing 1
- Thing 2
- Thing 3
## Do the first task
To do step 1:
1. First step.
1. Another step.
1. Another step.
## Do the second task
Before you begin, make sure you have [done the first task](#do-the-first-task).
To do step 2:
1. First step.
1. Another step.
1. Another step.
```
### Get started
A get started page is a set of steps to help a user get set up
quickly to use a single GitLab feature or tool.
It might consist of more than one task.
Get started pages should be in this format:
```markdown
# Title ("Get started with <feature>")
Complete the following steps to ... .
1. First step.
1. Another step.
1. Another step.
If you need to add more than one task,
consider using subsections for each distinct task.
```
### Topics and resources pages
This page has a list of links that point to important sections
of documentation for a specific GitLab feature or tool.
We do not encourage the use of these types of pages.
Lists like this can get out of date quickly and offer little value to users.
We've included this type here because:
- There are existing pages in the documentation that follow this format,
and they should be standardized.
- They can sometimes help navigate a complex section of the documentation.
If you come across a page like this
or you have to create one, use this format:
```markdown
# Title ("Topics and resources for <feature>")
Brief sentence to describe the feature.
Refer to these resources for more information about <this feature>:
- Link 1
- Link 2
- Link 3
```
## Help and feedback section
This section ([introduced](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/319) in GitLab 11.4)
is displayed at the end of each document and can be omitted by adding a key into
the front matter:
```yaml
---
feedback: false
---
```
The default is to leave it there. If you want to omit it from a document, you
must check with a technical writer before doing so.
### Disqus
We also have integrated the docs site with Disqus (introduced by
[!151](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/151)),
allowing our users to post comments.
To omit only the comments from the feedback section, use the following key in
the front matter:
```yaml
---
comments: false
---
```
We're hiding comments only in main index pages, such as [the main documentation index](../../index.md),
since its content is too broad to comment on. Before omitting Disqus, you must
check with a technical writer.
Note that after adding `feedback: false` to the front matter, it will omit
Disqus, therefore, don't add both keys to the same document.
The click events in the feedback section are tracked with Google Tag Manager.
The conversions can be viewed on Google Analytics by navigating to
**Behavior > Events > Top events > docs**.
## Guidelines for good practices
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36576/) in GitLab 13.2 as GitLab Development documentation.
*Good practice* examples demonstrate encouraged ways of writing code while
comparing with examples of practices to avoid. These examples are labeled as
*Bad* or *Good*. In GitLab development guidelines, when presenting the cases,
it's recommended to follow a *first-bad-then-good* strategy. First demonstrate
the *Bad* practice (how things *could* be done, which is often still working
code), and then how things *should* be done better, using a *Good* example. This
is typically an improved example of the same code.
Consider the following guidelines when offering examples:
- First, offer the *Bad* example, and then the *Good* one.
- When only one bad case and one good case is given, use the same code block.
- When more than one bad case or one good case is offered, use separated code
blocks for each. With many examples being presented, a clear separation helps
the reader to go directly to the good part. Consider offering an explanation
(for example, a comment, or a link to a resource) on why something is bad
practice.
- Better and best cases can be considered part of the good cases' code block.
In the same code block, precede each with comments: `# Better` and `# Best`.
Although the bad-then-good approach is acceptable for the GitLab development
guidelines, do not use it for user documentation. For user documentation, use
*Do* and *Don't*. For examples, see the [Pajamas Design System](https://design.gitlab.com/content/punctuation/).
<!-- This redirect file can be deleted after <2022-11-16>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

46
doc/development/documentation/topic_types/concept.md Normal file
View file

@ -0,0 +1,46 @@
---
stage: none
group: Style Guide
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
---
# Concept topic type
A concept introduces a single feature or concept.
A concept should answer the questions:
- What is this?
- Why would I use it?
Think of everything someone might want to know if they've never heard of this concept before.
Don't tell them **how** to do this thing. Tell them **what it is**.
If you start describing another concept, start a new concept and link to it.
Concepts should be in this format:
```markdown
# Title (a noun, like "Widgets")
A paragraph that explains what this thing is.
Another paragraph that explains what this thing is.
Remember, if you start to describe about another concept, stop yourself.
Each concept should be about one concept only.
```
## Concept headings
For the heading text, use a noun. For example, `Widgets` or `GDK dependency management`.
If a noun is ambiguous, you can add a gerund. For example, `Documenting versions` instead of `Versions`.
Avoid these heading titles:
- `Overview` or `Introduction`. Instead, use a more specific
noun or phrase that someone would search for.
- `Use cases`. Instead, incorporate the information as part of the concept.
- `How it works`. Instead, use a noun followed by `workflow`. For example, `Merge request workflow`.

130
doc/development/documentation/topic_types/index.md Normal file
View file

@ -0,0 +1,130 @@
---
stage: none
group: Style Guide
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
---
# Documentation topic types (CTRT)
At GitLab, we have not traditionally used types for our content. However, we are starting to
move in this direction, and we now use four primary topic types:
- [Concept](concept.md)
- [Task](task.md)
- [Reference](reference.md)
- [Troubleshooting](troubleshooting.md)
The tech writing team sometimes uses the acronym `CTRT` to refer to our topic types.
The acronym refers to the first letter of each topic type.
In general, each page in the GitLab documentation contains multiple topics.
Each topic on a page should be recognizable as a specific topic type.
## Other topic types
In addition to the four primary topic types, we have a few other types.
### Related topics
If inline links are not sufficient, you can create a topic called **Related topics**
and include an unordered list of related topics. This topic should be above the Troubleshooting section.
```markdown
# Related topics
- [Configure your pipeline](link-to-topic).
- [Trigger a pipeline manually](link-to-topic).
```
### Tutorials
A tutorial is page that contains an end-to-end walkthrough of a complex workflow or scenario.
In general, you might consider using a tutorial when:
- The workflow requires a number of sequential steps where each step consists
of sub-steps.
- The steps cover a variety of GitLab features or third-party tools.
Tutorials are learning aids that complement our core documentation.
They do not introduce new features.
Always use the primary [topic types](#documentation-topic-types-ctrt) to document new features.
Tutorials should be in this format:
```markdown
# Title (starts with "Tutorial:" followed by an active verb, like "Tutorial: Create a website")
A paragraph that explains what the tutorial does, and the expected outcome.
To create a website:
1. [Do the first task](#do-the-first-task)
1. [Do the second task](#do-the-second-task)
Prerequisites (optional):
- Thing 1
- Thing 2
- Thing 3
## Do the first task
To do step 1:
1. First step.
1. Another step.
1. Another step.
## Do the second task
Before you begin, make sure you have [done the first task](#do-the-first-task).
To do step 2:
1. First step.
1. Another step.
1. Another step.
```
### Get started
A get started page is a set of steps to help a user get set up
quickly to use a single GitLab feature or tool.
It consists of more than one task.
Get started pages should be in this format:
```markdown
# Title ("Get started with <feature>")
Complete the following steps to ... .
1. First step.
1. Another step.
1. Another step.
If you need to add more than one task,
consider using subsections for each distinct task.
```
In the left nav, use `Get started` as the text. On the page itself, spell out
the full name. For example, `Get started with application security`.
### Topics and resources
Some pages are solely a list of links to other documentation.
We do not encourage this page type. Lists of links can get out-of-date quickly
and offer little value to users, who prefer to search to find information.
## Heading text guidelines
In general, for heading text:
- Be clear and direct. Make every word count.
- Use articles and prepositions.
- Follow [capitalization](../styleguide/index.md#capitalization) guidelines.
- Do not repeat text from earlier headings. For example, if the page is about merge requests,
instead of `Troubleshooting merge requests`, use only `Troubleshooting`.
See also [guidelines for headings in Markdown](../styleguide/index.md#headings-in-markdown).

32
doc/development/documentation/topic_types/reference.md Normal file
View file

@ -0,0 +1,32 @@
---
stage: none
group: Style Guide
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
---
# Reference topic type
Reference information should be in an easily-scannable format,
like a table or list. It's similar to a dictionary or encyclopedia entry.
```markdown
# Title (a noun, like "Pipeline settings" or "Administrator options")
Introductory sentence.
| Setting | Description |
|---------|-------------|
| **Name** | Descriptive sentence about the setting. |
```
## Reference headings
Reference headings are usually nouns.
Avoid these heading titles:
- `Important notes`. Instead, incorporate this information
closer to where it belongs. For example, this information might be a prerequisite
for a task, or information about a concept.
- `Limitations`. Instead, move the content near other similar information.
If you must, you can use the title `Known issues`.

65
doc/development/documentation/topic_types/task.md Normal file
View file

@ -0,0 +1,65 @@
---
stage: none
group: Style Guide
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
---
# Task topic type
A task gives instructions for how to complete a procedure.
Tasks should be in this format:
```markdown
# Title (starts with an active verb, like "Create a widget" or "Delete a widget")
Do this task when you want to...
Prerequisites (optional):
- Thing 1
- Thing 2
- Thing 3
To do this task:
1. Location then action. (Go to this menu, then select this item.)
1. Another step.
1. Another step.
Task result (optional). Next steps (optional).
```
Here is an example.
```markdown
# Create an issue
Create an issue when you want to track bugs or future work.
Prerequisites:
- You must have at least the Developer role for the project.
To create an issue:
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Issues > List**.
1. In the top right corner, select **New issue**.
1. Complete the fields. (If you have reference content that lists each field, link to it here.)
1. Select **Create issue**.
The issue is created. You can view it by going to **Issues > List**.
```
## Task headings
For the heading text, use the structure `active verb` + `noun`.
For example, `Create an issue`.
If you have several tasks on a page that share prerequisites, you can use the title
`Prerequisites` and link to it.
## Related topics
- [View the format for writing task steps](../styleguide/index.md#navigation).

56
doc/development/documentation/topic_types/troubleshooting.md Normal file
View file

@ -0,0 +1,56 @@
---
stage: none
group: Style Guide
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
---
# Troubleshooting topic type
Troubleshooting topics should be the last topics on a page.
If a page has more than five troubleshooting topics, put the content on a separate page that has troubleshooting information exclusively. Name the page `Troubleshoot <featurename>`
and in the left nav, use the word `Troubleshoot` only.
Troubleshooting can be one of three types.
## An introductory topic
This topic introduces the troubleshooting section of a page.
For example:
```markdown
## Troubleshooting
When working with <x feature>, you might encounter the following issues.
```
## Troubleshooting task
The title should be similar to a [standard task](task.md).
For example, "Run debug tools" or "Verify syntax."
## Troubleshooting reference
This topic includes the error message. For example:
```markdown
### The error message or a description of it
You might get an error that states <error message>.
This issue occurs when...
The workaround is...
```
If multiple causes or workarounds exist, consider putting them into a table format.
If you use the exact error message, surround it in backticks so it's styled as code.
## Troubleshooting headings
For the heading of a **Troubleshooting reference** topic:
- Consider including at least a partial error message.
- Use fewer than 70 characters.
If you do not put the full error in the title, include it in the body text.

95
doc/user/project/merge_requests/revert_changes.md
View file

@ -6,50 +6,89 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Revert changes **(FREE)**
You can use Git's powerful feature to [revert any commit](https://git-scm.com/docs/git-revert "Git revert documentation")
by clicking the **Revert** button in merge requests and commit details.
You can revert individual commits or an entire merge request in GitLab.
When you revert a commit in Git, you create a new commit that reverses all actions
taken in the original commit:
- Lines added in the original commit are removed.
- Lines removed in the original commit are added back.
- Lines modified in the original commit are restored to their previous state.
Your **revert commit** is still subject to your project's access controls and processes.
## Revert a merge request
NOTE:
The **Revert** button is shown only for projects that use the
merge method "Merge Commit", which can be set under the project's
**Settings > General > Merge request**. [Fast-forward commits](methods/index.md#fast-forward-merge)
can not be reverted by using the merge request view.
After a merge request is merged, you can revert all changes in the merge request.
After the merge request has been merged, use the **Revert** button
to revert the changes introduced by that merge request.
Prerequisites:
![Revert merge request](img/cherry_pick_changes_mr.png)
- You must have a role in the project that allows you to edit merge requests, and add
code to the repository.
- Your project must use the [merge method](methods/index.md#fast-forward-merge) **Merge Commit**,
which is set in the project's **Settings > General > Merge request**. You can't revert
fast-forwarded commits from the GitLab UI.
After you select that button, a modal appears where you can choose to
revert the changes directly into the selected branch or you can opt to
create a new merge request with the revert changes.
To do this:
After the merge request has been reverted, the **Revert** button is no longer available.
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Merge requests** and identify your merge request.
1. Scroll to the merge request reports area, and find the report showing when the
merge request was merged.
1. Select **Revert**.
1. In **Revert in branch**, select the branch to revert your changes into.
1. Optional. Select **Start a new merge request** to start a new merge request with the new revert commit.
1. Select **Revert**.
The option to **Revert** is no longer shown after a merge request is reverted.
## Revert a commit
You can revert a commit from the commit details page:
You can revert any commit in a repository into either:
![Revert commit](img/cherry_pick_changes_commit.png)
- The current branch.
- A new merge request.
Similar to reverting a merge request, you can opt to revert the changes
directly into the target branch or create a new merge request to revert the
changes.
Prerequisites:
After a commit is reverted, the **Revert** button is no longer available.
- You must have a role in the project that allows you to edit merge requests, and add
code to the repository.
- Your project must use the [merge method](methods/index.md#fast-forward-merge) **Merge Commit**,
which is set in the project's **Settings > General > Merge request**. You can't revert
fast-forwarded commits from the GitLab UI.
When reverting 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.
To do this:
Here's an example to revert a merge commit using the second parent as the
mainline:
1. On the top bar, select **Menu > Projects** and find your project.
1. If you know the merge request that contains the commit:
1. On the left sidebar, select **Merge requests** and identify your merge request.
1. Select **Commits**, then select the title of the commit you want to revert. GitLab displays the contents of the commit.
1. If you don't know the merge request the commit originated from:
1. On the left sidebar, select **Repository > Commits**.
1. Select the title of the commit to display full information about the commit.
1. In the top right corner, select **Options**, then select **Revert**.
1. In **Revert in branch**, select the branch to revert your changes into.
1. Optional. Select **Start a new merge request** to start a new merge request with the new revert commit.
1. Select **Revert**.
```shell
git revert -m 2 7a39eb0
```
The option to **Revert** is no longer shown after a commit is reverted.
### Revert a merge commit to a different parent commit
When you revert a merge commit, the branch you merged to (usually `main`) is always the
first parent. To revert a merge commit to a different parent,
you must revert the commit from the command line:
1. Identify the SHA of the parent commit you want to revert to.
1. Identify the parent number of the commit you want to revert to. (Defaults to 1, for the first parent.)
1. Modify this command, replacing `2` with the parent number, and `7a39eb0` with the commit SHA:
```shell
git revert -m 2 7a39eb0
```
## Related topics
- [Official `git revert` documentation](https://git-scm.com/docs/git-revert)
<!-- ## Troubleshooting

1
lib/api/api.rb
View file

@ -291,6 +291,7 @@ module API
mount ::API::ResourceLabelEvents
mount ::API::ResourceMilestoneEvents
mount ::API::ResourceStateEvents
mount ::API::RpmProjectPackages
mount ::API::RubygemPackages
mount ::API::Search
mount ::API::Settings

46
lib/api/rpm_project_packages.rb Normal file
View file

@ -0,0 +1,46 @@
# frozen_string_literal: true
module API
class RpmProjectPackages < ::API::Base
helpers ::API::Helpers::PackagesHelpers
feature_category :package_registry
before do
require_packages_enabled!
not_found! unless Feature.enabled?(:rpm_packages)
end
params do
requires :id, type: String, desc: 'The ID of a project'
end
resource :projects, requirements: API::NAMESPACE_OR_PROJECT_REQUIREMENTS do
namespace ':id/packages/rpm' do
desc 'Download repository metadata files'
params do
requires :file_name, type: String, desc: 'Repository metadata file name'
end
get 'repodata/*file_name' do
not_found!
end
desc 'Download RPM package files'
params do
requires :package_file_id, type: Integer, desc: 'RPM package file id'
requires :file_name, type: String, desc: 'RPM package file name'
end
get '*package_file_id/*file_name' do
not_found!
end
desc 'Upload a RPM package'
post do
not_found!
end
desc 'Authorize package upload from workhorse'
post 'authorize' do
not_found!
end
end
end
end
end

62
spec/requests/api/rpm_project_packages_spec.rb Normal file
View file

@ -0,0 +1,62 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe API::RpmProjectPackages do
include PackagesManagerApiSpecHelpers
let(:project) { create(:project) }
let(:headers) { {} }
let(:package_name) { 'rpm-package.0-1.x86_64.rpm' }
let(:package_file_id) { 1 }
shared_examples 'an unimplemented route' do
it_behaves_like 'returning response status', :not_found
context 'when feature flag is disabled' do
before do
stub_feature_flags(rpm_packages: false)
end
it_behaves_like 'returning response status', :not_found
end
context 'when package feature is disabled' do
before do
stub_config(packages: { enabled: false })
end
it_behaves_like 'returning response status', :not_found
end
end
describe 'GET /api/v4/projects/:project_id/packages/rpm/repodata/:filename' do
let(:url) { api("/projects/#{project.id}/packages/rpm/repodata/#{package_name}") }
subject { get(url, headers: headers) }
it_behaves_like 'an unimplemented route'
end
describe 'GET /api/v4/projects/:project_id/packages/rpm/:package_file_id/:filename' do
let(:url) { api("/projects/#{project.id}/packages/rpm/#{package_file_id}/#{package_name}") }
subject { get(url, headers: headers) }
it_behaves_like 'an unimplemented route'
end
describe 'POST /api/v4/projects/:project_id/packages/rpm/authorize' do
let(:url) { api("/projects/#{project.id}/packages/rpm/authorize") }
subject { post(url, headers: headers) }
it_behaves_like 'an unimplemented route'
end
describe 'POST /api/v4/projects/:project_id/packages/rpm' do
let(:url) { api("/projects/#{project.id}/packages/rpm") }
subject { post(url, headers: headers) }
it_behaves_like 'an unimplemented route'
end
end