TL;DR: Я добавил в GitByBit новую отдельную практику, которая учит слияниям, ребейзу и разрешению конфликтов. Она уже доступна в последней версии GitByBit для VS Code.
Случалось ли такое: пытаешься слить ветку, а тебя встречает стена маркеров конфликта? Или забираешь изменения из удалённого репозитория и обнаруживаешь, что твои локальные правки жёстко не стыкуются со скачанными? Это один из самых бесячих моментов при работе с Git, особенно на старте.
Конфликты слияния: главная боль каждого, кто пользуется Git.
Именно поэтому я добавил в GitByBit новую практику: «Слияния, ребейз и разрешение конфликтов». В ней можно:
- Узнать, из-за чего весь сыр-бор вокруг выбора между слиянием и ребейзом, и когда применять каждый подход.
- Разобраться, в каких случаях Git делает fast-forward слияние, а в каких создаёт коммит слияния, и почему эта разница так важна.
- Потренироваться делать ребейз и слияние на реальных ветках, не боясь сломать рабочий репозиторий.
- Понять, как выбрать правильную стратегию интеграции под конкретный проект и правила команды.
Конфликты — неизбежная часть совместной работы, поэтому практика делает на них особый упор. Будет показано, как вообще возникают конфликты, как вычленять главное в маркерах конфликта и разрешать их как через терминал, так и через графический интерфейс.
В конце практика проведёт через классический сценарий ошибки failed push. Придётся побывать в шкуре опытного пользователя 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 и решил его попробовать. В нём есть всё, что мне нужно: трекинг событий, запись сессий и отчёты об ошибках. А ещё у них щедрый бесплатный тариф, так что на раннем этапе можно не париться о расходах. Ну и у них крутой маскот — ёжик Макс, которого я просто обожаю.
Если тебе не нравится Макс, у тебя нет сердца.
Правила разработки расширений для VS Code запрещают пихать свои скрипты аналитики внутрь расширения — в основном из соображений производительности и безопасности. Зато телеметрия, которую ты собираешь через API самого VS Code, вполне легальна. Можно принимать её на своём сервере, а потом пересылать в PostHog или любой другой сервис аналитики. Так можно отслеживать ошибки и то, как пользователи взаимодействуют с расширением, ничего не нарушая.
Теперь ошибки собираются в читабельном виде, и сразу понятно, что и где сломалось. Дубликаты группируются, так что видно, сколько пользователей столкнулись с проблемой.
В каждой ошибке достаточно деталей, чтобы помочь найти её причину. После исправления помечаешь ошибку статусом resolved, чтобы не засорять список.
Это решило проблему с читабельностью и отслеживанием ошибок, но мне всё ещё не хватало алертов в реальном времени. В PostHog встроена система уведомлений: если вылезает новая ошибка, она может стукнуть в Discord, Slack или куда-то ещё. Так я моментально узнаю о проблемах и могу быстро их закрыть.
Теперь, если из Discord слышен непрекращающийся ПИП!!!, я знаю: курс сломался. Можно быстро открыть дашборд PostHog и посмотреть, в чём дело.
TL;DR: В GitByBit теперь можно потренироваться создавать пулл реквесты!
Бывало такое: находишь ошибку в чужом коде и думаешь: «Почему они это до сих пор не исправили?». Заводишь тикет, ждёшь... и ничего не происходит.
Но суть в том, что больше не нужно ждать.
Можно просто засучить рукава и исправить всё самостоятельно. Создай пулл реквест, дождись слияния — и внезапно все, кто пользуется этой библиотекой, скажут тебе спасибо.
Никогда не знаешь, что вытянешь из пулл реквеста.
Настоящая ошибка, настоящее исправление
Практика начинается со знакомой ситуации: приложение-трекер для фитнеса падает, если кто-то пытается записать активность на поле для гольфа в ярдах. Приложение не умеет конвертировать ярды в метры и вылетает. Исправление банальное — добавить недостающую конвертацию (1 ярд = 0,9144 метра). Патчишь библиотеку и идёшь дальше по своим делам.
Но через какое-то время выходит обновление, которое ломает твоё исправление. Приходится накатывать патч заново. Потом снова. И снова. В какой-то момент понимаешь, что тратишь время на бессмысленное повторение патча, тогда как исправление должно быть в самой библиотеке. Но как его туда закинуть?
Великий и ужасный пулл реквест
Большинство проектов с открытым кодом живут на GitHub или похожих платформах, и все они поддерживают пулл реквесты. Пулл реквест — это способ предложить изменения в проект. Делаешь форк репозитория, вносишь правки, а затем отправляешь пулл реквест в оригинальный репозиторий, предлагая влить твои изменения в основную кодовую базу.
Помимо технических моментов вроде форков, веток и слияний, пулл реквест — это ещё и общение. Нужно объяснить, что именно было сделано, зачем это нужно и как это улучшит проект. Здесь можно показать, насколько хорошо ты понимаешь кодовую базу и можешь реально помочь проекту. И будет очень обидно запороть пулл реквест дурацкими сообщениями коммитов, кучей не связанных между собой правок или несоблюдением правил контрибьютинга.
С таким подходом в комментариях к пулл реквесту далеко не уедешь.
К тому же обсуждение пулл реквеста может заставить обновить форк, сделать ребейз и разрулить конфликты. В этом процессе задействован целый арсенал навыков работы с Git, и теперь их все можно отработать в GitByBit на реалистичном сценарии с настоящими GitHub-репозиториями.
Чтобы успешно провести пулл реквест, потребуется много терпения и внимания к деталям.
Помимо практики по пулл реквестам, я добавил несколько новых статей в Gitопедию: и . А ещё в разделе лучших практик появились два новых материала: и .