📚 Git для тестировщика
Перед прогоном фикса запиши ветку и коммит. Иначе баг «не воспроизводится» окажется проверкой не той сборки.
1. Снять ту версию, которую проверяешь
git clone забирает репозиторий в первый раз. Дальше репозиторий уже есть, clone не повторяют.
git fetch origin обновляет сведения о ветках на сервере и не меняет твои файлы. После fetch ты всё ещё на старой ветке. Зелёный прогон в этот момент не про фикс из тикета.
git switch bugfix/123 ставит рабочую копию на ветку из задачи. Если ветка есть только на сервере: git switch -c bugfix/123 origin/bugfix/123.
git status показывает имя ветки и чужие незакоммиченные файлы. Грязное дерево значит, что часть проверки идёт по локальным правкам, не по сборке команды.
git log -1 --oneline даёт короткий хеш. Его пишут в баг и в отчёт о прогоне. Через день ветку переместят, и без хеша спор нечем закрыть.
2. Своя ветка, если добавляешь проверку
Фикс из тикета не коммить в main и не дописывай чужим коммитом в чужую ветку, если команда этого не просила.
git switch -c test/bug-123 открывает ветку под регресс или фикстуру.
git add tests/bug_123.py берёт в коммит только нужный файл. git add . легко захватит .env, дамп базы и скрин с персональными данными.
git commit -m "add regression for bug-123" и git push -u origin test/bug-123 публикуют ветку. Секрет в коммите остаётся в истории. Его уже могли увидеть, даже если файл потом удалить.
3. Pull request: что писать тестировщику
Описание PR отвечает на три вопроса, без воды.
Что проверено: регресс на баг-123, ветка bugfix/123, коммит abc1234.
Как проверить: логин, профиль, смена аватара. Шаги такие, чтобы второй человек повторил их без созвона.
Что не трогал: биллинг, оплата, письма. Если не смотрел, так и напиши.
Конфликт с main: git fetch origin, затем git merge origin/main. Правь только помеченные строки. Не принимай целиком ни свою, ни чужую сторону, пока не прочитаешь обе. После мержа сценарий прогоняют заново: конфликт легко собирает рабочий код с неверным правилом.
git pull на грязном дереве часто встаёт. Сначала git status. Чужие локальные правки убирают в git stash, потом pull, потом git stash pop. Если pop снова дал конфликт, это те же помеченные строки, не новая магия.
4. Грабли
Проверил main, а фикс лежит в ветке тикета. Статус задачи «готово к тесту» ещё не значит, что локальный main уже содержит коммит.
git pull без git fetch и без взгляда на ветку обновляет текущую ветку, не ту, что в тикете.
Force-push в общую ветку затирает чужой фикс. Если попросили переписать историю, это решают в чате. Самому так не делают.
Ветка моя_ветка_тест через неделю ни о чём не говорит. Имя: test/bug-123 или как принято в репозитории.
5. Чек-лист перед прогоном
• Ветка совпадает с тикетом, это видно в git status.
• Хеш из git log -1 --oneline записан в отчёт.
• Дерево чистое, кроме файлов, которые сам добавил для проверки.
• В PR есть шаги, хеш и честная пометка, что не смотрел.
• В коммите нет .env, токенов и дампов с людьми.
Полная шпаргалка на Telegraph
━━━━━━━━━━━━━━━━━━━━
📢 QA❤️4Life — канал о тестировании
🤖 SyntxAI — все самые нужные нейросети в одном сервисе
🔒 MaxVpn — Удобный и быстрый VPN
🧠 Google AI Pro — подписка на личный Google-аккаунт на 18 месяцев за 990₽
━━━━━━━━━━━━━━━━━━━━
👑 Авторский курс по созданию персональных ИИ-агентов
#QA #Тестирование #Git #Шпаргалка
Перед прогоном фикса запиши ветку и коммит. Иначе баг «не воспроизводится» окажется проверкой не той сборки.
1. Снять ту версию, которую проверяешь
git clone забирает репозиторий в первый раз. Дальше репозиторий уже есть, clone не повторяют.
git fetch origin обновляет сведения о ветках на сервере и не меняет твои файлы. После fetch ты всё ещё на старой ветке. Зелёный прогон в этот момент не про фикс из тикета.
git switch bugfix/123 ставит рабочую копию на ветку из задачи. Если ветка есть только на сервере: git switch -c bugfix/123 origin/bugfix/123.
git status показывает имя ветки и чужие незакоммиченные файлы. Грязное дерево значит, что часть проверки идёт по локальным правкам, не по сборке команды.
git log -1 --oneline даёт короткий хеш. Его пишут в баг и в отчёт о прогоне. Через день ветку переместят, и без хеша спор нечем закрыть.
2. Своя ветка, если добавляешь проверку
Фикс из тикета не коммить в main и не дописывай чужим коммитом в чужую ветку, если команда этого не просила.
git switch -c test/bug-123 открывает ветку под регресс или фикстуру.
git add tests/bug_123.py берёт в коммит только нужный файл. git add . легко захватит .env, дамп базы и скрин с персональными данными.
git commit -m "add regression for bug-123" и git push -u origin test/bug-123 публикуют ветку. Секрет в коммите остаётся в истории. Его уже могли увидеть, даже если файл потом удалить.
3. Pull request: что писать тестировщику
Описание PR отвечает на три вопроса, без воды.
Что проверено: регресс на баг-123, ветка bugfix/123, коммит abc1234.
Как проверить: логин, профиль, смена аватара. Шаги такие, чтобы второй человек повторил их без созвона.
Что не трогал: биллинг, оплата, письма. Если не смотрел, так и напиши.
Конфликт с main: git fetch origin, затем git merge origin/main. Правь только помеченные строки. Не принимай целиком ни свою, ни чужую сторону, пока не прочитаешь обе. После мержа сценарий прогоняют заново: конфликт легко собирает рабочий код с неверным правилом.
git pull на грязном дереве часто встаёт. Сначала git status. Чужие локальные правки убирают в git stash, потом pull, потом git stash pop. Если pop снова дал конфликт, это те же помеченные строки, не новая магия.
4. Грабли
Проверил main, а фикс лежит в ветке тикета. Статус задачи «готово к тесту» ещё не значит, что локальный main уже содержит коммит.
git pull без git fetch и без взгляда на ветку обновляет текущую ветку, не ту, что в тикете.
Force-push в общую ветку затирает чужой фикс. Если попросили переписать историю, это решают в чате. Самому так не делают.
Ветка моя_ветка_тест через неделю ни о чём не говорит. Имя: test/bug-123 или как принято в репозитории.
5. Чек-лист перед прогоном
• Ветка совпадает с тикетом, это видно в git status.
• Хеш из git log -1 --oneline записан в отчёт.
• Дерево чистое, кроме файлов, которые сам добавил для проверки.
• В PR есть шаги, хеш и честная пометка, что не смотрел.
• В коммите нет .env, токенов и дампов с людьми.
Полная шпаргалка на Telegraph
━━━━━━━━━━━━━━━━━━━━
📢 QA❤️4Life — канал о тестировании
🤖 SyntxAI — все самые нужные нейросети в одном сервисе
🔒 MaxVpn — Удобный и быстрый VPN
🧠 Google AI Pro — подписка на личный Google-аккаунт на 18 месяцев за 990₽
━━━━━━━━━━━━━━━━━━━━
👑 Авторский курс по созданию персональных ИИ-агентов
#QA #Тестирование #Git #Шпаргалка