Ты используешь GitHub, не до конца понимая, что делаешь?
Работа вслепую всегда заканчивается поломками.
На GitHub всего три зелёные кнопки.
И есть только одно место, куда нужно смотреть перед тем, как их нажать.
В этой статье показано каждое место на экране GitHub, куда нужно смотреть и что нажимать — всё выделено красными рамками.
Подключение, отправка, проверка diff, слияние и откат.
Мы пройдём весь этот цикл на 10 реальных скриншотах.
Печатает ИИ.
Ты смотришь и нажимаешь.
Сложные термины я буду объяснять простым языком по мере их появления.
※ Интерфейс и особенности GitHub в этой статье проверены по состоянию на октябрь 2026 года. Экраны могут измениться.
Глава 1: Подключение к GitHub | Создаём репозиторий и загружаем локальные записи
Интерфейс GitHub на английском.
Но нужные места всегда одни и те же.
Красные рамки на экранах показывают, куда смотреть и что нажимать.
В этой главе нужно нажать всего одну зелёную кнопку.
Для начала создадим один репозиторий.
Репозиторий — это как ячейка в камере хранения, где ты держишь свои записи Git онлайн.
О том, что лежит внутри этой ячейки, и о четырёх ключевых терминах я писал в прошлом посте.
【Со схемами】Git для учеников средней школы
https://x.com/dan_pro_man/status/2107224533099069671?s=20
Даже если ты его не читал, одной этой статьи хватит, чтобы пройти весь цикл.
Зайди на GitHub и выбери «New repository» через иконку «+» в правом верхнем углу.
Если открыть https://github.com/new, попадёшь на тот же экран.
Единственное, что нужно ввести — имя.
В поле «Repository name» напиши название из букв и цифр.
«git-practice» вполне подойдёт.
В блоке «Choose visibility» выбери «Private».
Это значит, что репозиторий будет закрытым.
Переключатель «Add README» пока оставь выключенным.
Если у тебя уже есть локальные записи, подключаться проще к пустому репозиторию.
Нажми зелёную кнопку «Create repository» внизу.
Экран сразу после нажатия — самый важный в этой главе.
Ближе к низу есть заголовок: «…or push an existing repository from the command line».
Три строчки под ним — это команды, которые мы сегодня будем использовать.
Семь строчек выше нужны тем, у кого ещё нет локальных записей, так что их можно пропустить.
Вот что означают эти три строки:
Строка 1: Сообщить локальной записи адрес этой ячейки.
Строка 2: Привести имя главной ветки к «main».
Строка 3: Положить главную ветку в ячейку.
Скопируй адрес (в красной рамке) с этого экрана и отправь его ИИ одной строкой.
1Загрузи записи из этой папки в https://github.com/account-name/git-practice
Claude Code сам напечатает эти три строки.
Claude Code — это ИИ, который выполняет задачи на твоём компьютере по инструкции.
В моей инструкции я требую подтверждения перед пушем.
Пуш — это операция сохранения локальных записей в ячейку.
Поэтому он здесь остановится.
Ответь «Yes», а затем обнови страницу в браузере.
Там, где были три команды, теперь в ряд стоят твои локальные файлы. Рядом с ними — сообщение коммита.
Это знак того, что ты «подключился».
Обрати внимание на одну деталь.
Надпись «main» над списком файлов.
Она показывает, какую закладку ты сейчас просматриваешь внутри ячейки.
Закладка — это ветка.
Она отмечает, в какой столбец ты складываешь записи.
Впредь не трогай этот «main» напрямую.
Поначалу я тоже не придавал этому значения.
Работал в main и тратил кучу времени, пытаясь понять, куда откатываться.
Если подключение падает, дело обычно в адресе.
Не хватает «.git» в конце.
Опечатка в имени аккаунта.
Если видишь «not found», скопируй адрес с картинки ② заново.
На этом этапе твои локальные записи подключены к GitHub. Дальше — ежедневный цикл слияний через Pull Request.
**
Глава 2: Слияние через Pull Request | Отправляем работу ИИ, проверяем diff и жмём
Отсюда начинается ежедневный цикл.
Pull Request — это заявка с текстом «Пожалуйста, слейте это».
В этой главе нужно нажать три зелёные кнопки.
Печатает ИИ.
Твоя задача — только смотреть и нажимать.
Сначала отправь ИИ одну строку.
1Создай новую ветку, добавь 3 строки использования в README, сделай коммит и загрузи на GitHub
README — это первый файл, в котором пишется описание репозитория.
Claude Code создаёт ветку.
Изменяет файл и делает коммит.
В конце останавливается перед пушем и спрашивает.
Ответь «Yes», а затем открой ячейку в браузере.
Вверху появится жёлтый баннер.
Он сообщает: «Я только что сохранил эту ветку».
Нажми зелёную кнопку «Compare & pull request» справа.
Это и есть «Заявка».
Как будто ты отдаёшь черновик тетради учителю.
Сама по себе подача заявки ничего никуда не копирует.
Копирование происходит после проверки.
На экране заявки нужно проверить три вещи.
Первое: стрелка в самом верху.
«base: main» и «compare: work-branch»
Это показывает, откуда и куда делать слияние.
Просто убедись, что слева стоит main.
Второе: заголовок в поле «Add a title».
Если его генерирует ИИ, там будет краткое описание изменений.
Если подаёшь вручную, туда автоматически подставится сообщение коммита.
При ручной подаче напиши в одну строку, «что было сделано».
Третье: зелёная кнопка «Create pull request».
Нажатие принимает заявку.
После подачи нужно вмешательство человека.
В верхней части экрана появятся четыре вкладки.
Смотри только на самую правую — «Files changed».
Это изменённые файлы.
Зелёные строки — добавленные.
Красные строки — удалённые.
Это и есть diff.
Если запрошенные тобой 3 строки зелёные — всё отлично.
На примере также добавились заголовки и пустые строки, поэтому получилось 6 зелёных строк.
Если есть красные строки, о которых ты не просил, не делай слияние.
На примере есть 1 красная строка.
Из раздела «Items placed» исчезла одна строка заметки.
Если ты этого не просил, остановись.
Спроси ИИ: «Почему ты удалил эту красную строку?»
Это самые важные 30 секунд при делегировании работы ИИ.
Раньше, когда от одних уведомлений о ревью у меня сводило желудок, я нажимал, даже не глядя.
Теперь я сначала считаю красные строки.
Если есть хотя бы одна незапрошенная красная строка, я останавливаюсь.
Если с diff всё в порядке, вернись во вкладку «Conversation».
Ближе к низу есть зелёная кнопка «Merge pull request».
Если над ней написано «No conflicts with base branch», можно сливать напрямую.
После нажатия она изменится на «Confirm merge».
Нажми её ещё раз.
Теперь записи рабочей ветки слиты в main.
Цвет станет фиолетовым, и появится надпись «Merged».
Ниже возникнет блок с текстом «Pull request successfully merged and closed».
Справа от него — «Delete branch».
Смело нажимай.
Исчезнет только «закладка» рабочей ветки внутри ячейки.
Так как записи уже слиты в main, ничего не потеряется.
Наконец, обнови локальное окружение.
Отправь ИИ: «Переключись на main и стяни последние изменения с GitHub».
Один цикл завершён.
Следующую задачу начинай с новой ветки.
Не работай в main.
На этом этапе ты прошёл цикл подачи заявки, проверки diff и слияния. Дальше речь пойдёт о Revert — кнопке для отмены ошибок после слияния.
**
Глава 3: Откат (Revert) | Отменяем ошибки после слияния одной кнопкой
Иногда ошибки замечаешь уже после слияния.
В Git сохранённые записи «отменяются» без их удаления.
На экране GitHub для этого есть кнопка.
Она называется «Revert».
Снова открой Pull Request, который ты только что слил.
Там есть строка «merged commit … into main».
В самом конце этой строки находится «Revert».
Что произойдёт при нажатии?
Записи не удалятся.
Создастся новый Pull Request с противоположными изменениями.
Согласно официальной документации, откат произойдёт, когда ты сольёшь этот новый Pull Request.
То есть откат идёт по тому же циклу, что и в Главе 2.
Проверь diff, нажми зелёную кнопку.
Вместо удаления добавляется запись о том, что изменения «отменены».
Если просишь ИИ, скажи: «Отмени Pull Request, который я только что слил».
Claude Code сделает то же самое через git revert.
Есть ещё один экран, с которым ты можешь столкнуться.
«This branch has conflicts that must be resolved».
Это конфликт.
Он возникает, когда одна и та же строка была изменена по-разному в main и в рабочей ветке.
Зелёная кнопка становится серой, и нажать её нельзя.
Не пытайся исправить это на экране — отправь ИИ одну строку.
1Стяни main и покажи мне обе версии конфликтующих фрагментов
Какой вариант оставить, решаешь ты.
Как только ИИ всё исправит и загрузит заново, зелёная кнопка вернётся.
Конфликты — это не провал.
Они просто показывают факт: одну и ту же строку отредактировали дважды.
И последнее — то, чего не видно на экране.
Ключи.
Файлы с паролями или API-ключами никогда нельзя загружать на GitHub.
Даже если ты сделаешь Revert, загруженный ключ считается скомпрометированным, и его придётся перевыпускать.
Перед загрузкой отправь ИИ: «Исключи .env из записей».
На своей работе я прописываю конфигурации AWS в текстовых файлах и следую этому же циклу.
Конфигурации, слитые без проверки diff, улетают прямиком в прод.
Поэтому те самые критические 30 секунд перед нажатием кнопки я ИИ не делегирую.
Все кнопки на экране нажимает человек.
И даже расширяя зону ответственности ИИ, это правило остаётся неизменным.
На этом полный цикл подключения, подачи заявки, слияния и отката пройден.
В конце я даю готовые материалы.
Я расписал шаги для прохождения одного цикла на экране GitHub.
Экраны и промпты из этой статьи я упаковал в форматы, готовые к использованию.
- Плакат-переводчик экранов GitHub (9 экранов, 69 терминов)
- Карта восстановления, если ИИ что-то сломал (6 сценариев)
- 7 промптов для одного полного цикла
- Чек-лист перед слиянием (8 пунктов)
Всё это собрано в PDF-буклет на 15 страниц.
Только с ними ты сможешь начать проходить циклы уже сегодня.
Чтобы получить их, просто вступи в Open Chat ниже.
После вступления следуй инструкциям и отправь слово «Submit» — материалы придут автоматически.
https://line.me/ti/g2/pEpZQdEyn1BM5Zi2wqLBT2rZYpC0ZaOncIWTag
Итог: пройди всего один цикл сегодня
Не отправляй работу ИИ напрямую в main.
Делай заявку из рабочей ветки, проверяй diff и нажимай зелёные кнопки.
В одном цикле нужно нажать три зелёные кнопки.
В день, когда я впервые сам нажал Revert, я понял, что записи не удаляются.
После этого я перестал бояться что-либо трогать.
Не нужно делать всё сразу.
Сегодня у тебя только одна задача.
Открой репозиторий, созданный в Главе 1, и отправь ИИ одну строку.
Создай новую ветку, добавь 1 строку в README и загрузи на GitHub
Когда появится жёлтый баннер, нажми зелёную кнопку и открой «Files changed».
Если там только одна зелёная строка — всё отлично.
Посмотри на эту одну строку своими глазами перед слиянием.
Это первый шаг к расширению того, что можно делегировать ИИ.
Для инженеров старше 30 победа — это не объём работы, а грамотный подход.
Вместо того чтобы переучиваться работать с инструментами после каждого обновления, быстрее определить, где нужно остановиться.
AWS и ИИ развиваются стремительно.
Читать логи тех, кто тестирует всё в реальной работе, быстрее, чем пытаться угнаться за всем в одиночку.
В своей практике на стыке ИИ и инженерии я оставляю не только успешные записи, но и сломанные, и исключённые.
Подписывайтесь, чтобы не пропустить новые инсайты! @dan_pro_man
