Семь раз отмерь, один раз git push

Это классическая грустная история одного факапа. Вы безусловно её оцените, если когда-нибудь работали с гитом, мержили ветки и имеете представление о слиянии fast-forward.

Перед тем, как перейти к непосредственно к факапу, который едва не погубил одну очень важную ветку, позвольте рассказать вам о том воркфлоу, который использовался на этом прекрасном проекте.

О, если бы это был какой-нибудь классический git flow! Увы, но это был не он.
Проект жил в двух окружениях: продакшен и демо. Прод проекта собирался из мастер-ветки, а демо проекта — из ветки demo-branch. На демо-стенд выкладывали все задачи для их тестирования перед загрузкой на прод, а ещё скидывали всё, что попадается под руку: черновики, тестовые обновления, эксперименты с настройками проекта... В общем, демо представляло из себя версию прода в горячечном бреду. Поэтому существовало очень гласное правило: никаких подливаний demo-branch в другие ветки, особенно в мастер, чтобы какая-нибудь незарелизенная приколюха не просочилась в продакшен-среду.

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

Одному инженеру понадобилось что-то починить в настройках проекта на демо-стенде. Он отколол себе ветку hotfix от demo-branch («чинить-то надо демо, значит от него и откалываемся» — объяснял он мне потом), что-то там настроил, влил ветку обратно в demo-branch, проверил — на демо всё работает. Ура!

Дело за малым — нужно обновить те же самые настройки на проде. Нет, инженер не слил demo-branch с мастером, всё нормально. Он сделал то, что должен был: взял свою рабочую ветку hotfix, создал пул-реквест в мастер и отправил его мне на проверку.

Я, не подозревая ничего худого, переключился на мастер и выполнил две команды, которые стали роковыми:

git merge new-branch
git push

В этом слиянии слились не только ветки, но и два критических обстоятельства:

1. Ветка hotfix была отколота не от мастера, а от demo-branch.
2. Накануне в мастер-ветку и в demo-branch был подлит один и тот же коммит.

В итоге ветка hotfix успешно влилась в мастер, подтянув за собой в качестве приданного всю историю коммитов из demo-branch, так как была её дочкой.
А из-за того, что последние коммиты в мастере и demo-branch совпадали, гит решил, что он возвращает ветку родителю, поэтому выполнил простое fast-forward слияние, при котором указатель мастера просто переместился на последний коммит из hotfix, заодно встроив в историю ветки все коммиты из demo-branch.

Когда я всё осознал, было уже слишком поздно. «Да что ты, просто отмени мерж,» — скажете мне вы. Я так и хотел сделать. Но fast-forward слияние нельзя отменить. Точнее, в таком слиянии просто нечего отменять. При Fast-forward не создаётся merge-коммит, который является артефактом слияния, поэтому откатить этот процесс невозможно. Можно только отменить отдельные коммиты, которые подтянулись из сливаемой ветки.

В нашем случае таких коммитов оказалось несколько десятков, и они равномерно распределились по всей истории: demo-branch срослась с мастером как несчастные полярники под влиянием пришельца-мимикриста из фильма «Нечто».

Выискивать демо-коммиты и ревертить их оказалось делом почти безнадёжным. Поэтому я решил проблему радикально. Хвала архитекторам, в этом репозитории находилась лишь часть проекта с основными настройками, я просто вручную вернул конфигам их первозданный вид и обновил мастер-ветку.

Мир был спасён, опасность миновала. Но ситуация от этого не переставала быть страшной. Совершенно необходимо было принять какие-то меры, чтобы это больше не повторилось.

И меры были приняты:

git config merge.ff false

Этой командой я запретил fast-forward слияния в своём репозитории с тем, чтобы всегда, ВСЕГДА создавался коммит слияния. Теперь в случае очередного факапа я смогу хотя бы отменить мерж и избежать ужасных нечто-монстров.

И конечно, я сделал для себя главный вывод. Прошло уже несколько лет, а я до сих пор использую его в качестве своего гит-кредо: семь раз отмерь, потом отмерь ещё семь раз, потом подумай, а уже потом отправляй изменения на сервер!

#практика

Привет! 26 февраля в Москве состоится вторая конференция WriteConf, которая объединяет всех пишущих специалистов в айти: редакторов, технических и ux-писателей, контент-мейкеров, SMM и маркетологов. Будет чисто наша писательская тусовка и много полезной информации по коммуникациям, текстам, инструментам и практикам работы. Много реального опыта и практических кейсов. Крутые спикеры прилагаются)

Билеты можно приобрести по ссылке, а подробности узнать в официальных каналах в телеге и вк.

Приходите, будет интересно!

P.S. Я тоже буду выступать: на личном примере расскажу о том, как организовать большую систему документирования с небольшими затратами. Надеюсь, увидимся)

#карьера

Неожиданно получил премию канала Техписалити! за «Docs as code для самых маленьких».

Спасибо) Я рад, что этот курс до сих пор помогает людям разобраться в основах подхода «документация как код». Разумеется, я и не представить не мог, что он станет популярным: я делал его, чтобы систематизировать свои знания и составить базовый онбординг на случай, когда всё позабуду))

Честно, я и канал создал для того, чтобы победить прокрастинацию и начать глубже погружаться в профессию технического писателя. Девизом парарайтера могли бы стать слова Вовки из Тридевятого царства: «Ну-ка, поглядим, как тут избы делают?»

Поэтому очень круто, что контент парарайтера находит своего благодарного читателя и реально помогает найти ответы на некоторые профессиональные вопросы.

А ещё я хочу поблагодарить Стаса Рычкова. Стас, спасибо тебе большое за то, что в 2022 году ты откликнулся и помог мне настроить мой первый самостоятельный docs-as-code проект на vitepress.
И спасибо всему русскоязычному сообществу технических писателей за отзывчивость, открытость и готовность делиться опытом с товарищами по профессии!

#карьера