Привет Performance lovers!

Знаете ли вы что в мире есть 100 млрд типов людей:
1️⃣ Хранят тесты в отдельном репозитории
2️⃣ Хранят тесты вместе с сервисом

Я был человеком типа 1️⃣, а стал 2️⃣. Все круто, но если сделать правку в самой свежей версии, например, поправить параметры приложения на тестовом стенде, то автоматически эти изменения в предыдущие ветки (релизы) не добавятся

И вот тесты в ветке develop (все последние изменения и продукта и тестов) проходят ✅ отлично, а в ветке release-2026.2 (релизный проект и чуть более старые тесты) изменения не дошли ❗️ нужно еще сделать 🍒 cherry-pick

🎚 Убедиться, что версии актуальны

git fetch origin

🎚 Сделать ветку на базе стабильной ветки (release-2026.2):

git checkout -b fix-perf-tests-2026.2 --no-track origin/release-2026.2

❓ Тут может быть скрытая угроза, когда внешней веткой для локальной fix-perf-tests-2026.2 станет не origin/fix-perf-tests-2026.2, а origin/release-2026.2. И вы очень не хотели бы случайно разломать релиз. Чтобы такой привязки не происходило добавлен флаг --no-track. В целом он не особо нужен для создания веток, но тут он для перестраховки


🍒 Перенести нужный коммит

git cherry-pick -x 89006ee2

Тут могут возникнуть конфликты, например, вы там меняли .gitignore и этот файл .gitignore также был изменен кем-то кто обновлял релизную ветку. У меня получилось, что конфликты в моих же файлах — я их правил

Без 💻 IDEA бы с трудом разбирался в консоли, как верно сделать git cherry-pick --continue — а тут есть удобный диалог. IDEA очень помогает

Можно нажимать Accept Yours (первую кнопку) почти всегда, но бывает интересно нажать Merge ... и посмотреть на изменения еще раз

🎚 Проверить, что все прошло хорошо

git log -n 1
git diff HEAD~1 HEAD --name-only

Что только тесты были перенесены, а не что-то лишнее.

🎚 А потом опубликовать ветку и сделать мерж:

git push -u origin fix-perf-tests-2026.2

❓ Тут для перестраховки явно добавлен флаг -u чтобы в origin точно создалась ветка origin/fix-perf-tests-2026.2, при настройках git по умолчанию такое не требуется, но при некоторых настройках просто git push origin мог бы попробовать залить все сразу в release-2026.2 (смотри предыдущий ❓), это почти никогда не возможно — но тут у нас двойная перестраховка от такого случая

Много плюсов от размещения тестов вместе с проектом, но есть вот такие 🎚 5-7 шагов. В которых есть ❓ нюансы еще.

Может быть вы из тех счастливых людей, что не хранят тесты в репозитории или не пишите их совсем. Но раз вы дочитали до этой строки, то буду надеяться на полезность этой заметки 😊