linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
Intro
Lessons
Footer
linuxlab-TutorialsPricingAboutPrivacy & cookies
Copyright © 2026 LinuxLab. All rights reserved.
linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
  • Introduction
  • Chapters
  • How it works
  • Lessons
  • Knowledge base
  • Interview prep
home/git/kb/Collaboration/notifications

kb/collab ── Collaboration ── beginner

GitHub notifications

A web inbox at `github.com/notifications` plus email alerts for repo events. Watch raises the subscription level. Filters like `is:unread reason:mention` cut through the noise. The main hygiene habit is reviewing your watch list periodically at `/notifications/subscriptions`.

view as markdownaka: github-notifications, watch-notifications

GitHub notifications are an incoming stream of events across all active repos. They arrive two ways: the web inbox at github.com/notifications and email. Global settings are at github.com/settings/notifications.

Watch levels

By default you are subscribed as "participating": you receive events only for threads you were part of (you opened the issue, left a comment, were mentioned). This is the minimum.

The Watch button on a repo raises the level:

  • Participating only: default, minimum.
  • All Activity: all issues and PRs in the repo.
  • Custom: you choose categories: Issues, PRs, Releases, Discussions, Security alerts.
  • Ignore: receive nothing, not even for your own activity.

The most useful Custom combination is Releases only. It turns Watch into "notify me when a new version is out" with no noise from Issues or PRs.

Filters in the inbox

is:unread                     # unread
is:unread reason:mention      # @me was mentioned
is:unread reason:review-requested   # review was requested
org:acme                      # from a specific org
repo:acme/web                 # from a specific repo

At minimum, remember is:unread reason:mention: that is "what you must respond to."

Email vs. web

Most experienced users turn off email notifications for everything except mention and review_requested. Configure this at github.com/settings/notifications. Everything else lives in the web inbox, where you can close it thread by thread with "mark as done."

Email works well if you have filters set up in Gmail or similar, with labels. Without filters, GitHub email notifications quickly become noise.

Cleaning up subscriptions

github.com/notifications/subscriptions lists all the repos you are watching. There are usually dozens of old repos you subscribed to at some point and forgot.

A practical routine: go through the list every six months and turn off Watch on everything you no longer use. The noise drops sharply.

Pitfalls

  • Participating cannot be turned off completely. If you are the author of an issue or PR, you are automatically subscribed. You can manually "Unsubscribe" on a specific thread.
  • Watch is not the same as Star. Star is a public bookmark, not a subscription. Starring a repo does not give you notifications.
  • Email from GitHub Apps can be separate. Dependabot, for example, sends alerts by email independently of your GitHub notification settings. That is under Personal Settings -> Notifications in a different section.

§ команды

bash
open https://github.com/notifications

Open the web notification inbox

bash
open 'https://github.com/notifications?query=is%3Aunread+reason%3Amention'

Show only @me mentions in unread notifications

bash
open https://github.com/notifications/subscriptions

Open the Watch subscriptions list for review

§ см. также

  • pull-requestPull Request (PR)A request to merge a branch into the main branch after passing review and CI. On GitHub/GitLab/Bitbucket it is the standard mechanism for collaborative work. Technically it is not a Git command but a hosting feature built on top of branches and commits.
  • code-reviewCode reviewReading and discussing another developer's code before merge. The primary goal is sharing context, not finding bugs (bugs are a side effect). A good review improves the code and spreads knowledge of the system across the team.
  • branch-protectionBranch protection rulesA set of rules that GitHub/GitLab/Bitbucket applies to any attempt to modify a protected branch. Blocks direct pushes, requires a PR with an approval, requires green CI, and blocks force-pushes. Without these rules anyone with write access can overwrite main with a single commit.
Footer
linuxlab-
Copyright © 2026 LinuxLab. All rights reserved.
Tutorials
Pricing
About
Privacy & cookies