Обычно я пишу SQL-запросы, формулирую требования и помогаю команде превращать хотелки бизнеса в рабочие решения. Но бывают дни, когда приходится переключаться в другой режим — почти разработчика. И вот один из таких кейсов. Он о Git, багах и роли аналитика, которая оказывается шире, чем может показаться.
Всё началось с бага
🛠️ Один из SQL-отчётов, над которым я работал, не попал в релиз. Об этом сообщил руководитель поддержки, после того как заказчик заметил баг.
Нужно было срочно исправить ситуацию — вручную доставить нужные изменения.
Казалось бы, просто. Но нет
Если ты хоть раз сталкивался с такими фразами:
«нужно отбранчеваться от релизной ветки, сделать cherry-pick, закоммитить и запушить»
…то ты знаешь, что это не просто. Это звучит как заклинание из чёрной магии, особенно если ты не разработчик.
Что такое cherry-pick?
🔁 git cherry-pick — это команда, которая позволяет выборочно взять изменения из одного коммита (например, из ветки develop) и применить их в другой ветке (например, release). Это не слияние всей ветки, а точечное применение нужного куска кода.
Очень удобно, если ты хочешь подлить конкретный фикс без риска затащить лишние изменения.
Как всё прошло
- 🧠 Старший разработчик объяснил, что нужно делать.
- 🧩 Тимлид помог собрать все команды и проверить результат.
- 🧑💻 Я создал ветку от релиза, сделал cherry-pick, закоммитил, запушил и успешно закрыл баг.
А должен ли аналитик это делать?
Хороший вопрос. И ответ — неоднозначный.
Старший разработчик честно сказал:
«Такие задачи лучше не давать джунам и аналитикам — это devops-история».
И я с ним согласен. Но реальность такова, что в небольших командах часто приходится выходить за рамки роли. Особенно если ты уже немного умеешь кодить и понимаешь, как работает инфраструктура.
Что я вынес из этой ситуации
✅ Научился применять cherry-pick в реальной задаче
✅ Разобрался, как устроен релизный процесс
✅ Убедился, насколько важны чёткие коммиты — они спасают время и нервы
✅ Почувствовал, как важно, чтобы команды взаимодействовали, а не «перекидывали» задачи по ролям
Совет аналитикам:
Хоть вы и не обязаны знать Git на уровне медла-разработчика, базовые вещи стоит освоить:
- как создаются ветки (git checkout -b)
- как искать нужные коммиты (git log)
- как подливать изменения (git cherry-pick)
- как пушить (git push)
📌 Это не сделает вас девопсом. Но поможет выручить команду, когда на кону стабильность продукта — и доверие заказчика.
А что ты думаешь?
❓ Приходилось ли тебе выходить за рамки своей роли?
❓ Или сталкиваться с ситуацией, когда приходится “спасать релиз”?
👇 Напиши в комментариях — будет интересно обсудить, где заканчивается зона ответственности аналитика и начинается командная солидарность.
📎 Хочешь больше таких кейсов?
Подписывайся на канал — здесь без глянца, про настоящую работу в IT, системный анализ и немного котиков.
🔗 Ранее писал про Git и его подводные камни: