Crosslinking issues
There are several ways to mention an issue or make issues appear in each other’s Linked issues section.
For more information on GitLab Issues, read the issues documentation.
From commit messages
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,
add #xxx to the commit message, where xxx is the issue number.
If they are not in the same project, you can add the full URL to the issue
(https://gitlab.com/<username>/<projectname>/issues/<xxx>).
git commit -m "this is my commit message. Ref #xxx"
or
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.
Linking your first commit to your issue is relevant for tracking your process with GitLab Value Stream Analytics. It measures the time taken for planning the implementation of that issue, which is the time between creating an issue and making the first commit.
From linked issues
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.
You do that as explained above, when mentioning an issue from a commit message.
When mentioning issue #111 in issue #222, issue #111 also displays a notification
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
Mentioning issues in merge request comments works exactly the same way as they do for linked issues.
When you mention an issue in a merge request description, it links the issue and merge request together. Additionally, you can also set an issue to close automatically as soon as the merge request is merged.
