PR #847 — hotfix для FAQPage schema (по следам PR #837)

Ссылка: https://bitbucket.org/stevens_edu/stevens_main_nextjs/pull-requests/847 Связан с: PR #837 (ICUS-216 — Add FAQPageJsonLd for accordion, merged 2026-03-24) Branch: ICUS-216-faq (тот же, что использовался для PR #837 — переиспользован для hotfix) Parent / спека: ICUS-214 (см. PR #837 spec/)

Особый вес PR #847

PR #847 прямо упомянут в письме Alexis Watson (29.04) как пример проблемы со squashing:

"On other occasions, such as PR #847, the use of commit squashing (consolidating a batch of changes into one big change by rewriting history) can make minor adjustments very difficult to parse out if the branch has already been shared. The lack of history means team has to review all of it once more to ensure nothing is missed, as opposed to focusing on what has changed."

→ Этот PR — главный артефакт второго тезиса письма ("avoid rebasing/squashing after code is shared").

Бизнес-контекст (предыстория hotfix'а)

Из обсуждения внутри iX (контекст, который дал Андрей):

PR #837 (merged 24.03) добавил FAQPageJsonLd per Accordion. Когда на странице несколько Accordion'ов — выходит несколько отдельных JSON-LD объектов FAQPage на одной URL.
Google Rich Results / Search Console считают это ошибкой ("duplicate FAQPage entity per URL").
Первая идея (Vincent / iX): merge всех Q&A в один большой FAQPage. Но архитектурно это сложно — каждый Accordion рендерится отдельным компонентом без знания о соседях.
Major shortcut от Michael Forbes (со ссылкой на StackOverflow):

"we will be compliant (no error in Google) even if we generate separate JSON-LD for each Accordion component as we currently do... if we just do one simple thing: add an @id property to each of the FAQPage objects, where its value is the same for each object (but different for each page). Simply using the URL path of the page as the @id value is a great solution."
Решение для PR #847: в каждый FAQPage JSON-LD добавляется @id = URL текущей страницы. Google трактует это как "несколько ссылок на одну сущность", дубликата нет.
Branch reuse: Michael прямо предложил не плодить ветки:

"I suggest that the existing ICUS-216-faq branch (which was the basis of PR 837) continue to be used for this hotfix, avoiding multiple branches for the same issue (multiple PRs for the same branch is no problem at all)."

Что это значит для разговора по squashing

Что Alexis написал в письме

"the use of commit squashing... can make minor adjustments very difficult to parse out if the branch has already been shared"

Что фактически произошло

Branch ICUS-216-faq была расшарена (был открыт и замержен PR #837 — то есть branch видна команде).
Та же branch переиспользована для PR #847 (по совету самого же Michael Forbes из iX).
Где-то в этом процессе произошёл squash, который "переписал историю" — Alexis это и заметила.

Возможные сценарии (надо уточнить у Ивана)

Squash при merge PR #837 — стандартный squash-merge через GitHub/Bitbucket UI; история на расшаренной ветке разрушается.
Squash/rebase в локальной ветке Ивана перед открытием PR #847 — Иван "почистил" историю перед публикацией.
Force-push в branch ICUS-216-faq поверх уже видимой истории.

→ Все три случая — нарушение принципа "не переписывать историю на расшаренных ветках". Какой именно сценарий — нужно посмотреть git log + reflog.

Структура папки

— скрины комментариев из PR
context/ — переписки/контекст (включая решение через @id)
— расшифровка
— итог

Статус

Контекст PR (hotfix для FAQPage @id)
Решение по @id зафиксировано
PR description Ивана разобран — aggregation как командное решение (Саша, менеджер, Иван); в PR — реализация и описание Ивана (лучше shortcut Michael)
⏳ Git-истории сейчас нет — у нас нет доступа к локальному репо Ивана. Будем смотреть на встрече с Иваном (завтра).
Сформировать финальную позицию по squashing после встречи

Что спросить у Ивана на завтрашней встрече (git-аспект)

Все эти вопросы требуют, чтобы Иван открыл свой локальный репо / Bitbucket UI на встрече:

Branch ICUS-216-faq: после merge PR #837 (24.03) — ветка сохранилась или была удалена и пересоздана?
PR #837 mergeStrategy: был ли squash-merge при закрытии (через UI / автоматом)?
Force-push'и: между PR #837 и PR #847 — были ли git push --force в ICUS-216-faq?
Локальный rebase/squash: делал ли rebase или squash в локальной ветке после того, как ветка уже была видимой ревьюерам?
Reflog: git reflog ICUS-216-faq — увидим, переписывалась ли история.
Коммиты сейчас: git log --oneline ICUS-216-faq — посмотрим текущее состояние и сравним со скринами PR #847.