7.2 Notifications and Workflow Management

Why GH-900 tests notifications as a collaboration skill

Domain 3.3 asks you to identify the purpose of notifications and how to configure them. That is not a settings scavenger hunt. Collaboration on GitHub fails when a reviewer never sees a review request, or when a newcomer watches every repository they star and then disables email entirely. GitHub's About notifications definition is the one to memorize: notifications are updates for specific activity you subscribed to. A subscription is how you opt into ongoing updates for a conversation, a repository, CI, or a class of events.

You configure delivery and subscription types under notification settings (from the inbox Manage notifications menu). To use the notifications inbox on github.com and on GitHub Mobile, you must enable notifications for both Email and On GitHub. If "On GitHub" is off for watching and participating, the inbox has nothing to show.

Watching versus starring versus participating

These three buttons sit near each other on a repository page. They are not interchangeable.

Watching means you subscribed to updates for the repository. GitHub lets you watch a maximum of 10,000 repositories. You can watch from the repository Watch menu or from github.com/watching. Default automatic watching: GitHub can automatically watch all repositories you have push access to, except forks, and you automatically watch repositories you create that your personal account owns. That automatic-watch setting is enabled by default; turn it off in notification settings if you do not want every new grant of push access to flood your inbox.

Per-repository Watch choices:

• Participating and @mentions — only threads you join or are mentioned in.
• All activity — the firehose for that repository.
• Ignore — suppress repository notifications.
• Custom — pick event types: issues, pull requests, releases, security alerts, and discussions (if enabled), in addition to participating and @mentions.

If you Custom-watch Issues, you are subscribed to every issue in that repository, including issues that existed before you chose the option. A later @mention on a pull request still notifies you for that pull request.

Starring is Domain 2/7-adjacent discovery, not a notification tool. Star a repository to find it on your stars page, to signal appreciation, and to influence Explore. Exam trap: "I starred the repo so I will see every pull request." You will not, unless you also Watch.

Participating is thread-scoped. GitHub automatically subscribes you when you:

• are assigned to an issue or pull request
• open an issue or pull request
• comment on a thread
• click Watch or Subscribe on the thread
• are @mentioned (or a team you belong to is @mentioned)
• change the state of a thread (close an issue, merge a pull request)

You also get gist notifications when you author a gist, are mentioned in one, or click Subscribe on one. Unsubscribe from a conversation with Unsubscribe on the issue, pull request, or discussion, or from the inbox. If you unsubscribe and someone later @mentions you (or a team you receive updates for), GitHub resubscribes you.

Inbox, email, and GitHub Mobile

You can take notifications in any combination of three places.

GitHub inbox (https://github.com/notifications) is built for GitHub triage. Default filters match common reasons, shown as labels such as mention, subscribed, or review requested. You can query reason:review-requested to see only pull requests that asked for your review. Inbox actions:

• Done — remove from the inbox; find later with is:done.
• Mark read or unread.
• Save — flag for later; is:saved. Saved items are kept indefinitely.
• Unsubscribe — stop future updates and drop the item from the inbox.

You can triage many notifications at once, preview the originating issue or pull request, group by repository or date, and create custom filters (for example, only mentions in one open-source repo).

Retention: notifications that are not Saved are kept for 5 months. Saved notifications stay. If you unsave a notification older than 5 months, it disappears within a day.

Email goes to a verified email address as multipart HTML plus plain text, including Markdown, @mentions, and emojis from the original thread. Benefits GitHub calls out: your mail client can keep mail longer than five months, you can color-label it, and you can route different organizations or repositories to different addresses (an organization may require a verified domain). You can reply by email; GitHub posts the reply on the issue, pull request, or discussion, strips signatures, and redacts typical email addresses. Enable image loading from notifications@github.com if you want GitHub to mark the web notification read when you read the email.

GitHub Mobile syncs with the web inbox. Installing the app opts you into web notifications; inside the app you enable push for direct mentions, assignments, review requests, and deployment approvals, and you can schedule working hours so pushes only arrive during those windows.

You can also subscribe to CI / GitHub Actions workflow status on repositories that use Actions, and to deploy keys added to organizations you own.

Unsubscribe, custom routing, and security notifications

Unsubscribe is the everyday volume control. From a thread, click Unsubscribe. From the inbox, Unsubscribe removes that notification and future updates from that conversation. From a repository, switch Watch to Participating and @mentions or Ignore if the whole repo is noise. Review github.com/watching periodically; 10,000 watched repositories is a cap, not a goal.

Custom routing means two related skills on GH-900:

1. Custom watch events on one repository (only releases, only security alerts, only discussions).
2. Custom email routing — a default address for participating and watching, optional per-organization addresses, and optional per-repository push-notification addresses. Organizations can restrict email notifications to an approved domain; you must verify an address in that domain or you will not receive that org's mail. Each GitHub notification email includes headers you can filter on in a mail client (including severity headers for Dependabot, below).

On an individual issue or pull request you can further customize when you want future updates, rather than taking every comment after you unsubscribe from the repo firehose.

Dependabot and security notifications (high level)

GH-900 does not ask you to triage a CVE. It does ask whether security alerts are a notification type you can configure. Dependabot alerts notify people with write, maintain, or admin permission when a repository's dependencies have known vulnerabilities. You configure them from the same Manage notifications settings as everything else.

Delivery options GitHub documents:

• On GitHub (inbox / Mobile web notifications) when Dependabot is enabled, when a new manifest is committed, and when a new critical or high vulnerability is found.
• Email on the same triggers, plus an optional Email weekly digest summarizing alerts for up to 10 repositories.
• CLI warnings when you push to a repository that has insecure dependencies.
• GitHub Mobile.

Email and web notifications are per repository when Dependabot is enabled or a new manifest lands, and per organization when a new vulnerability is discovered. GitHub does not send a fresh notification when an existing vulnerability is merely updated. Dependabot email includes an X-GitHub-Severity header so you can filter critical versus low in a mail client. You can also filter the GitHub inbox for Dependabot. Watching with Custom → Security alerts is how you subscribe to those events without watching every issue comment.

Treat other security notifications the same way at exam altitude: they are subscriptions you configure, not a side effect of starring, and they can be routed to inbox, email, or Mobile like any other notification class.

Exam scenarios and traps

• "Bookmark a cool public repo" → Star. "See every new issue on the team repo" → Watch (All activity or Custom → Issues).
• "I commented once" → you participated; you will keep getting that thread until you Unsubscribe.
• Starring never equals watching. Ignoring never equals unstarring.
• Automatic watch of push-access repos (except forks) is on by default.
• Inbox requires On GitHub (and Email, to use the documented inbox+Mobile path).
• Five-month retention unless Saved.
• @mention after unsubscribe brings the thread back.
• Dependabot is configured in notification settings; weekly digest is optional; updates to an already-notified vulnerability do not re-page you.
• Custom watch of Issues does not hide a later @mention on a pull request.

If you can pick Watch versus Star versus Participate from a one-line story, name the three delivery surfaces, and say how to cut volume (Unsubscribe, Custom, Ignore) without dropping security alerts, you have Domain 3.3.