Коммитс (англ. commitics) — документальный разбор настоящей ошибки в открытом проекте, собранный из коммитов, PR и переписки.

Каждый заход даёт два результата: публичный разбор с цитатами и ссылками — и внутренний вывод про свой код. Второй обязателен: разбор без него — чтение, а не работа.

Жанр развлекательный, а не учебный. Читатель пришёл за историей, а не за уроком. Польза извлекается сама, потому что история настоящая.

• Кадр — это коммит, PR или реплика. У каждого есть дата, автор и одно событие. «29 июня 2022 приезжает коммит Add a few strategies» — кадр. «Разработчики добавили стратегии» — пересказ.
• Даты вслух. Не «позже», а «через год и четыре месяца». Промежуток — половина драматургии.
• Название коммита — реплика персонажа. Их не пересказывают, их приводят.
• Одно событие — один абзац.
• Последствие показывается, а не называется. Не «некорректный расчёт», а «кнопка ‘убрать скидку’ выдавала максимальную».
• Пуант в конце. Заголовок интригует, но не раскрывает.
• Тестов и опросов в конце нет. Вопрос с четырьмя вариантами превращает историю в проверочную работу. Вывод — да, экзамен — нет.

Главное — люди, а не код. Читателю интересно место, где работают программисты: команда, ревью, спор, решение, которое кому-то пришлось защищать. Код — повод, а не содержание.

Что искать в первую очередь:

• ревью с возражением — кто-то сказал «так нельзя» и оказался прав (или не оказался, и это ещё интереснее);
• PR, который защищали — автор отвечает на замечания, меняет подход, спорит с мейнтейнером;
• откат, который пришлось объяснять — решение прожило и было отменено;
• мейнтейнер против контрибьютора, команда против сроков, двое несогласных и третий, который принял решение;
• честно названная цена: «мы знаем, что это плохо, и вот почему оставили».

Проект с командой ценнее одиночного репозитория. Не из снобизма: где есть процесс, там есть переписка, а где есть переписка — есть ход мысли. В репо одного человека решение принимается молча, и восстанавливать нечего.

Сгенерированное допустимо, но это не цель. У генерации не бывает ни спора, ни второй стороны, ни человека, который за неё отвечает.

Свой код — короткий хвост, а не половина текста. Проверка обязательна — она делает работу работой, а не чтением. Но читателю она неинтересна: абзац-два, конкретно. Всё остальное место принадлежит чужой истории и людям в ней.

Имя ставится там, где человек что-то сделал или сказал. Автор цитаты, автор коммита, автор починки. Это и точность, и уважение.

«Кто сломал» — обычно неизвестно и почти всегда неважно. git blame показывает последнего, кто трогал строку. Герой разбора — тот, кто нашёл; злодей — обстоятельства.

Мотивы не домысливаются. «Разработчик, вероятно, торопился» — это выдумка про живого человека под его именем. Не написано — значит неизвестно.

Юмор про положение, а не про людей. Смешное почти всегда в самой ситуации. Насмешка над автором и нечестна, и скучна.

Мы попадаем в разборы наравне. Если та же ошибка нашлась у нас — так и пишется, с тем же тоном. Это единственное, что делает остальное честным.

Переносится в любой проект как есть — подставьте тему.

Найди и разбери настоящую историю ошибки в открытом проекте по теме «ТЕМА» (например: очередь задач, списание бонусов, ограничение частоты, часовые пояса, загрузка файлов).

Где искать. Полный git clone (не --filter=blob:none — на нём git log -S умирает). Дальше:

• git log -S "ключевое слово" — когда строка появилась и что было до;
• git log --oneline -- путь/к/файлу — искать откаты и переписывания: «back to», «revert», «actually», «fix race», «properly»;
• gh api repos/ВЛАДЕЛЕЦ/РЕПО/pulls/N и …/issues/N/comments — описания и переписка. Часто ценнее кода: там объясняют, почему не сделали правильнее;
• задача, на которую ссылается PR: там слова пострадавшего;
• документация проекта: там цена решения, описанная для пользователя.

Что считается хорошей находкой. Не «нашёл баг», а нашлась цепочка: кто-то сделал так → столкнулись с тем-то → починили этак → и объяснили словами почему.

И главное — в цепочке должны быть ЛЮДИ. Интересно место, где работают программисты: команда, ревью, спор, решение, которое кому-то пришлось защищать или отменять. Ищи в первую очередь возражение в ревью, PR, который автор отстаивал, откат, который объясняли, несогласие мейнтейнера с контрибьютором, честно названную цену («знаем, что плохо, оставили вот почему»). Проект с командой ценнее одиночного репозитория: где есть процесс, там есть переписка, а где переписка — там ход мысли. Сгенерированный код допустим как материал, но у генерации нет ни спора, ни второй стороны, ни человека, который за неё отвечает.

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

Ссылка на код — на СТРОКУ и по SHA. В каждом пункте, где упоминается код. Не «в ScheduleComponent.tsx», а https://github.com/ВЛАДЕЛЕЦ/РЕПО/blob/<полный-sha>/путь/файл.ts#L574-L590. Ссылка на ветку (blob/main/…) не годится: через месяц строки уедут, и читатель откроет чужой код на том же номере — то есть соврẻт ровно там, где пошли проверять. SHA: git rev-parse HEAD в клоне или gh api repos/О/Р/commits/main --jq .sha; на сайте GitHub — клавиша y. В шаге списка ссылка кладётся в refs, а не в текст.

Правила точности. Цитаты дословные и со ссылкой, перевод рядом с оригиналом. Имена — там, где человек что-то сказал или сделал. Мотивы не домысливать: не написано — значит неизвестно. «Кто сломал» по git blame не устанавливается — он показывает, кто трогал строку последним.

Остановка. Полчаса поисков без цепочки — тема закрывается, берётся другая. Разборы делаются рядом с разработкой, а не вместо неё.