linuxlab.io
Учебники▾
  • Линукс и сети
    Файловая система, процессы, TCP/IP, BGP и OSPF
    →
  • Terraform и IaC
    HCL, state, plan/apply на sandbox LocalStack
    →
  • Git и GitHub
    Объектная модель, plumbing, ветвление, GitHub Actions
    →
Все учебники →
ЦеныО платформеВойтиСоздать аккаунт
/
Intro
Lessons
Footer
linuxlab-УчебникиЦеныО платформеКонфиденциальность и куки
Copyright © 2026 LinuxLab. Все права защищены.
linuxlab.io
Учебники▾
  • Линукс и сети
    Файловая система, процессы, TCP/IP, BGP и OSPF
    →
  • Terraform и IaC
    HCL, state, plan/apply на sandbox LocalStack
    →
  • Git и GitHub
    Объектная модель, plumbing, ветвление, GitHub Actions
    →
Все учебники →
ЦеныО платформеВойтиСоздать аккаунт
/
  • Введение
  • Главы
  • How it works
  • Уроки
  • База знаний
  • Собеседование
home/git/kb/Совместная работа/notifications

kb/collab ── Совместная работа ── beginner

GitHub notifications

Веб-инбокс на `github.com/notifications` плюс email-уведомления о событиях в репо. Watch повышает уровень подписки. Фильтры `is:unread reason:mention` спасают от шума. Главная гигиена - периодически чистить watch-список через `/notifications/subscriptions`.

view as markdownaka: github-notifications, watch-notifications

Уведомления GitHub - входящий поток событий по всем активным репо. Приходят двумя путями: веб-инбокс на github.com/notifications и email. Настройка глобальная по аккаунту в github.com/settings/notifications.

Уровни watch

По умолчанию ты подписан как «participating»: получаешь события только по тредам, где сам участвовал (открыл issue, оставил комментарий, был mentioned). Это минимум.

Кнопка Watch на репо повышает уровень:

  • Participating only - дефолт, минимум.
  • All Activity - все Issues и PR в репо.
  • Custom - выбираешь категории: Issues, PR, Releases, Discussions, Security alerts.
  • Ignore - не получать ничего, даже про свою активность.

Самая полезная Custom-комбинация: только Releases, ничего больше. Это превращает Watch в «notify me when new version is out» без шума от Issues/PR.

Фильтры в инбоксе

is:unread                     # непрочитанные
is:unread reason:mention      # упомянули @me
is:unread reason:review-requested   # попросили review
org:acme                      # из конкретной org
repo:acme/web                 # из конкретного репо

Запомни хотя бы is:unread reason:mention - это «то, на что обязательно надо реагировать».

Email vs веб

Большинство опытных пользователей отключают email-уведомления для всего, кроме mention и review_requested. Это в github.com/settings/notifications. Остальные события живут в веб-инбоксе, где их легко закрыть «mark as done» по тредам.

Email удобен, если у тебя настроены фильтры в Gmail/etc. с ярлыками. Без фильтров email-уведомления GitHub быстро становятся шумом.

Чистка подписок

github.com/notifications/subscriptions - список всех репо, на которые ты Watch'ишь. Обычно там десятки старых репо, на которые подписался когда-то и забыл.

Эмпирика: пройдись раз в полгода, выключи Watch на всём, что больше не используешь. Шум резко падает.

Подводные камни

  • Participating не отключается полностью. Если ты автор issue или PR, ты автоматически в подписке. Можно вручную «Unsubscribe» на конкретном треде.
  • Watch не равен Star. Star - публичная закладка, не подписка. Star'нул и не получаешь уведомлений.
  • Email от GitHub Apps бывает отдельно. Например, Dependabot шлёт alerts на email независимо от настроек уведомлений GitHub. Это в Personal Settings -> Notifications -> другая секция.

§ команды

bash
open https://github.com/notifications

Открыть веб-инбокс уведомлений

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

Только упоминания @me в непрочитанных

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

Список Watch-подписок для ревизии

§ см. также

  • pull-requestPull Request (PR)Запрос на влитие ветки в основную с прохождением ревью и CI. На GitHub/GitLab/Bitbucket - стандартный механизм совместной работы. Технически это не команда Git, а функция хостинга, надстроенная над веткой и серией коммитов.
  • code-reviewCode reviewЧтение и обсуждение кода другого разработчика перед merge. Главная цель - поделиться контекстом, а не найти баги (баги - побочный результат). Хороший ревью улучшает код и распространяет знание о системе по команде.
  • branch-protectionBranch protection rulesНабор правил, которые GitHub/GitLab/Bitbucket применяет к попыткам изменить защищённую ветку. Запрещает прямой push, требует PR с approve, требует зелёный CI, блокирует force-push. Без них любой с write-доступом может затереть main одним коммитом.
Footer
linuxlab-
Copyright © 2026 LinuxLab. Все права защищены.
Учебники
Цены
О платформе
Конфиденциальность и куки