Користуєшся GitHub, не до кінця розуміючи, що робиш?
Робота наосліп завжди закінчується зламаним кодом.
На GitHub є лише три зелені кнопки.
І є лише одне місце, куди варто дивитися перед тим, як їх натискати.
У цій статті показано кожну точку на екрані GitHub, куди треба дивитися і що натискати — усі вони виділені червоними рамками.
Підключення, відправка, перевірка diff, merge та revert.
Ми пройдемо цей повний цикл на 10 реальних скриншотах.
AI друкує код.
Ти дивишся і натискаєш.
Складні терміни я пояснюватиму простою мовою одразу, щойно вони з'являтимуться.
※ Інтерфейс 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: покласти гілку main у шафку.
Скопіюй адресу (червона рамка) з цього екрана й надішли її AI одним рядком.
1Завантаж записи з цієї папки на https://github.com/account-name/git-practice
Claude Code сам надрукує ці три рядки.
Claude Code — це AI, який виконує завдання на твоєму комп'ютері за твоїми інструкціями.
У моїй інструкції для нього є обов'язкова умова: запитувати підтвердження перед push.
Push — це операція, коли локальні записи кладуться у шафку.
Тому він тут зупиниться.
Відповідай "Yes", а потім онови сторінку в браузері.
Там, де були три команди, тепер у ряд стоять твої локальні файли. Поруч із ними — commit message.
Це знак того, що ти "підключений".
Зверни увагу на одну деталь.
Над списком файлів написано "main".
Це вказівка на те, яку закладку всередині шафки ти зараз переглядаєш.
Закладка — це гілка (branch).
Вона позначає, у яку колонку ти складаєш записи.
Надалі не чіпай цей "main" напряму.
Спочатку я теж не звертав на це особливої уваги.
Працював у main, а потім витрачав купу часу, шукаючи, куди повертатися.
Коли підключення не вдається, причина майже завжди в адресі.
Забули дописати ".git" у кінці.
Помилка в написанні імені акаунта.
Якщо бачиш "not found", скопіюй адресу з картинки ② ще раз.
Отже, твої локальні записи підключені до GitHub. Далі — щоденний цикл merge через Pull Requests.
**
Розділ 2: Merge через Pull Request | Відправляємо роботу AI, перевіряємо diff і тиснемо кнопки
Звідси починається щоденний цикл.
Pull Request — це заявка з текстом "Будь ласка, злий це".
У цьому розділі потрібно натиснути три зелені кнопки.
AI друкує код.
Твоє завдання — лише дивитися і натискати.
Спершу надішли AI один рядок.
1Створи нову гілку, додай 3 рядки використання в README, зроби commit і завантаж на GitHub
README — це перший файл, у якому пишеться опис репозиторію.
Claude Code створює гілку.
Змінює файл і робить commit.
Нарешті, зупиняється перед push і запитує дозволу.
Відповідай "Yes", а потім відкрий шафку в браузері.
Зверху з'явиться жовтий банер.
Він сповіщає: "Я щойно поклав цю гілку на місце".
Натисни зелену кнопку "Compare & pull request" праворуч.
Це і є "Відправка".
Ніби ти віддаєш чернетку зошита вчителю.
Сама по собі відправка нічого не копіює у фінальну версію.
Копіювання відбувається після перевірки.
На екрані відправки є три місця, куди треба подивитися.
Перше: стрілка в самому верху.
"base: main" і "compare: work-branch"
Це показує, звідки і куди робитиметься merge.
Просто переконайся, що ліворуч стоїть main.
Друге: заголовок у полі "Add a title".
Якщо його генерує AI, там буде короткий опис змін.
Якщо відправляєш вручну, поле автоматично заповниться commit message.
При ручній відправці напиши одним рядком, "що було зроблено".
Третє: зелена кнопка "Create pull request".
Її натискання означає прийняття заявки.
Після відправки потрібна дія людини.
Угорі екрана з'являться чотири вкладки.
Дивись лише на крайню праву — "Files changed".
Це змінені файли.
Зелені рядки — додані.
Червоні рядки — видалені.
Це і є diff.
Якщо 3 рядки, про які ти просив, зелені — все ок.
На прикладі екрана також додалися заголовки та порожні рядки, тому зелених стало 6.
Якщо є червоні рядки, про які ти не просив, не роби merge.
На прикладі екрана є 1 червоний рядок.
Один рядок зник із розділу "Items placed".
Якщо ти цього не замовляв, зупинись.
Запитай AI: "Чому ти видалив цей червоний рядок?"
Це найважливіші 30 секунд, коли делегуєш роботу AI.
Раніше, коли від самих сповіщень про review мені ставало не по собі, я натискав кнопки, навіть не перевіряючи це.
Тепер я спершу рахую червоні рядки.
Якщо є хоча б один непроханий червоний рядок — стоп.
Якщо з diff усе гаразд, повертайся на вкладку "Conversation".
Майже внизу є зелена кнопка "Merge pull request".
Якщо над нею написано "No conflicts with base branch", можна сміливо робити merge.
Після натискання текст зміниться на "Confirm merge".
Натисни ще раз.
Тепер записи робочої гілки злиті з main.
Колір стане фіолетовим, і з'явиться напис "Merged".
Нижче виникне блок із текстом "Pull request successfully merged and closed".
Праворуч від нього — "Delete branch".
Сміливо натискай.
Зникне лише "закладка" робочої гілки всередині шафки.
Оскільки записи вже злиті з main, нічого не втрачається.
Нарешті, онови своє локальне середовище.
Надішли AI: "Перейди на main і стягни останні зміни з GitHub".
Один цикл завершено.
Наступне завдання починай з нової гілки.
Не працюй у main.
Отже, ти пройшов цикл відправки, перевірки diff та merge. Далі поговоримо про Revert — кнопку, яка скасовує помилки після merge.
**
Розділ 3: Revert | Скасовуємо помилки після merge однією кнопкою
Буває, що помилку помічаєш уже після merge.
У Git збережені записи "скасовуються" без їхнього видалення.
На екрані GitHub для цього є спеціальна кнопка.
Вона називається "Revert".
Відкрий Pull Request, який ти щойно змерджив.
Там буде рядок "merged commit … into main".
У крайньому правому кінці цього рядка — "Revert".
Що відбудеться, якщо натиснути?
Записи не видаляються.
Створюється новий Pull Request зі зворотними змінами.
Згідно з офіційною документацією, скасування відбувається саме тоді, коли ти мерджиш цей новий Pull Request.
Тому revert проходить той самий цикл, що й у Розділі 2.
Перевір diff, натисни зелену кнопку.
Замість видалення додається запис про те, що зміни "повернуто назад".
Якщо просиш AI, скажи: "Скасуй Pull Request, який я щойно змерджив".
Claude Code зробить те саме за допомогою git revert.
Є ще один екран, з яким ти можеш зіткнутися.
"This branch has conflicts that must be resolved".
Це конфлікт.
Він виникає, коли один і той самий рядок змінено по-різному в main і в робочій гілці.
Зелена кнопка стає сірою, і натиснути її неможливо.
Не намагайся виправити це прямо на екрані — надішли AI один рядок.
1Стягни main і покажи мені обидві версії конфліктних фрагментів
Яку з них залишити — вирішуєш ти.
Щойно AI усе виправить і завантажить знову, зелена кнопка повернеться.
Конфлікти — це не помилки.
Вони просто констатують факт: один і той самий рядок відредагували двічі.
І наостанок — те, чого не видно на екрані.
Ключі.
Файли з паролями або API-ключами категорично не можна завантажувати на GitHub.
Навіть якщо зробити Revert, щойно ключ опинився в мережі, він вважається скомпрометованим, і його треба перевипускати.
Перед завантаженням надішли AI: "Виключи .env із записів".
На своїй роботі я прописую конфігурації AWS у текстових файлах і використовую точно такий самий цикл.
Конфігурації, змерджені без перевірки diff, одразу летять у прод.
Тому ті критичні 30 секунд перед натисканням кнопки я AI не делегую.
Усі кнопки на екрані натискає людина.
І хоча обсяг задач, які я віддаю AI, постійно зростає, це правило залишається незмінним.
Отже, повний цикл підключення, відправки, merge та revert пройдено.
Наостанок ділюся готовими матеріалами.
Я покроково розписав, як пройти один цикл на екранах GitHub.
Усі екрани та промпти з цієї статті я упакував у формати, готові до використання.
- Плакат-шпаргалка з інтерфейсом GitHub (9 екранів, 69 термінів)
- Карта відновлення, якщо AI щось зламав (6 сценаріїв)
- 7 промптів для одного повного циклу
- Чек-лист перед merge (8 пунктів)
Усе це зібрано в PDF-буклет на 15 сторінок.
Лише з ними ти зможеш почати проходити цикли вже сьогодні.
Щоб отримати їх, просто приєднуйся до Open Chat нижче.
Після вступу дотримуйся інструкцій, надішли слово "Submit", і матеріали прийдуть автоматично.
https://line.me/ti/g2/pEpZQdEyn1BM5Zi2wqLBT2rZYpC0ZaOncIWTag
Підсумок: пройди сьогодні лише один цикл
Не кидай роботу AI напряму в main.
Відправляй із робочої гілки, перевіряй diff і натискай зелені кнопки.
В одному циклі потрібно натиснути три зелені кнопки.
Того дня, коли я вперше сам натиснув Revert, я зрозумів: записи не видаляються.
Після цього я перестав боятися щось чіпати.
Не треба робити все й одразу.
Сьогодні в тебе лише одне завдання.
Відкрий репозиторій, створений у Розділі 1, і надішли AI один рядок.
Створи нову гілку, додай 1 рядок у README і завантаж на GitHub
Коли з'явиться жовтий банер, натисни зелену кнопку й відкрий "Files changed".
Якщо зелений лише один рядок — усе добре.
Подивись на цей рядок власними очима, перш ніж робити merge.
Це перший крок до того, щоб розширити межі того, що можна делегувати AI.
Для інженерів, яким за 30, перемога вимірюється не обсягом роботи, а архітектурою процесів.
Замість того, щоб перевчити інструменти щоразу, коли вони оновлюються, набагато швидше чітко визначити, де треба зупинятися.
AWS та AI розвиваються блискавично.
Слідкувати за логами людей, які тестують це в реальній роботі, значно ефективніше, ніж намагатися встигнути за всім самотужки.
У своїй практиці AI × Engineering я залишаю не лише успішні записи, а й зламані, і відхилені.
Підписуйтесь, щоб не пропустити наступні інсайти! @dan_pro_man
