TL;DR: я додав до GitByBit нову практику, яка вчить зливати гілки, робити ребейз і розв'язувати конфлікти. Вона вже доступна в останній версії GitByBit для VS Code.
Знайома ситуація: зливаєш гілку — а тебе зустрічає стіна маркерів конфліктів? Або забираєш зміни з віддаленого репозиторію й виявляєш, що локальні правки воюють із новими? Це один із найприкріших моментів у роботі з Git, особливо для новачків.
Конфлікти злиття — прокляття кожного, хто користується Git.
Саме тому я додав до GitByBit нову практику — «Злиття, ребейз і розв'язання конфліктів». У ній ти:
- Дізнаєшся, чому всі сперечаються про злиття проти ребейзу і коли що використовувати.
- Розберешся, коли Git виконує злиття в режимі fast-forward, а коли створює коміт злиття, і чому ця різниця важлива.
- Відпрацюєш ребейз і злиття на наближених до реальності гілках, не чіпаючи бойових репозиторіїв.
- Навчишся обирати стратегію інтеграції під свій проєкт і правила команди.
Конфлікти — природна частина командної роботи, тож практика не оминає їх, а йде просто в гущу. Ти побачиш, як конфлікти виникають, навчишся вихоплювати головне з маркерів конфліктів і розв'язувати самі конфлікти як у терміналі, так і в графічному інтерфейсі.
Наостанок практика проведе тебе через типовий сценарій невдалого пушу. Ти опиняєшся в ролі досвідченого користувача Git, який допомагає колезі відправити зміни до віддаленого репозиторію, продираючись крізь загадкові помилки та конфлікти злиття.
Нова практика злиттів і ребейзів уже доступна в останній версії GitByBit для VS Code.
TL;DR: через випадкову помилку в новій версії VS Code я втратив кілька тижнів припливу нових користувачів. Урок: моніторинг помилок у реальному часі варто впроваджувати якомога раніше.
Розробляти проєкт наодинці важко. Доводиться носити багато капелюхів одночасно: розробник, дизайнер, маркетолог, підтримка — і це ще не все. Постійно жонглюєш завданнями та пріоритетами, і часом щось таки випадає з рук.
У перший тиждень липня чергове оновлення VS Code змінило внутрішню систему автентифікації, і наявні версії GitByBit почали йти в нескінченний цикл одразу на старті. Фактично, поки проблема не була усунена, ніхто з користувачів не міг пройти курс. А я, нічого не підозрюючи, працював над майбутньою практикою пулл реквестів (яка, до речі, дуже крута й вийшла минулого тижня).
Зрештою хтось повідомив про проблему на GitHub, тож я зміг виправити її та випустити нову версію. Але кілька тижнів припливу нових користувачів фактично втрачено: скористатися курсом вони так і не змогли.
Коли усвідомлюєш, що твій проєкт не працював останні кілька тижнів.
Більшість моїх інших проєктів — це звичайні вебзастосунки, які працюють на моєму власному сервері. Вони збудовані на популярних фреймворках на кшталт Laravel чи React, тож їх легко інтегрувати із системою моніторингу помилок у реальному часі, як-от Sentry або Rollbar. Щойно стається помилка, я одразу отримую сповіщення, заливаю виправлення на сервер, і всі користувачі відразу його отримують. Налагоджувати проблему теж простіше: у мене є доступ до серверних логів, тож видно, що саме пішло не так.
Але GitByBit — не звичайний вебзастосунок. Є розширення для VS Code і вебверсія, і кожна частина має окремий фронтенд і бекенд. Усе це збудовано на різних технологіях, тож звітування про помилки не зводиться до «вставити API-ключ Rollbar десь у конфіг». Досі всі ці частини надсилали телеметрію на мій основний сервер, де вона зберігалась в єдиному централізованому журналі.
Але, на жаль, жодної системи моніторингу, яка сповіщала б про помилки в реальному часі, не було. Тож, щоб дізнатися про помилки, доводилося відкривати й читати ось це:
Не надто читабельно — хіба що ти володієш клінгонською.
Можна час від часу переглядати такі логи, але якщо це не період одразу після релізу, користі мало. Здебільшого нічого поганого не відбувається, тож регулярні перевірки поступово закидаються. Заглядаєш раз на тиждень, потім поринаєш в інші справи — і все, забуто.
Власне, я так і роблю... Але логи треба не лише збирати, а й моніторити.
Здається, що коли щось зламається, про це розкажуть користувачі або воно зрештою спливе в логах. Частка правди тут є, але поки проблему буде помічено, може минути чимало часу — а разом із ним і чимало користувачів, які не змогли пройти курс через помилку. Саме це й сталося з проєктом у липні.
Гей, Олександре, хіба ж ти не досвідчений розробник? Чому нормальне звітування про помилки не було зроблено від самого початку? Чому аж дотепер?
Гарне запитання! У цьому й виклик соло-розробки: справ безліч, а рук лише дві (сподіваюся). Доводиться ПРІОРИТЕЗУВАТИ! До того ж:
- Базові логи вже були, тож за бажання можна було подивитися, що йде не так.
- Я був зайнятий роботою над матеріалами курсу, тож витрачати тижні на бекенд-інфраструктуру не здавалося аж таким пріоритетом.
- Це ранній доступ, тож люди більш-менш готові до проблем і помилок. Я сподівався: якщо щось піде не так, користувачі повідомлять, і я швидко все виправлю.
Але тепер, коли курс стає популярнішим, час завести кращий спосіб моніторити помилки й проблеми в реальному часі.
PostHog поспішає на допомогу
Я вже кілька років намагаюся відв'язатися від Google, але для відстеження дій користувачів на своїх проєктах досі здебільшого використовую Google Analytics. Нещодавно я натрапив на PostHog і вирішив спробувати. Він поєднує кілька потрібних мені речей: відстеження подій, запис сесій і звітування про помилки. А ще в нього щедрий безкоштовний тариф, тож у проєкті на етапі раннього доступу можна поки не перейматися витратами. І до того ж у них є милий їжачок-маскот на ім'я Max, якого я просто обожнюю.
Якщо тобі не подобається Max — ти погана людина.
Настанови для розробників VS Code забороняють підключати власні аналітичні скрипти всередині розширення — здебільшого з міркувань продуктивності та безпеки. Проте телеметрія, зібрана через VS Code API, не порушує правил: її можна приймати на своєму сервері й пересилати далі в PostHog чи будь-який інший сервіс аналітики. Так можна відстежувати дії користувачів і помилки в розширенні, не порушуючи правил.
Тепер помилки збираються в читабельному форматі, тож видно, що і де пішло не так. Повтори групуються, тому одразу зрозуміло, скількох користувачів зачепило.
Кожна помилка містить чимало деталей, які допомагають знайти першопричину. Виправлену помилку можна позначити як розв'язану, щоб вона не захаращувала список.
Це розв'язало проблему з читабельністю та відстеженням, але лишалося питання сповіщень про нові помилки в реальному часі. У PostHog є вбудована система сповіщень, яка може писати в Discord, Slack чи інші канали, щойно стається нова помилка. Тож тепер я одразу дізнаюся про будь-які проблеми й можу швидко їх виправити.
Тепер, якщо з Discord лунає безперервний потік БУП!!!, я знаю: курс зламався. Можна швидко відкрити дашборд PostHog і подивитися, що сталося.
TL;DR: у GitByBit тепер можна потренуватися створювати пулл реквести!
Бувало таке? Знаходиш помилку в чужому коді й думаєш: «Чому це досі не виправили?» Створюєш тикет, чекаєш... і нічого.
Так от: чекати більше не обов'язково.
Можна засукати рукави й виправити все самотужки. Надішли пулл реквест, дочекайся злиття — і твоєю роботою користуватимуться всі, хто працює з цією бібліотекою.
Ніколи не знаєш, що витягнеш із пулл реквеста.
Справжня помилка, справжнє виправлення
Практика починається з життєвого сценарію: твій фітнес-трекер глючить, коли хтось намагається записати активність на полі для гольфу з дистанцією в ярдах. Застосунок не вміє конвертувати ярди в метри й падає. Виправлення просте — додати конвертацію (1 ярд = 0,9144 метра). Латаєш бібліотеку й спокійно живеш далі.
Але за якийсь час прилітає оновлення, яке ламає твоє виправлення. Доводиться накладати латку знову. Потім ще раз. І ще. Стає ясно: час іде на безглузде латання, а виправлення має жити в самій бібліотеці. Як же його туди доправити?
Могутній пулл реквест
Більшість проєктів із відкритим кодом розміщені на GitHub або схожих платформах, і всі вони підтримують пулл реквести. Пулл реквест — це спосіб запропонувати зміни до проєкту. Ти робиш форк репозиторію, вносиш зміни, а потім надсилаєш до оригінального репозиторію пулл реквест із пропозицією злити твої правки в основну кодову базу.
Окрім технічного боку (форків, гілок і злиттів), пулл реквест передбачає ще й спілкування. Потрібно пояснити, що саме змінено, навіщо це потрібно і як воно покращує проєкт. Саме тут можна показати, наскільки добре ти розумієш кодову базу і вмієш робити корисний внесок. Але нічого не вийде, якщо запороти пулл реквест недбалими повідомленнями комітів, запушити купу сторонніх змін або знехтувати правилами проєкту щодо внесення змін.
З таким настроєм у коментарях до пулл реквеста далеко не заїдеш.
До того ж обговорення пулл реквеста може вимагати оновлення форку, ребейзу й розв'язання конфліктів. У процесі задіяний цілий набір Git-навичок, і тепер їх усі можна відпрацювати в GitByBit у реалістичному сценарії зі справжніми репозиторіями на GitHub.
Щоб довести пулл реквест до пуття, потрібно чимало терпіння та уваги до деталей.
Разом із практикою пулл реквестів я додав до Gitopedia кілька нових статей, зокрема і . А ще з'явилися дві нові найкращі практики: та .