GitHub UI как карта местности

Git появился в 2005 году. GitHub -в 2008. Три года Git жил без GitHub, и многие крупные проекты до сих пор живут без него. Ядро Linux принимает патчи по email через mailing list, kernel.org хостит репозитории, никакого «PR» там нет. Это нормально и работает.

Что добавляет GitHub поверх Git:

• Bare-репозитории на своих серверах (push/pull через HTTPS/SSH).
• Web UI для просмотра кода, истории, diff'ов.
• Pull request -механизм code review поверх веток.
• Issues -трекер задач, привязанный к репо.
• Actions -CI/CD внутри платформы.
• Социальный слой: профиль, follow, star, organization, team.
• Marketplace интеграций (Apps).

Из этого только первые два -чисто инфраструктура. Всё остальное - продуктовые решения GitHub. У GitLab свои аналоги (merge request вместо pull request, GitLab CI/CD вместо Actions, и т.д.). У Bitbucket свои. У Gitea свои. Концепции похожи, но это разные реализации, не «стандарт Git».

Полезный тест на путаницу: если ты говоришь «нужно сделать pull request в git», ты путаешь слои. Git делает push, fetch, merge. Pull request -это просьба в UI форджа «возьми мою ветку в основную», над которой накручены review, обсуждения, проверки. Концептуально это pull-request, живущий не в .git/, а в базе GitHub.

Эта глава -про второй слой. Про сервис, не про инструмент.

Любой репо на GitHub показывает один и тот же набор вкладок в верхней навигации. Что-то может быть отключено настройками админа (например, Wiki выключают, если он не нужен), но концептуально список один. Вот зачем каждая существует.

Code. Дефолтная вкладка, исходники. Что показывает: дерево файлов на текущей ветке, README снизу, список последних коммитов сверху. Что полезно: переключатель ветки/тега в левом верхнем углу, кнопка «Go to file» (Cmd-K в открытом репо) открывает fuzzy-поиск по путям. История коммитов конкретного файла -кнопка «History» внутри файла. Blame -кнопка «Blame» рядом (blame в чистом Git).

Issues. Трекер задач. Issue -не равно тикет в Jira: проще, привязан к репо, легко связывается с PR через #123. Поддерживает labels (теги), assignees, milestones, шаблоны issue (.github/ISSUE_TEMPLATE/). Используется и для багов, и для feature requests, и для обсуждения «как нам сделать X».

Pull Requests. То же самое, что Issues, но с веткой и diff'ом. Каждый PR -это запрос «слей мою ветку в твою». Обсуждение, review, статус-чеки, merge или close -всё здесь. Подробности в pull-request и в главе 17.

Discussions. Форум при репо. Появился в 2020. В отличие от Issues, тут разговор без задачи: «как лучше архитектурно решить X», Q&A, анонсы. На больших OSS-проектах помогает разгрузить Issues от «как мне настроить вашу либу». Включается в Settings.

Actions. CI/CD. Workflow'ы лежат в .github/workflows/*.yml, запускаются по событиям (push, PR, schedule, manual). Эта вкладка -dashboard прошедших запусков, логи, состояние runs. Подробности -глава 19 (Sprint Git-5).

Projects. Канбан-доски и таблицы поверх Issues/PR. Заменяет Trello для проектной работы внутри GitHub. Полностью опциональная вкладка: многие команды живут без неё.

Wiki. Markdown-документация, отдельный git-репо внутри основного. Бывает удобно для долговременных «как-делать» гайдов, которые не хочется держать в основной кодовой базе. Часто выключают -многие предпочитают docs/ в самом репо.

Security. Раздел про уязвимости: Dependabot alerts, security advisories, secret scanning, code scanning. Глубоко -глава 20 (Sprint Git-5). Сейчас важно знать, что эта вкладка существует и где она.

Insights. Аналитика репо: график активности, contributor'ы, статистика по PR и issues. Полезна для понимания «жив ли проект» и для отчётности. Подвкладка «Network» рисует граф всех форков с коммитами -иногда полезно увидеть, чьи форки ушли далеко от вашего.

Settings. Настройки конкретного репо. Видна только тем, у кого есть admin-доступ. Сюда мы вернёмся в секции 15.6.

Этот порядок -не случайный. Code и Issues -ежедневные. PR - когда работаешь с веткой. Discussions, Actions, Projects, Wiki - опциональные. Security, Insights, Settings -административные.

На GitHub есть два типа владельцев репо: пользователь и организация.

Пользователь -это персональный аккаунт. У него профиль (github.com/your-name), почта, ssh-ключи (ssh-keys-git), personal access tokens. Все настройки этого аккаунта -в github.com/settings. Репозитории, которыми он владеет, называются «owned by user-name».

Организация (organization, org) -контейнер для нескольких пользователей и репозиториев. Аналог: компания. У организации свой биллинг, свои репозитории, свои настройки безопасности, свои teams. Один пользователь может быть членом многих организаций -это нормальная ситуация: ты работаешь в компании A, контрибутишь в OSS-org B, имеешь персональные репо как user C.

Team -именованная группа пользователей внутри организации. Например, в org acme есть teams backend, frontend, devops. Каждой команде можно дать доступ к набору репозиториев одним щелчком, вместо того чтобы добавлять каждого пользователя в каждый репо отдельно. Команды могут быть вложенными: backend/database наследует доступы от backend.

Главные следствия для повседневной работы:

• Когда ты делаешь fork репозитория acme/web, форк создаётся либо в твоём пользователе (me/web), либо в одной из твоих организаций. GitHub спрашивает куда.
• SSH-ключи и токены -на уровне пользователя, не организации. Если ты ушёл из компании, твои локальные ключи продолжают работать -надо отзывать вручную (или через SSO).
• Permission на репо может быть выдан напрямую пользователю, или через team. Понимать разницу важно при удалении кого-то: убрать из team часто недостаточно, если есть прямой grant.

Профиль публичный по умолчанию. Всё, что ты делал публично (коммиты в публичные репо, ответы в Issues, активность в Discussions), видно любому. Это часть протокола: открытость - социальный сигнал в OSS. Если хочется приватности, рабочая активность пусть будет в приватных репо или приватных org - контрибуция в них не видна посторонним.

Уведомления GitHub -это твой inbox по всем активным репо. Когда кто-то отметил тебя в PR, ответил на твой комментарий, попросил review -прилетает notification. Они приходят двумя путями: github.com/notifications (веб-инбокс) и email.

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

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

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

Главный совет: пройдись по github.com/notifications/subscriptions и почисти watch-список. Обычно там десятки репо со времён, когда ты ставил Watch ради «следить за релизами», а потом забыл. Каждый из них генерирует шум.

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

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

Email vs web -личное предпочтение. Web-инбокс позволяет «mark as done» и группирует по треду. Email удобен, если у тебя настроены фильтры и ярлыки. Большинство опытных пользователей выключают email-уведомления для всего, кроме mention и review_requested: остальное живёт в веб-инбоксе.

Настройка -в github.com/settings/notifications. Это глобально по аккаунту, не по репо.

Три кнопки в правом верхнем углу любого репо часто путают. Они делают разные вещи.

Watch -подписка на уведомления. Если ты Watch'ишь репо, его активность приходит в твой /notifications. Никакого социального значения, никто не видит твой watch-список кроме тебя. Используешь, когда хочешь быть в курсе.

Star -закладка. Аналог bookmark в браузере, плюс публичный сигнал. Звёзды видны всем: на странице репо и на твоём профиле («Starred» вкладка). Используют для двух целей:

1. Личная закладка: «полезный репо, хочу запомнить».
2. Социальный сигнал: «этот проект мне нравится». Многие мейнтейнеры смотрят на счётчик звёзд как на грубую метрику популярности.

Star не подписывает на уведомления. Можно поставить звезду и не получать ни одного письма.

Fork -клон в твой namespace. Создаёт копию репо как me/web (или my-org/web). Это уже Git-операция: на сервере создаётся отдельный git-репозиторий, ты можешь его клонировать локально, делать коммиты, открывать PR обратно в оригинал. Подробности в fork-vs-clone и главе 12.

Когда какую кнопку:

Большинство watch'ат свои репо и репо команды (для уведомлений), star'ят понравившиеся (для закладок), fork'ают только когда реально собираются контрибутить или модифицировать.

На странице любого репо есть три счётчика: Watch / Star / Fork. Это публичные числа. Не делай из них самоцель: 10к звёзд не означают, что репо живой. Insights -> Contributors покажет, был ли последний коммит в этом году или три года назад.

Самая частая фрустрация на GitHub: «я не могу найти настройку». Корень -в том, что settings разнесены по трём уровням.

Personal Settings (github.com/settings) Твой аккаунт. SSH-ключи, GPG-ключи (gpg-signing), personal access tokens, email, notifications, профиль, billing для персональных репо. Сюда ходишь, когда «не работает push с моей машины» или «хочу настроить 2FA».

Organization Settings (github.com/organizations/acme/settings) Видна owner'ам организации. Биллинг организации, members и teams, разрешения по умолчанию для новых репо, secret-scanning политика на уровне org, SAML/SSO, audit log. Сюда ходишь, когда «хочу добавить нового члена команды» или «настроить, чтобы все репо org были private по умолчанию».

Repository Settings (github.com/acme/web/settings) Видна admin'ам конкретного репо. Имя репо, описание, видимость (public/private/internal), branches, branch protection, secrets для Actions, webhooks, collaborators, integrations. Сюда ходишь, когда «настроить required reviews на main» или «добавить нового collaborator».

Главный принцип: настройка лежит на том уровне, где работает её scope.

• Видимость репо -в Repository Settings, не Organization Settings. У одного репо public, у другого private -это нормально внутри одной org.
• SSH-ключ для push'а -в Personal Settings, не Repository Settings. Ключ -твой, не репо.
• Default branch protection rules для всех новых репо org - Organization Settings, потому что scope -вся org.
• Конкретный branch protection на main именно этого репо - Repository Settings -> Branches.

Когда не можешь найти настройку: подумай, к чему она относится. «К моему аккаунту» -personal. «Ко всей компании» -org. «К этому конкретному репо» -repo. После трёх раз становится рефлексом.

Глобальный поиск -кнопка наверху или клавиша /. Ищет по всему GitHub. Без фильтров результаты бесполезны, поэтому запомни главные:

lang:python def parse_config   # python-код с этой строкой

repo:facebook/react useState   # внутри одного репо

org:vercel filename:.eslintrc  # все eslintrc в org

path:packages/cli/             # код в этом пути

stars:>1000 lang:rust          # популярные репо на Rust

is:public archived:false       # только живые публичные

Полный синтаксис -в docs.github.com/search. Запоминать его целиком не нужно. Запомни, что ты можешь фильтровать по lang, repo, org, path, filename, stars, fork-статусу. Когда нужно - посмотришь точный синтаксис.

Внутри репо есть свой поиск (кнопка «Go to file» или t). Это fuzzy-поиск по путям -набираешь часть имени, выбираешь. Очень быстро для навигации, если репо большой.

Под t есть ещё Cmd/Ctrl-K -командная палитра, открывает в том же поле и поиск, и недавние действия, и навигацию по организациям. Это новее, и многие старые пользователи о ней не знают.

Один типовой кейс, где search спасает: ты хочешь понять, как используется функция parseConfig в open-source. lang:python parseConfig или lang:typescript parseConfig -и видишь реальные примеры из чужих проектов. Это часто полезнее официальной документации: видишь, как с библиотекой работают настоящие люди.

UI -это карта, не объяснение. Карта показывает, где улицы. Объяснение, почему улицы устроены так, ты должен принести сам.

Конкретно: глядя на кнопку «Merge pull request», UI не объяснит тебе, в чём разница между merge commit, squash и rebase -это уже merge-strategies и глава 8. Глядя на Branch protection rules, UI не расскажет, что такое required reviews и зачем они -это глава 17. Глядя на Actions, UI не научит писать workflow -это глава 19.

Это нормально. UI -интерфейс, не учебник. Документация GitHub (docs.github.com) -reference: «как настроить X». Не «зачем X».

Практическое следствие: при освоении новой фичи GitHub читай в такой последовательности:

1. Зачем эта фича существует. Какую проблему решает. Часто -внешний источник, не GitHub Docs: блог-пост, conference talk, статья.
2. Какая модель в основе. Что соответствует чему в Git (ветки, коммиты, refs). Это часть -из глав 1-14 этой книги.
3. Как сделать на практике. Вот тут -GitHub Docs и UI.

Если делаешь шаги в обратном порядке (сразу клик-клик в UI), получится «как-то заработало, но не понимаю». Через неделю сломается, не сможешь починить.

Второй важный момент: UI меняется. То, что сегодня в выпадающем меню под аватаркой, через год -в боковой панели. То, что в Settings -> General, через два года -в новой Security вкладке. Запоминать конкретное расположение кнопок бесполезно. Запоминать «в этом сервисе должна быть настройка X где-то в Settings» -полезно. Найдёшь.

Третий: GitHub не единственный фордж. GitLab, Bitbucket, Gitea, Forgejo, Codeberg -все делают похожие вещи разными словами. PR в GitHub = MR в GitLab. Actions = GitLab CI = Bitbucket Pipelines. Когда понимаешь модель (а не клики), ты без труда переключаешься между ними.