Как вы работаете с Git и деплоем, какие команды используете

Что проверяют

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

Как отвечать

Покажите команды через свои задачи:

• ветка с доработкой: git fetch, затем git switch feature/PAY-123, для своей ветки автотестов git switch -c. Команды switch и restore появились в Git 2.23 и нагляднее старого checkout;
• что изменилось: git log --oneline main..feature/PAY-123 и git diff main...feature/PAY-123 очерчивают зону регресса до начала тестирования;
• поиск регрессии: git bisect start, отметить good и bad, дальше Git делит историю пополам, а через git bisect run можно гонять автотест;
• репозиторий автотестов: git add -p, git stash при переключении задач, git rebase main перед merge request, git push --force-with-lease вместо --force;
• отмена: git revert создаёт новый коммит и безопасен для общей ветки, git reset переписывает историю и годится только локально.

Про деплой. Обычно QA не выкатывает на прод, а запускает пайплайн на тестовый стенд: ручная джоба в GitLab CI, параметризованная сборка в Jenkins с выбором ветки. После выкатки сверяете версию: хеш коммита в эндпоинте /version или тег образа. Для диагностики пригодятся kubectl get pods, kubectl logs, kubectl describe pod, kubectl rollout status, локальное окружение поднимает docker compose up -d.

Назовите, что из этого делали сами. Если с Kubernetes не работали, скажите, чем смотрели логи.

Где спотыкаются

Перечисляют git init, add, commit без контекста. Для QA ценнее bisect и сравнение веток, чем пересказ учебника.

Тестируют, не проверив сборку на стенде, и полдня разбирают баг, которого в нужной версии уже нет.

Делают git push --force в общую ветку и затирают чужие коммиты. --force-with-lease откажет, если на сервере появилось что-то новое.