Comments 23
Релизный цикл непонятный, проблемы непонятные, что происходит - лучше не знать. Ужас какой.
UPD: так и не понял, почему сброс ветки до создания результирующей был в принципе выполнен. Все изменения можно сделать локально, без форс пуша. И только потом, когда локально всё точно хорошо - сделать пуш.
А в целом почему форс пуш релизной ветки был посчитан хорошей идеей - даже думать не хочу.
UPD2: гугл говорит, что в гитлабе можно восстановить ветку, см https://stackoverflow.com/a/69763946
"Мне интересно — как бы вы поступили в такой ситуации? "
1. Делал бы бекапы Git-а. Тогда можно было бы откатиться на ночной бэкап, потеряв дельту данных за утро.
2. Делал бы снапшот виртуалки с git перед любыми серьёзными изменениями.
3. Перестал бы использовать команду git reset --hard и навёл бы порядок с ветками в Git. Если у вас ещё не стабильный EPIC, то что он делает в ветке мастер (Prod), а не в ветке dev (DEV). В прод должны попадать только стабильные изменения. Также почитал бы, что такое включение функционала через флаги, тогда нестабильный EPIC был бы спрятан от пользователей и никак на них не влиял, пока бы этот EPIC не довели до стабильного состояния и не включили этот функционал специальным флагом.
4. Слушал бы, что говорят старшие товарищи и почему именно тимлид, попросил тебя не лезть в релиз.
Спасибо, что так подробно расписал.
Много здравых мыслей, особенно про фичефлаги и стабильность изменений в релизных ветках — это как раз те моменты, которые хотелось бы довести до ума.
Согласен, что подход с dev → master и более чистой изоляцией эпиков с флагами — то, к чему надо стремиться, особенно если хочешь безопасных релизов.
Отдельное спасибо за мысль про снапшоты и бэкапы Git — мы как раз обсуждаем сейчас, как улучшить процессы на случай таких вот сбоев.
Про «слушать старших товарищей» — тоже услышал, без сарказма. Ошибся, сделал выводы.
Тимлид ушёл в отпуск
и сразу всё сломалось? под кем-то, явно, горит стул.
В ситуации, как у автора, git reflog (для HEAD) или git reflog BRANCH_NAME позволяют восстановить гораздо быстрее и удобнее, чем описано в статье.
reflog — работает не только в рамках какой-то ветки, но в рамках всех веток, в том числе HEAD,которая, конечно же, была на нужном commit-е перед тем, как был сделан git reset --hard.
Надо было найти запись перед той, на которую встал HEAD после --reset, и остальная часть статьи просто не понадобилась бы.
Я вообще никогда не использую reset --hard. Если надо откатить локальные изменения, то использую git checkout + git clean -f. Если нужно стянуть ветку, которую удалённо ребэйсили, то надо свою локальную удалить, а удалённую стянуть через fetch. Про reset --hard я почему-то всегда слышу только в контексте стрёмных историй вроде тех, что случилась у автора.
git reset --hard - вполне рабочая команда. Но да прежде чем ее делать нужно четко понимать что именно ты хочешь сделать.... собственно так со многими командами в гите.
Сам тоже умудрялся "намудриь" в гите и пушнуть с форсом, но у меня хотя бы все коммиты локально были и git reflog спас. А так то да, автор, явно где-то поторопился..... бывает и на старуху проруха, что уж там... Я после последнего своего факапа стараюсь отставлять бекапные ветки, когда в гите всякие неоднозначные манипуляции делаю типа сквошей, ребейзов и ресетов. Удалить то их потом, когда все сделал и убедился, что все получилось как надо - не сложно.
Спасибо, за понимающий комментарий. Да, reset --hard — не зло само по себе, просто требует осторожности и ясной головы.
В моём случае как раз её не хватило :) Поторопился, не оставил ни бэкапной ветки, ни чёткого плана отката — и вот результат.
Теперь точно буду аккуратнее и заведу привычку перед неоднозначными действиями делать временные ветки.
Кажется, я как раз стал очередной стрёмной историей про reset --hard 😅
Спасибо, что поделился своим способом — звучит надёжно, буду пробовать.
Я может не понял , но как выше писали - многовато движений.
https://stackoverflow.com/questions/5473/how-can-i-undo-git-reset-hard-head1
P.S. Полагаю когда мастер будут тянуть люди - ещё вспомнят этот релиз.
Формулировка "релиз на мне" говорит о слабой автоматизации и недостатке формализованных процессов. В зрелых DevOps-командах релиз ― это нажатие кнопки через CI/CD-процессы, а не ручная работа одного человека. Если кто-то год не релизил и процесс всё ещё сложен или слабо документирован, значит, и команда, и практики DevOps нуждаются в пересмотре. Лучше использовать trunk-based development вместо git flow или github flow, поскольку trunk-based development упрощает процессы интеграции, ускоряет выпуск изменений и снижает риски, связанные с долгоживущими ветками. Решение ― автоматизация релизов, актуализация документации и работа по trunk-based development: тогда роль отдельного человека исчезнет сама собой.
Спасибо за развёрнутый комментарий — многое резонирует.
Мы как раз сейчас подходим к переосмыслению процессов, и то, что всё держится на одном человеке (в данном случае — на мне), уже само по себе звоночек.
До trunk-based пока не дошли, но кажется, пора двигаться в эту сторону.
Зафиксировал для себя: автоматизация, актуальная дока, меньше ручного — чтобы следующий релиз не превращался в спецоперацию.
Git хранит все коммиты даже после хард-ресета (как минимум некоторое время), можно было из них обратно ветки собрать. reflog уже упоминали.
Документировать релизный процесс, чтобы не только тим-лид мог релизить и не приходилось импровизировать
master и release ветки сделать protected, force-push в любую ветку, которой пользуются больше одного человека - зло. Если нужно пересобрать релиз-ветку заново, то делать новую релиз-ветку или ревертить коммиты.
Полюбить фича-флаги
Гит ничего не удаляет, так что даже reset откатывается одной командой. И даже удаленные слитые ветки легко восстановить, так как гитлаб или гитхаб хранят полную историю, достаточно просто скопировать нужный хеш.
Сложилось впечатление, что вы не осознаете что коммиты в гите это не дифы а полные снапшоты состояний проекта.
А у вас разве можно релизить ветку, которую только что собрали из непонятно чего и даже не протестировали? Удивительные процессы ))
По делу пишете. С reflog и восстановлением веток — действительно всё проще, чем казалось в моменте. Тогда просто не хватило понимания, да и в голове была каша.
Что касается релиза — да, ветка действительно собиралась в спешке, и это, пожалуй, главный звоночек. Пока у нас процессы скорее стихийные, чем надёжные. Надеюсь, этот случай подтолкнёт к тому, чтобы выстроить их более осмысленно.
Ну а по поводу "удивительных процессов" — согласен, местами удивлён был даже сам 😅
Кто ж блин делает МРы НЕ в мастер? Сами себе в ноги настреляли
Уроки Git-хаоса: форс-ресет, удалённые ветки и GitLab