{
  "index": 290,
  "slug": "editorial-2019-12-mechanism-code-ownership",
  "title": "Кому принадлежит изменение: Git, CODEOWNERS и границы ответственности",
  "excerpt": "Последний автор строки не всегда знает смысл контракта, а CODEOWNERS не заменяет review. Разбираем, как разделить историю, маршрут проверки, решение и контроль после merge.",
  "contentHtml": "<p>Ошибка на стыке модулей часто начинается с простой задержки. В задаче уже указан файл, в <code>git blame</code> видно имя, но исправление ждёт ответа. Разработчик считает владельцем последнего автора строки. Автор помнит рефакторинг и не знает, кто принимает решение по контракту. Pull request получает формальный approval, а после merge никто не проверяет спорный ответ. Цена ошибки — не только потерянные часы. Неизвестный статус может попасть в успешный сценарий, изменение контракта — пройти без нужного специалиста, а тот же дефект вернуться в соседнем файле.</p>\n<p>Тезис простой: «владелец кода» — не одна роль. История Git отвечает на вопрос «кто менял». CODEOWNERS отвечает на вопрос «кого запросить по пути». Review отвечает на вопрос «какое решение принято для diff». Отдельное назначение нужно для проверки после merge. Если смешать эти ответы, команда получает имя вместо ответственности. Если разделить их, каждый риск получает проверяемый маршрут.</p>\n<h2>Симптом начинается не с имени</h2>\n<p>Формулировка «у модуля нет владельца» слишком общая. Начните с наблюдаемого поведения: gateway вернул <code>unknown</code>, checkout показал успешную оплату; retry записал старый результат поверх нового; изменение файла прошло без человека, который знает допустимые статусы. В такой записи есть вход, неверный результат и цена. Она помогает найти границу решения, а не назначить виноватого.</p>\n<p>Пример ниже искусственный. Он не описывает production-инцидент, настоящих людей или измеренный эффект. В нём обработчик получает ответ платёжного gateway. Статусы <code>paid</code> и <code>declined</code> известны, остальные значения функция возвращает как отдельное <code>unknown</code>. Следующий переход не должен трактовать его как <code>success</code>, а исходный ответ остаётся доступным для диагностики.</p>\n<pre><code>function nextState(response) {\n  if (response.status === 'paid') return 'success';\n  if (response.status === 'declined') return 'failure';\n  return 'unknown';\n}\n\n// Искусственный пример: unknown не считается success.\nconst state = nextState({ status: 'pending_review' });\nconsole.log(state); // unknown</code></pre>\n<p>Функция возвращает <code>unknown</code>, но сама по себе не знает, что делать дальше. Владелец контракта решает, допустим ли отдельный <code>unknown</code>, можно ли повторить запрос и какие данные сохранить. Владелец пути кода проверяет обработчик, переходы интерфейса и тест. Эти люди могут совпасть, но совпадение надо подтвердить, а не предположить по истории строки.</p>\n<h2>Четыре следа вместо одного «owner»</h2>\n<p><code>git blame</code> показывает revision и автора, которые последними изменили строку. Это полезный вход в расследование. Строка могла прийти из рефакторинга, переноса файла или форматирования. Поэтому blame не доказывает, что автор принимает сегодняшнее бизнес-решение. <code>git log</code> добавляет историю пути и связанных изменений, но также не назначает текущую ответственность.</p>\n<p>Ниже CODEOWNERS означает именно механизм GitHub. Он сопоставляет путь с пользователями или командами и автоматически запрашивает их review для обычного открытого pull request; draft pull request не вызывает такой запрос, пока его не переведут в режим ready for review. GitHub ищет файл в <code>.github/</code>, корне или <code>docs/</code>; если файлов несколько, использует первый по порядку поиска. Для запроса review GitHub использует CODEOWNERS из base branch — ветки, в которую попадёт pull request. Правило в feature branch само по себе не гарантирует нужный маршрут.</p>\n<p>Review тоже имеет узкую границу. Comment оставляет замечание, Approve сообщает, что изменение готово к merge, Request changes блокирует принятие до исправления. Ни один статус не записывает, кто проверит поведение после выпуска. Поэтому follow-up надо назначить отдельно: это может быть проверка лога, сценария или отдельная техническая задача.</p>\n<div class=\"table-scroll\"><table><caption>Симптом → причина → проверка → действие</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Задача уходит к автору строки</td><td>Историю приняли за текущего владельца решения</td><td><code>git blame -L</code>, затем diff и связанный контракт</td><td>Сохранить автора как факт и отдельно назначить decision owner</td></tr><tr><td>Нужный reviewer не получил запрос</td><td>Не совпал путь, выбран не тот base branch или owner не имеет доступа</td><td>Проверить расположение файла, регистр пути, порядок правил и права</td><td>Исправить точное правило CODEOWNERS и открыть новый review-маршрут</td></tr><tr><td>Есть approval, но спорный статус не разобран</td><td>Review проверил форму diff, а не риск контракта</td><td>Найти в обсуждении ответ на вопрос о <code>unknown</code></td><td>Запросить конкретное подтверждение или отправить Request changes</td></tr><tr><td>После merge никто не знает результат</td><td>Follow-up не был частью записи изменения</td><td>Проверить назначенного исполнителя и ожидаемый сигнал</td><td>Создать отдельное действие; не закрывать задачу по одному факту merge</td></tr></tbody></table></div>\n<h2>Как работает маршрут CODEOWNERS</h2>\n<p>В примере общий маршрут задаёт запасного reviewer, а более узкие пути уточняют область. Правила вымышлены и приведены только для объяснения синтаксиса. В GitHub последнее совпавшее правило имеет больший приоритет. Несколько owners для одного пути записывают в одной строке. Отрицание через <code>!</code> и диапазоны в квадратных скобках нельзя переносить из `.gitignore` без проверки: в CODEOWNERS они не работают как в gitignore.</p>\n<pre><code># Искусственный пример, не конфигурация рабочего репозитория.\n*                                      @example/platform\n/web/checkout/                       @example/checkout\n/web/checkout/gateway/               @example/payments\n/docs/checkout-contract.md           @example/payments @example/checkout\n/.github/CODEOWNERS                   @example/repository-admins</code></pre>\n<p>Для изменения <code>/web/checkout/gateway/status.js</code> сначала проверяют, какое правило совпало и кто имеет право получить review. Для документа контракта можно явно запросить обе команды, если именно они обладают знаниями о семантике и потребителе. Но сама строка с двумя owners не делает approval обоих обязательными: при требовании review from Code Owners GitHub считает достаточным approval любого из них. Если риск требует двух разных решений, это надо записать в описании изменения и запросить обе команды явно.</p>\n<figure><img src=\"/assets/editorial/2019/code-ownership-resolution-2019.svg\" alt=\"Схема разделяет исторический след Git, маршрут CODEOWNERS, решение review и проверку после merge.\" loading=\"lazy\" /><figcaption>История помогает найти контекст, CODEOWNERS направляет запрос, review проверяет diff, а результат после merge требует отдельного действия.</figcaption></figure>\n<h2>Пример записи решения</h2>\n<p>Короткая запись в issue или pull request должна связывать риск с ролью. Для искусственного сценария достаточно такого контракта:</p>\n<pre><code>symptom: unknown status enters success flow\ndecision_owner: payments-contract\ncode_path_owner: checkout\nreview_questions:\n  - Is unknown a separate state?\n  - Can retry create a second transition?\nfollow_up_owner: checkout\nready_when:\n  - unknown is visible in the test\n  - success transition rejects unknown\n  - review answers both questions\n  - follow-up has a recorded result</code></pre>\n<p>Эта запись не создаёт новую должность и не обещает реальный production-сигнал. Она задаёт границу проверки. Если проект не использует CODEOWNERS, те же поля можно хранить в задаче и запросить reviewer вручную. Механизм маршрутизации изменится, но вопросы останутся теми же.</p>\n<h2>Порядок действий</h2>\n<ol><li>Запишите вход, наблюдаемый симптом, неверный результат и цену ошибки. Не начинайте с поиска человека.</li><li>Ограничьте историю нужным диапазоном строк и путём: используйте <code>git blame -L</code>, затем <code>git log --follow -- path</code> и связанные документы. Не переносите имя из истории в поле decision owner.</li><li>Назначьте владельца решения по контракту. Он должен ответить, что означает неизвестный статус и какие переходы допустимы.</li><li>Если вы используете GitHub, проверьте CODEOWNERS из base branch. Убедитесь, что путь написан с правильным регистром, правило расположено в поддерживаемом файле, а команда имеет нужный доступ.</li><li>Сформулируйте вопросы review по риску: семантика контракта, побочные переходы, отрицательный тест. Общий текст «проверьте код» не закрывает эти вопросы.</li><li>До merge назначьте follow-up и ожидаемый сигнал. Это может быть результат тестового сценария или проверка доступного контура; не называйте непроверенное production-результатом.</li><li>После merge запишите результат. Если сигнал не подтверждён, оставьте задачу открытой или создайте связанную. Статус «merged» означает состояние кода, а не доказательство исправления симптома.</li></ol>\n<h2>Отрицательный путь и ограничения</h2>\n<p>Отрицательный путь должен ломать удобную гипотезу. Удалите владельца из учебной записи: критерий готовности должен перестать выполняться. Подставьте неизвестный статус: он не должен перейти в <code>success</code>. Перенесите файл в соседний каталог: маршрут CODEOWNERS должен измениться или проверка должна сообщить о несоответствии. Если любой из этих тестов проходит без назначенного решения, критерий слишком слабый.</p>\n<p>Есть и ограничения механизма. CODEOWNERS знает путь, но не знает, кто владеет внешним API или продуктовым смыслом. Git знает историю, но не знает будущую ответственность. Review фиксирует решение по конкретному diff и может устареть после существенной правки. Автоматический запрос не равен прочитанному review. Эти границы нельзя закрыть ещё одним wildcard-правилом.</p>\n<p>Минимальная рабочая карта выглядит так: один симптом, один владелец решения, владелец пути, reviewer с вопросом по риску, отрицательный тест и отдельный follow-up. Один человек может занимать все роли. Готовность проверяется не количеством имён, а свидетельствами: неизвестный вход остаётся отдельным состоянием, review отвечает на заявленные вопросы, а последующее действие имеет записанный результат или явную новую задачу.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: About code owners</a> — расположение и синтаксис CODEOWNERS, base branch, доступ owners и связь с branch protection.</li><li><a href=\"https://docs.github.com/en/pull-requests/reference/pull-request-reviews\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Pull request reviews</a> — значения Comment, Approve и Request changes.</li><li><a href=\"https://git-scm.com/docs/git-blame\" target=\"_blank\" rel=\"noopener noreferrer\">Git documentation: git-blame</a> — назначение команды для поиска revision и автора строк.</li></ul>"
}