Письмо от Michael Forbes (2026-04-30, 19:37)

От: Michael Forbes (he/him), Solutions Architect, Division of Information Technology — Stevens IT Кому: Holubets Andrii (Contractor), Napper, Tom + ещё 2 Копия: Vincent, Bemin + ещё 1 Дата: четверг, 30 апреля 2026, 19:37 Скриншот:

Полный текст

Hi Andrii,

Here is an example of the type of squashing or rebasing (or something along those lines) that happened 2 hours ago: https://bitbucket.org/stevens_edu/stevens_main_nextjs/pull-requests/846/commits

Typically that list of commits would have at least one commit (more is also fine) each time a change is made in response to a PR comment, so that a reviewer could just look at the changes. But in this PR we reviewed the initial offering, a small change was made that we would have a quick glance at by looking in that list, except that instead the list has just 1 monolithic commit that combines all of the already-reviewed code with the small thing that changed. This means the next code review takes a very long time instead of being quick turnaround. It also prevents pulling the changes into an existing local checkout without first deleting the local branch, when shared history is rewritten.

Thanks for your help on this so we can get through approvals much more rapidly!

Michael Forbes (he/him) Solutions Architect Division of Information Technology

Что это значит

🚨 Это эскалация — второе письмо от клиента менее чем через сутки после письма Alexis (29.04, 22:28 → 30.04, 19:37 ≈ 21 час).

Что нового

1. Конкретный пример — Michael показывает PR #846 (тот самый header) как живую иллюстрацию проблемы squashing/rebase, о которой Alexis написал абстрактно.
2. "2 hours ago" — то есть Иван сегодня (30.04) сделал squash/rebase на расшаренной ветке PR #846. Это уже после письма Alexis от 29.04. Сигнал получен — поведение продолжилось.
3. Конкретная техническая боль ревьюера:
   • "next code review takes a very long time" — ревьюер не может посмотреть только дельту изменений.
   • "prevents pulling the changes into an existing local checkout without first deleting the local branch" — реальный практический блок: Michael не может pull-нуть, надо удалять ветку и заново checkout.
   • "shared history is rewritten" — это технический термин: история коммитов на расшаренной ветке переписана force-push'ем.

Почему это важно для встречи

• Письмо Alexis было общим тезисом — Michael дал конкретный пример прямо сейчас.
• Этот пример противоречит возможной защите "это было до письма" — squash случился через сутки после письма.
• Адресат: Андрей напрямую (контрактор-менеджер), в копии Tom (iX-заказчик) и Anton (тимлид). То есть эскалация и в нашу управленческую цепочку, и в клиентскую.
• Тон вежливый ("Thanks for your help") — не угроза, но прямое указание: "сделайте чтобы это не повторялось".

Связь с PR #846 / PR #847

• На PR #846 ровно сегодня случилось то, что Michael описал. На встрече с Иваном — спросить:
  • Какой именно коммит/действие 30.04 вызвал переписывание истории?
  • Это был squash локальных коммитов перед push? Force-push? Rebase на master?
  • Что именно Иван хотел этим достичь?
• Расширяет тему PR #847 (где squashing уже был замечен) — теперь это подтверждённый паттерн через 2 PR'а.

Что нужно ответить (черновик позиции)

1. Подтвердить получение, не оправдываться.
2. Конкретно по этому случаю — что именно произошло на PR #846 30.04 (понять ДО ответа).
3. Заявить процессное изменение: не делать force-push / не переписывать историю на расшаренных PR-ветках. Изменения в ответ на ревью — отдельные коммиты, потом merge commit.
4. Подтвердить встречу 5.05 — этот кейс будет в повестке.

Список приёмников / эскалация

Имя	Роль	Канал
Andrii Holubets	Контрактор-менеджер (мы)	TO
Tom Napper	iX (наш заказчик)	TO
(+2 в TO)	Не идентифицированы — уточнить	TO
Vincent	Stevens IT	CC
Bemin	Stevens IT (Bemin Shaker — ревьюер)	CC
(+1 в CC)	Не идентифицирован	CC

⚠️ Идентифицировать оставшихся получателей — это важно для понимания уровня эскалации.