github.dev открывает репозиторий в браузерной версии Visual Studio Code. Здесь удобно искать по проекту и согласованно править несколько файлов, когда редактора на компьютере нет или устанавливать его для небольшой задачи не хочется.

Разберём открытие редактора, создание ветки, просмотр изменений и отправку коммита. Понадобятся аккаунт GitHub, интернет и право сохранять изменения в выбранный проект либо собственную копию.

Действия сверены с официальной документацией 3 октября 2026 года. Работа в интерфейсе и внешние коммиты при подготовке не выполнялись.

Что редактор умеет и где его граница

В github.dev есть дерево файлов, поиск, подсветка текста и панель работы с Git. Редактор бесплатен на GitHub.com и работает в браузере. Изменения до коммита сохраняются в локальном хранилище браузера. Устройство редактора.

У него нет вычислительной машины для терминала, установки зависимостей и запуска приложения. Для этого выбирают Codespaces или локальную среду. Поддерживается только часть расширений, способных работать в браузере.

Редактирование и выполнение программы — разные действия. Для правки README запуск не всегда нужен; изменение кода следует проверить подходящим способом до включения в рабочую версию.

Откройте нужный проект

На странице репозитория нажмите клавишу . вне поля ввода. Другой способ — заменить в том же адресе github.com на github.dev. Войдите в нужный аккаунт и проверьте название репозитория и ветку.

Панель файлов слева показывает структуру проекта. Откройте README и связанные документы, чтобы понять задачу. Поиск по содержимому находится в панели с лупой; он помогает увидеть употребления формулировки сразу в нескольких файлах.

Если цель — прочитать чужой проект, чтение не требует делать fork. Если хотите сохранить правку без права записи, понадобится допустимый путь через собственную копию. Правила участия смотрите в README и CONTRIBUTING.md.

Создайте ветку перед правкой

Ветка — отдельная линия изменений. Нажмите её имя в строке состояния внизу окна, введите имя по задаче, например docs-next-step, и выберите Create new branch.

Убедитесь, что новая ветка выбрана. Если в редакторе уже есть незакоммиченные изменения, сначала разберите их: GitHub допускает перенос таких правок между ветками, поэтому смена имени ветки не делает прошлую работу исчезнувшей. Ветки и управление изменениями.

Для общего проекта проверьте, от какой основной ветки начинается задача. Не включайте чужие незавершённые изменения в свой коммит просто потому, что они видны в панели.

Измените связанные документы вместе

Представим, что README говорит «После встречи запишите решения», а чеклист checklist.md содержит пункт «Записать решения». Команда решила фиксировать ещё и следующий шаг. Тогда нужно уточнить обе инструкции, иначе разные документы будут давать разные правила.

В README замените предложение на «После встречи запишите решения и следующий шаг». В чеклист добавьте пункт:

- [ ] Записать следующий шаг, ответственного и срок.

Это пример связи документов, а не обязательное упражнение с новым репозиторием. В вашем проекте выберите настоящую небольшую правку и все места, где она имеет смысл.

После сохранения откройте Source Control слева — панель с символом ветки. Нажмите каждый изменённый файл и прочитайте diff, сравнение прежних и новых строк. Проверьте, что список файлов соответствует задаче и существующие ссылки продолжают вести к правильным именам.

Поиск поможет найти другие упоминания, но массовую замену делайте только после чтения контекста. Одинаковое слово в инструкции, имени файла и URL может требовать разных решений.

Создайте коммит и проверьте отправку

Нажмите + рядом с нужным файлом, чтобы включить его изменения в коммит. Это staging, или выбор состава сохранённой версии. Общая кнопка выбора всех файлов удобна только после проверки всего списка.

Введите сообщение, которое объясняет законченную правку, например «Добавлен следующий шаг в инструкцию встречи». Нажмите Commit & Push. По текущей документации действие создаёт коммит и автоматически отправляет его в выбранную ветку GitHub. Если интерфейс просит подтверждение, прочитайте его и направление отправки. Сохранение коммита в github.dev.

Сохранённый в браузере файл ещё не равен отправленному коммиту. Пока результат не подтверждён на GitHub, не очищайте данные сайта и не рассчитывайте на перенос незавершённой правки на другой компьютер.

Откройте обычную страницу GitHub.com, выберите docs-next-step и проверьте оба документа. В истории должен быть нужный коммит. Главная проверка находится в этой ветке, а не только в опустевшей панели редактора.

Как предложить правку основной версии

Если нужен PR, после коммита используйте значок Pull Request в Source Control либо создайте запрос на GitHub.com. Сверьте исходную ветку с изменением и целевую ветку, дайте понятное описание и проверьте список файлов.

Создание PR ещё не включает изменения в основную ветку. Принятие, или merge, выполняется по правилам проекта после ревью и проверок. В репозитории сайта оно может запустить автоматический выпуск; это стоит знать до подтверждения.

Полезные сценарии

Исправить несколько связанных инструкций. Вход — документы одного проекта и согласованное изменение правила. Найдите все места, создайте ветку, проверьте каждый diff и сохраните понятный коммит. На GitHub будут согласованные документы. Проверка программы, если она затронута, потребует среды запуска.

Изучить проект перед работой. У вас есть незнакомый репозиторий. Откройте README и поиск, найдите нужные термины и файлы, составьте карту дальнейшего чтения. Наблюдаемый результат — конкретные места в исходнике. Для чтения не обязательно менять файлы или устанавливать расширения.

Подготовить небольшую правку с другого компьютера. Вход — доступный репозиторий и разрешение изменить документ. Откройте редактор, используйте отдельную ветку, отправьте коммит и сверьте его в веб-версии. История станет доступна с привычного рабочего места. Неотправленные правки остаются зависимыми от локального хранилища этого браузера.

Если сохранение не удалось

Нет права записи — проверьте аккаунт, владельца и допустимость fork. Нет ожидаемого файла — сопоставьте ветку и путь. В GitHub старая версия — проверьте результат Commit & Push и выбранную ветку в браузере.

Если требуется терминал, он не появится от установки случайного расширения. Выберите подходящую среду отдельно. Для небольшой правки документов достаточно штатного редактора, чтения diff и подтверждения коммита на GitHub.

Следующий шаг

Проверить смысл и оформление исправленного документа поможет README и Markdown на GitHub: как читать описание проекта и оформить своё.

Если коллеги правят инструкции через браузер, согласуйте выбор веток и проверку связанных документов перед отправкой.

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov.