ExamFinch.com My Study

Study guide

6.3 Linking PRs, Templates, Filters, and Assignments

Practice this exam

GitHub Foundations GH-900

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Domains, Scoring, and Candidate Profile 1.3 Official Resources and Hands-On Prep

2 Version Control Fundamentals

2.1 Purpose and Benefits of Version Control 2.2 Git vs GitHub 2.3 Repositories, Commits, and History 2.4 Branches, HEAD, and the Default Branch

3 Working with GitHub

3.1 Accounts, Organizations, and Enterprise Options 3.2 GitHub Flow 3.3 Markdown for Issues and Pull Requests 3.4 GitHub Desktop and GitHub Mobile

4 Repository Structure and Key Files

4.1 Repository Structure and Community Health Files 4.2 Creating Repositories with Templates and Branches 4.3 Adding and Managing Files

5 Repository Insights and Maintenance

5.1 Insights, Stars, Dashboards, and Dependency Insights 5.2 Repository Maintenance and Collaboration Best Practices

6 Issues and Pull Requests

6.1 Issues 6.2 Pull Requests 6.3 Linking PRs, Templates, Filters, and Assignments

7 Discussions, Notifications, and Documentation

7.1 Discussions 7.2 Notifications and Workflow Management 7.3 Gists, Wikis, and GitHub Pages

8 GitHub Actions

8.1 Actions Purpose, Workflows, and Events 8.2 Jobs, Steps, Runners, Secrets, and Reusable Actions

9 GitHub Copilot

9.1 Copilot Suggestions, Agents, Agent Mode, and Multi-Model Support 9.2 Copilot for Individuals, Business, and Enterprise

10 Codespaces and github.dev

10.1 Codespaces, Customization, and Dev Containers 10.2 github.dev vs Codespaces

11 Manage Projects with GitHub

11.1 GitHub Projects and Layout Options 11.2 Configuring Projects, Labels, Milestones, and Workflows 11.3 Saved Replies and Assignees 11.4 Project Insights

12 Account Security and Access

12.1 Two-Factor Authentication and Passkeys 12.2 Access Permissions and Roles 12.3 Enterprise Managed Users and Copilot Policy

13 Privacy, Branch Protection, and Organization Admin

13.1 Privacy, Visibility, and Branch Protection 13.2 Organization Settings, Teams, and Roles

14 Open Source, Sponsors, and InnerSource

14.1 Open Source Benefits and GitHub Sponsors 14.2 How GitHub Supports Open-Source Projects 14.3 InnerSource

15 Marketplace, Discovery, and Collaboration Models

15.1 Following Users and Organizations 15.2 GitHub Marketplace 15.3 Forks, Templates, and Discoverable Repositories

6.3 Linking PRs, Templates, Filters, and Assignments

Key Takeaways Explain This Topic AI

Closing keywords in a pull request description link and auto-close issues only when that pull request merges into the default branch; anyone with write permission can also link up to 10 issues per pull request from the Development sidebar.

Issue templates live on the default branch in .github/ISSUE_TEMPLATE as .md files ( name and about ) or .yml issue forms ( name and description ); pull request templates live on the default branch in the repository root, docs/ , or .github/ .

Issue and pull request search uses qualifiers such as is:issue , is:pr , is:open , assignee:@me , label:bug , milestone: , draft:true , linked:pr , and review-requested:USERNAME .

Assignees (up to 10) own the work item; reviewers are requested to Comment, Approve, or Request changes; CODEOWNERS automatically request review for matching paths on non-draft pull requests and must have write permission.

Keyword-created links are removed by editing the description; only manually linked pull requests can be unlinked from the Development sidebar without editing keywords.

Last updated: August 2026

Why linking, templates, filters, and assignments are one skill

The January 2026 GH-900 outline states Domain 3.2 as a single bullet: explain how to link pull requests to issues and manage templates, filters, and assignments . That is not four trivia piles. It is the operating system around issues and PRs. Linking shows that a fix is in progress and can close the work item. Templates make incoming issues and PRs complete. Filters (search qualifiers) find the right records. Assignments—and the neighboring reviewer and CODEOWNERS mechanisms—answer who is doing the work versus who must approve the change.

GitHub's Linking a pull request to an issue article is the linking source of truth.

Linking pull requests to issues

You can link automatically with keywords or manually from the Development sidebar. Linked work tells collaborators "someone is implementing this" and, for keyword links into the default branch, closes the issue when the pull request (or a closing commit) merges .

Closing keywords

Put a supported keyword in the pull request description (the summary the author writes at create time) or in a commit message :

  • close / closes / closed
  • fix / fixes / fixed
  • resolve / resolves / resolved
  • Linked issue Syntax Example
  • Same repository KEYWORD #ISSUE-NUMBER Closes #10
  • Different repository KEYWORD OWNER/REPOSITORY#ISSUE-NUMBER Fixes octo-org/octo-repo#100
  • Several issues Full syntax for each issue Resolves #10, resolves #123, resolves octo-org/octo-repo#100

Keywords may use a colon and any capitalization: Closes: #10 , CLOSES #10 . Using a keyword to reference a pull request comment from another pull request links those PRs; merging the referencing PR also closes the referenced PR .

Default-branch rule (highest-yield trap): keywords are interpreted only when the pull request targets the repository default branch . Target any other branch and GitHub ignores the keywords: no Development link from the keyword, and merging does not close the issues.

Commit-message keywords close the issue when that commit reaches the default branch, but the pull request that happens to contain the commit is not listed as a linked pull request . If the exam asks how to make the PR show up in the issue's Development section, a description keyword or a manual sidebar link is the answer, not a buried commit message.

To drop a keyword link, edit the pull request description and remove the keyword. Keyword links cannot be cleared from the sidebar alone.

Development sidebar (manual linking)

Anyone with write permissions can link manually.

From a pull request : open the PR → right sidebar Development → choose the issue. You can manually link up to ten issues per pull request , and for this direction the issue and pull request must be in the same repository .

From an issue : open the issue → Development → pick the repository → pick a pull request or a branch → Apply . From the issue side, the linked PR or branch may live in a different repository . GitHub remembers the last repository you picked.

Manual links can be manually unlinked . That is the difference from keyword links. Manual linking also works when you are merging into a non-default branch and still want the issue to show that work is in progress—knowing that auto-close will not fire until a default-branch merge with a keyword (or a later default-branch PR).

You can search linked work with linked:pr (issues that have a closing-reference PR) and linked:issue (PRs linked to an issue they may close). Negate with -linked:pr to find issues nobody is implementing.

Loading diagram... How an issue gets linked to a pull request

Templates: issues and pull requests

Issue and pull request templates standardize what contributors submit. They must live on the default branch ; a template committed only to a feature branch is invisible in the chooser.

Issue templates

Issue templates sit in the hidden .github/ISSUE_TEMPLATE directory.

Markdown templates use a .md extension (names are not case sensitive) with YAML front matter keys name: and about: so they appear in the community profile checklist.

Issue forms use a .yml extension with name: and description: . Forms render web fields (the GitHub form schema) and convert submitted values into a Markdown issue body. You can mark fields required, set default labels, and set default assignees.

config.yml in .github/ISSUE_TEMPLATE customizes the template chooser (for example, whether blank issues are allowed, or extra contact links).

The template builder can commit straight to the default branch or open a pull request. Contributors then pick "Bug report" versus "Feature request" instead of a blank textarea. Security vulnerability reporting is a SECURITY.md policy, not an ordinary issue template—send reporters to the security policy instead of a public bug form when the topic is a vulnerability.

Pull request templates

A pull request template pre-fills the PR body . Store it on the default branch in one of three places : the repository root , the docs/ folder, or the hidden .github/ directory. Filenames are not case sensitive and may use .md or .txt . A common name is PULL_REQUEST_TEMPLATE.md . Unlike issue templates, PR templates are not required to live under ISSUE_TEMPLATE .

You can also set organization- or personal-account default community health files, including templates, that apply when a repository has not defined its own.

Exam traps: putting bug.md in the repo root will not drive the issue chooser. Putting PULL_REQUEST_TEMPLATE.md only under .github/ISSUE_TEMPLATE/ is the wrong folder. Templates on my-feature are unused until they reach the default branch.

Filters and search qualifiers

The Issues and Pull requests tabs have UI filters. Under the hood they are search qualifiers you can type anywhere GitHub search runs. Search is not case sensitive . Quote multi-word values. Prefix - to exclude (except some missing-metadata forms).

Qualifiers GH-900 is most likely to show:

  • Qualifier Meaning
  • is:issue / type:issue Issues only
  • is:pr / type:pr Pull requests only
  • is:open / is:closed State
  • is:merged / is:unmerged Whether a PR merged
  • assignee:USERNAME or assignee:@me Assigned work
  • author:@me You opened it
  • label:bug Has that label; comma form is OR, repeated label: is AND
  • milestone:"v2" In that milestone
  • draft:true / draft:false Draft versus ready PRs
  • linked:pr / linked:issue Closing-reference links
  • review:approved / review:changes_requested / review:none / review:required Review state
  • review-requested:USERNAME That person is still requested (drops off after they review)
  • reviewed-by:USERNAME They already submitted a review
  • no:assignee / no:label / no:milestone Missing metadata
  • head:branch / base:main PR branch names

involves:USERNAME is a logical OR of author, assignee, mentions, and commenter. user-review-requested:@me finds PRs where you personally were asked to review, as opposed to a team request.

A realistic filter on an exam might read: is:issue is:open label:bug -linked:pr assignee:@me —open bugs assigned to you that still have no implementing pull request.

Assignees vs reviewers vs CODEOWNERS

These three mechanisms sit next to each other on a pull request and are the most common Domain 3 mix-up.

Assignees (issues and PRs, maximum 10 ) communicate who is doing the work . Eligible people: yourself, commenters, users with write access, and org members with read access. Assigning does not request a review and does not grant merge rights. Filter: assignee: .

Reviewers are people or teams requested to review a pull request . They submit Comment, Approve, or Request changes. Read access is enough to perform a review; write (or triage, to assign a reviewer) is required to request one. Reviewers appear in the Reviewers sidebar, not the Assignees sidebar. Filter: review-requested: , reviewed-by: .

CODEOWNERS is a file named CODEOWNERS in .github/ , the repository root , or docs/ (GitHub searches in that order). Patterns map paths to @user or @org/team . Those people or teams must have write permission (teams must be visible and have write even if members already have write elsewhere). When a non-draft pull request touches a matching path, GitHub automatically requests those owners. The CODEOWNERS file that matters is the one on the base branch of the pull request. Owners are not auto-requested on drafts; marking ready fires the requests. Branch protection can require a code-owner approval; if several owners match one pattern, any one of them can satisfy that requirement. CODEOWNERS files must stay under 3 MB . Invalid lines are skipped. You cannot use gitignore-style ! negation, character ranges [ ] , or escaped # patterns.

  • Role Answers Auto-requested on new PRs? Typical permission
  • Assignee Who is implementing or driving the item No Read (org) or write, plus commenters

Reviewer Who should Comment / Approve / Request changes Only if someone requests them or CODEOWNERS matches Read to review; write/triage to request

CODEOWNER Who owns these paths Yes, when the PR is ready and paths match Write required

A person can be all three at once. The exam still wants you to pick the mechanism : assign for ownership of the ticket, request review for feedback, CODEOWNERS for path-based automatic review.

Exam scenarios and traps

Keywords on a PR into gh-pages when main is default: no auto-close.

"Show on the issue that a branch is in progress, even before a PR exists" → issue Development sidebar can link a branch , not only a PR.

Ten-issue cap is on manual PR→issue links. Do not invent a 100-issue sidebar.

Write permission for sidebar linking; you cannot manually link with comment-only access.

Issue forms are .yml in .github/ISSUE_TEMPLATE . PR templates are not required to live there.

review-requested: stops matching after that person reviews. review-involves: keeps them.

CODEOWNERS does not assign the issue. It requests PR review.

Draft + CODEOWNERS: no auto-request until ready.

assignee:@me is:pr review:changes_requested is how you find your PRs that are blocked on feedback—not label:reviewer .

Wire the four tools together the way GitHub designed them: a template produces a complete issue, an assignee owns it, a filter finds it, a pull request links it in Development, keywords close it on default-branch merge, and CODEOWNERS plus reviewers guard the merge. That is Domain 3.2.