2020-05-26 23:08:26 -04:00
---
stage: Plan
group: Project Management
2020-11-26 01:09:20 -05:00
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
2020-05-26 23:08:26 -04:00
---
2021-06-23 11:07:50 -04:00
# Crosslinking issues **(FREE)**
2017-05-08 04:35:38 -04:00
2021-06-23 11:07:50 -04:00
There are several ways to mention an issue or make [issues ](index.md ) appear in each other's
2021-04-06 14:09:02 -04:00
[Linked issues ](related_issues.md ) section.
2017-05-08 04:35:38 -04:00
2021-04-06 14:09:02 -04:00
For more information on GitLab Issues, read the [issues documentation ](index.md ).
## From commit messages
2017-05-08 04:35:38 -04:00
Every time you mention an issue in your commit message, you're creating
a relationship between the two stages of the development workflow: the
issue itself and the first commit related to that issue.
If the issue and the code you're committing are both in the same project,
2021-04-06 14:09:02 -04:00
add `#xxx` to the commit message, where `xxx` is the issue number.
2017-05-08 04:35:38 -04:00
```shell
git commit -m "this is my commit message. Ref #xxx "
```
2021-08-20 11:10:24 -04:00
If they are in different projects, but in the same group,
add `projectname#xxx` to the commit message.
```shell
git commit -m "this is my commit message. Ref projectname#xxx"
```
If they are not in the same group, you can add the full URL to the issue
(`https://gitlab.com/< username > /< projectname > /issues/< xxx > `).
2017-05-08 04:35:38 -04:00
```shell
git commit -m "this is my commit message. Related to https://gitlab.com/< username > /< projectname > /issues/< xxx > "
```
Of course, you can replace `gitlab.com` with the URL of your own GitLab instance.
2020-12-17 19:10:04 -05:00
Linking your first commit to your issue is relevant
2020-10-05 11:08:56 -04:00
for tracking your process with [GitLab Value Stream Analytics ](https://about.gitlab.com/stages-devops-lifecycle/value-stream-analytics/ ).
2020-12-17 19:10:04 -05:00
It measures the time taken for planning the implementation of that issue,
2017-05-08 04:35:38 -04:00
which is the time between creating an issue and making the first commit.
2021-04-06 14:09:02 -04:00
## From linked issues
2017-05-08 04:35:38 -04:00
2021-04-06 14:09:02 -04:00
Mentioning linked issues in merge requests and other issues helps your team members and
collaborators know that there are opened issues regarding the same topic.
2017-05-08 04:35:38 -04:00
2019-07-03 20:55:35 -04:00
You do that as explained above, when [mentioning an issue from a commit message ](#from-commit-messages ).
2017-05-08 04:35:38 -04:00
2020-12-17 19:10:04 -05:00
When mentioning issue `#111` in issue `#222` , issue `#111` also displays a notification
2019-07-03 20:55:35 -04:00
in its tracker. That is, you only need to mention the relationship once for it to
display in both issues. The same is valid when mentioning issues in [merge requests ](#from-merge-requests ).
2017-05-08 04:35:38 -04:00
![issue mentioned in issue ](img/mention_in_issue.png )
2021-04-06 14:09:02 -04:00
## From merge requests
2017-05-08 04:35:38 -04:00
2019-03-25 00:29:51 -04:00
Mentioning issues in merge request comments works exactly the same way as
2021-04-06 14:09:02 -04:00
they do for [linked issues ](#from-linked-issues ).
2017-05-08 04:35:38 -04:00
2020-12-17 19:10:04 -05:00
When you mention an issue in a merge request description, it
2021-04-06 14:09:02 -04:00
[links the issue and merge request together ](#from-linked-issues ). Additionally,
2019-07-03 20:55:35 -04:00
you can also [set an issue to close automatically ](managing_issues.md#closing-issues-automatically )
as soon as the merge request is merged.
2017-05-08 04:35:38 -04:00
![issue mentioned in MR ](img/mention_in_merge_request.png )