LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

Select Accept to consent or Reject to decline non-essential cookies for this use. You can update your choices at any time in your settings.

Start free trial Sign in

From the course: GitHub Issues and Projects for Teams

Marking duplicates - GitHub Tutorial

From the course: GitHub Issues and Projects for Teams

Start my 1-month free trial Buy for my team

Marking duplicates

“

- [Instructor] Over time, a repository can become unorganized and messy, with duplicate GitHub issues, especially as your team grows. A maintainer, someone who's responsible for managing a repo, which can include tracking and closing issues, ensuring related documentation is up to date, and arranging content to be understandable for new collaborators, is recommended to have an expanding repositories. We will cover how maintainers and other team members can mark issues as duplicates of another, to limit confusion and keep your issues sorted. To begin, we'll visit our repo's issues tab and browse for any similar issues. As seen, we have two issues here that are extremely similar, and if we open each one up we can see that they're talking about the same problem. To promote organization, we'll mark one of these two issues as a duplicate of the other with GitHub's built in action keyword. We can do so by opening the duplicate issue, then within a comment, we can type duplicate of, Followed by the pound symbol and the issue number it duplicates. For a marked as duplicate action to function, the user who creates the duplicate reference comment must have write access to the repository where they create the comment. If we click on comment, we can then see it appear. If for any reason you would like to undo the action of marking an issue as a duplicate, you can unmark duplicate issues by clicking the undo in timeline. This will add a new timeline event, indicating that the issue was unmarked. As we continue growing our repo's issues, we can begin to conceptualize how hectic it can become without following proper organizational protocol. By understanding how to mark issues as duplicates, we're building the correct protocol to ensure our project's issues are readily comprehensible by all team members who interact with them.

Contents