Mentions & Notifications: @mentions, Team Mentions, and Notification Settings
With issues, pull requests, and discussions all covered, this lesson addresses the connective tissue that actually gets the right people's attention at the right time: @mentions and GitHub's notification system, along with the practical settings needed to avoid being overwhelmed by them.
Learning Objectives
- Use an @mention to notify a specific GitHub user within a comment.
- Use a team mention to notify an entire configured team at once.
- Understand the difference between being 'subscribed' to a thread and being explicitly mentioned.
- Configure notification settings to manage the volume of alerts received.
Key Terms to Know Before Using GitHub Mentions and Notifications
- @mention: Typing @ followed by a username within a comment, issue, or pull request, which sends that specific person a notification and links to their profile.
- Team mention: Typing @ followed by an organization team's name (e.g., @org/backend-team), notifying every member of that team at once.
- Watching a repository: A subscription level determining which events on a repository generate notifications for you, configurable per repository.
- Notification fatigue: The phenomenon of becoming desensitized to or overwhelmed by an excessive volume of notifications, reducing their overall effectiveness.
How GitHub Mentions and Notifications Actually Work
Typing `@` followed by a username anywhere within a comment, issue, pull request, or discussion — for example, `@asha-mehta` — creates an **@mention**. This does two things: it renders as a clickable link to that person's profile, and critically, it sends them a direct notification, regardless of their current subscription status to that specific thread. This makes @mentions the most direct way to explicitly bring a specific person's attention to something, such as asking a specific reviewer to look at a pull request, or looping in someone with relevant context on an issue.
For organizations that have configured **teams** (groups of members, typically organized by function like `backend-team` or `design-team`), GitHub also supports **team mentions**, using the format `@org-name/team-name`. Mentioning a team notifies every member of that team simultaneously — useful for requesting a review from 'whoever on the backend team is available' rather than needing to know and mention a specific individual by name.
Beyond explicit mentions, GitHub's notification system is also driven by **subscription**, which happens automatically in several situations (opening an issue/PR, commenting on one, being assigned to one) or can be set manually by **watching** an entire repository. Repository watching has several levels: 'Not watching' (only direct mentions and participation notify you), 'Watching' (all activity in the repository notifies you), and 'Ignoring' (no notifications from this repository at all, even mentions, in the most extreme case).
A common, very real problem on active projects is **notification fatigue** — receiving so many notifications that they lose their effectiveness as a signal, since a barrage of low-priority alerts makes it easy to miss the few that genuinely need attention. GitHub's notification settings (found in account Settings > Notifications) offer meaningful control here: choosing between email and web notifications independently, customizing which specific event types trigger a notification (mentions, review requests, assignments, and more, each configurable separately), and adjusting per-repository watch levels for particularly noisy or particularly critical repositories. A common, practical practice for managing this: set most repositories to 'Not watching' (relying on direct mentions and your own participation to surface what's relevant to you) while explicitly 'Watching' only a small number of repositories where you genuinely need full visibility into all activity.
GitHub Mentions and Notifications: Visual Walkthrough
Draw a comment box containing the text: 'Hey @rohit-sharma, can you review this? Also looping in @acme-corp/backend-team for visibility.' Draw two notification bell icons branching off: one pointing to Rohit's avatar labeled 'Direct @mention — notified individually', another pointing to a group of avatars labeled 'Team mention — every backend-team member notified'. Below, draw a settings panel mockup showing three watch levels for a repository: 'Not watching (mentions/participation only)', 'Watching (all activity)', 'Ignoring (no notifications at all)', with a note: 'Most developers: "Not watching" for most repos, "Watching" for a few critical ones — avoids notification fatigue.'
GitHub Notification Settings: Quick Reference Table
| Mention/Setting | Notifies | Typical Use Case |
|---|---|---|
| @username | One specific person | Requesting a specific person's attention or review |
| @org/team-name | Every member of that team | Requesting attention from 'anyone available' on a team |
| Watching a repository | You, for all activity on that repo | Repositories you need full visibility into |
| Not watching (default participation) | You, only for mentions and threads you're involved in | Most repositories, to avoid notification overload |
Using @mentions: Syntax and Examples
# Example comment using both an individual @mention and a team mention
Hey @rohit-sharma, could you take a look at the discount calculation logic in this PR?
Also looping in @acme-corp/backend-team in case anyone else has context on this.
# Notification settings are configured via GitHub's website
# (Settings > Notifications), not through Git commands, e.g.:
# - Email notifications: OFF for "comments on issues/PRs I'm not involved in"
# - Email notifications: ON for "review requests" and "@mentions"
# - Repository watch level for 'critical-production-service': Watching
# - Repository watch level for most other repos: Not watching (default participation)Breaking Down the Mentions Example
The comment demonstrates both mention types working together: `@rohit-sharma` notifies that one specific person directly, while `@acme-corp/backend-team` simultaneously notifies every member of that configured team. The settings example illustrates a practical, fatigue-avoiding configuration: narrowing email notifications to only the highest-signal event types (review requests and direct mentions), while reserving full 'Watching' status for only the one repository that genuinely requires complete visibility, leaving most other repositories on the lighter default participation-based notification level.
How Mentions and Notifications Are Used on Real Engineering Teams
- Requesting a code review on GitHub commonly combines the platform's formal 'Request review' feature (assigning specific reviewers) with an informal @mention in a comment for extra visibility or urgency.
- Team mentions are frequently used in on-call or incident-response contexts, pinging an entire relevant team (like @company/infrastructure-team) when a specific individual's availability isn't known.
- Engineering leads sometimes coach new hires specifically on notification settings during onboarding, since unmanaged notification volume is a common, avoidable source of early overwhelm on a new, highly active team.
- Some organizations configure notification routing through integrations (like sending certain GitHub notifications into a dedicated Slack channel) specifically to reduce reliance on GitHub's native email notifications for high-volume teams.
GitHub Mentions and Notifications Interview Questions and Answers
Q1. What does an @mention do on GitHub, and how does it differ from simply being subscribed to a thread?
Typing @ followed by a username sends that specific person a direct notification and links to their profile, regardless of whether they were previously subscribed to that thread. This is more explicit and immediate than relying on automatic subscription, which only occurs when someone has already participated in, been assigned to, or opened that specific issue or PR.
Q2. How does a team mention differ from an individual @mention?
An individual @mention (like @username) notifies exactly one specific person. A team mention (like @org-name/team-name) notifies every member of that configured team simultaneously, useful for requesting attention from 'anyone available' on a team rather than a specific named individual.
Q3. What is notification fatigue, and how can GitHub's settings help manage it?
It's the phenomenon of becoming desensitized to or overwhelmed by an excessive volume of notifications, making it harder to notice the ones that genuinely matter. GitHub's notification settings allow customizing which specific event types trigger alerts and adjusting per-repository watch levels, letting someone reserve full notification volume for only the few repositories where it's genuinely needed.
GitHub Mentions and Notifications Quiz: Test Your Understanding
1. What happens when you type @username in a GitHub comment?
- Nothing changes visually or functionally
- That specific person receives a direct notification and a clickable link to their profile is created
- The comment is automatically deleted
- The repository's default branch changes
Answer: B. That specific person receives a direct notification and a clickable link to their profile is created
Explanation: An @mention explicitly notifies the mentioned person directly, regardless of their prior subscription status to that thread, and renders as a link to their profile.
2. What is the correct format for mentioning an entire team on GitHub?
- #team-name
- @team-name-only
- @org-name/team-name
- !team-name
Answer: C. @org-name/team-name
Explanation: Team mentions use the format @org-name/team-name, notifying every member of that configured organizational team simultaneously.
3. What is 'notification fatigue'?
- A GitHub feature that pauses notifications automatically
- Becoming desensitized to or overwhelmed by an excessive volume of notifications, reducing their effectiveness
- A limit GitHub places on how many notifications you can receive per day
- An error that occurs when too many people are mentioned at once
Answer: B. Becoming desensitized to or overwhelmed by an excessive volume of notifications, reducing their effectiveness
Explanation: Notification fatigue describes the real problem of high notification volume making it harder to notice and act on the alerts that genuinely require attention.
Common Mistakes With Mentions and Notifications
- Relying only on automatic subscription rather than an explicit @mention when someone's specific, timely attention is genuinely needed.
- Setting every repository to 'Watching', leading directly to notification fatigue and making genuinely important alerts easy to miss.
- Mentioning an entire team when a specific individual's attention was actually intended, potentially causing confusion about who should actually act.
- Never reviewing or customizing notification settings at all, passively accepting whatever default volume and channels GitHub applies.
GitHub Mentions and Notifications: Exam-Ready Quick Notes
- @username: notifies one specific person directly, regardless of prior subscription.
- @org-name/team-name: notifies every member of that configured team.
- Repository watch levels: Not watching (mentions/participation only), Watching (all activity), Ignoring (nothing).
- Notification fatigue: manage by customizing event-type notifications and reserving full 'Watching' for only critical repositories.
GitHub Mentions and Notifications: Key Takeaways
- @mentions are the most direct, explicit way to bring a specific person's attention to a GitHub conversation, regardless of their subscription status.
- Team mentions extend this same directness to an entire group at once, useful when a specific individual's availability isn't known.
- Deliberately managing notification settings — rather than accepting defaults everywhere — is essential for avoiding fatigue on an active project.
Frequently Asked Questions About GitHub Mentions and Notifications
Q1. How do I notify a specific person on GitHub?
Type @ followed by their username anywhere in a comment, issue, or pull request, such as @asha-mehta. This sends them a direct notification and links to their profile, regardless of whether they were previously subscribed to that thread.
Q2. How do I notify an entire team at once on GitHub?
Use the format @org-name/team-name, for example @acme-corp/backend-team, which notifies every member of that configured organizational team simultaneously.
Q3. What is the difference between watching a repository and just being mentioned in it?
Watching a repository notifies you of all activity happening within it, regardless of whether you're personally involved. Being mentioned only notifies you specifically when someone explicitly tags you or when you're already participating in a particular thread.
Q4. How can I reduce the number of GitHub notifications I receive?
In your account's Notification settings, customize which specific event types (like mentions, review requests, or comments) actually trigger a notification, and adjust your watch level on individual repositories — setting most to 'Not watching' while reserving full 'Watching' status for only the repositories where you genuinely need complete visibility.
Q5. What is notification fatigue, and why does it matter?
It's the effect of receiving so many notifications that they become easy to ignore or overlook, making it harder to notice the ones that genuinely need attention. Deliberately managing notification settings helps prevent this, keeping alerts meaningful rather than overwhelming.
Summary
@mentions (`@username`) explicitly notify a specific person directly within a GitHub comment, issue, or pull request, regardless of their prior subscription to that thread, while team mentions (`@org-name/team-name`) extend this same directness to every member of a configured team at once. Beyond explicit mentions, GitHub's broader notification system is driven by automatic subscription (from participating in or being assigned to a thread) and configurable repository watch levels — Not watching, Watching, or Ignoring. Managing notification fatigue, a genuine and common problem on active projects, involves customizing which specific event types trigger alerts and reserving full 'Watching' status for only the small number of repositories that genuinely require complete visibility, rather than leaving every repository at a high notification volume by default.