Инцидент: плохой merge

Сначала диагностика: найди точный коммит, сломавший main. Не угадывай — читай граф. Merge-коммит — это тот, у которого два родителя, стоящий там, где main покраснел:

git fetch origin
git log --graph --oneline --decorate origin/main | head -30
git show <merge-sha>          # увидеть, что смёржено, и линию родителей

git show на merge печатает объединённый diff и, что важно, список родителей (Merge: a1b2c3 d4e5f6). Первый родитель — это ветка, на которой ты был в момент merge, — main, а второй — фичеветка, которую подтянули. Этот порядок родителей и есть то, от чего зависит revert на шаге 3.

Выбирай инструмент по одному вопросу: эта история запушена и общая? Это всё дерево решений, и оно бинарно:

• Общая / уже запушена (плохой merge на origin/main): нужно дописать исправление, никогда не переписывать. Используй git revert.
• Только локальная (merge есть лишь на твоей машине, никогда не пушился): можно переписывать свободно. git reset --hard <до-merge> нормально.

В командном инциденте ответ почти всегда «общая», потому что merge на origin/main и коллеги его уже стянули. Переписывание через reset + force-push стёрло бы коммиты, на которых теперь строят другие, и рассинхронизировало бы каждый клон. Revert оставляет плохой merge в истории и кладёт новый коммит, отменяющий его эффект.

Откати merge через -m 1, чтобы назвать магистрального родителя. У merge два родителя, поэтому git revert не может знать, какая сторона — «изменение для отмены», — ты должен сказать ему через -m (mainline). -m 1 значит «оставить первого родителя (main) базой и отменить всё, что принёс второй родитель»:

git revert -m 1 <merge-sha>
git push origin main          # обычный push: revert — новый коммит, без force

Это дописывает один новый коммит, вычитающий изменения фичи. main снова зелёный, полная история сохранена, и ничей клон не инвалидирован. Выбор не того mainline (-m 2) отменил бы собственную работу main — так что сначала подтверди порядок родителей с шага 1.

Если force-push стёр коммиты, восстанови их через reflog — страховку для общих катастроф. Допустим, кто-то «починил» инцидент, сделав force-push и стерев хорошие коммиты с main. Эти коммиты не пропали; они без ссылок, и reflog всё ещё называет их на любой машине, где они были:

git reflog                    # локально: каждая позиция, что держал HEAD, с sha
git reflog show origin/main   # на что remote-tracking ref указывал во времени
git branch rescue <good-sha>  # заякорить потерянные коммиты на настоящую ветку

Reflog локален для каждого клона, поэтому восстановление часто происходит на клоне коллеги (или в reflog самого сервера / git fsck --lost-found), который всё ещё держит верхушку до force-push. Найди там последний хороший SHA, заведи ветку, запушь — и потерянная работа вернулась. Reflog — это причина, по которой «я сделал force-push поверх хорошей работы» восстановимо, а не фатально.

Сообщи команде, затем влей починку чисто. Техническое восстановление — половина дела. Напиши в канал инцидента, что случилось, что ты откатил, и что main зелёный. Затем верни фичу правильно: ветка от свежего main, revert-the-revert или rebase исходной работы на него, почини настоящий дефект, прогони CI до зелёного и влей через обычный отревьюенный PR. Инцидент кончается не когда main снова собирается, а когда фича влита корректно и команда знает последовательность.