What marking a duplicate actually does
Two issues in your tracker describe almost the same problem.
One is already being worked on, the other just arrived from a new reporter.
You now face a small but real triage decision: should you clone the original issue, or mark the new one as a duplicate of it?
Both actions are built into GitHub, but they do very different things.
Cloning creates a fresh issue with prefilled details.
Marking a duplicate links two existing issues together in the timeline.
Picking the wrong one can split the conversation, confuse reporters or quietly lose context.
This guide walks through what each action actually does, the access you need, and the situations where one fits better than the other.
When you mark an issue or pull request as a duplicate, you type “Duplicate of” followed by the issue or pull request number in the body of a new comment.
GitHub then shows a “marked as duplicate” timeline event, which tracks similar issues together and removes unnecessary burden for both maintainers and collaborators.
GitHub also provides saved replies called “Duplicate issue” and “Duplicate pull request” if you prefer not to type the phrase each time.
There is one documented prerequisite worth knowing before you try it.
For the “marked as duplicate” timeline event to appear, the user who creates the duplicate reference comment must have write access to the repository where they create the comment.
If you comment without that access, the phrase alone does not produce the timeline event.
The action is also reversible in a documented way.
You can unmark duplicate issues and pull requests by clicking Undo in the timeline.
That adds a new timeline event indicating the issue was unmarked, so the original comment history stays visible rather than disappearing.
What cloning an issue actually does
Cloning is a different tool for a different job.
GitHub describes it as a way to quickly create a similar issue: you can clone an existing open issue into the same repository or a different one.
The original issue remains unchanged, and the new issue gets its own URL and can be edited before being created.
Cloning has two documented access requirements.
You must have triage access to the repository that contains the original issue and to the destination repository.
The destination repository must also allow blank issues.