Git для тестировщика: шпаргалка

Перед прогоном фикса запиши ветку и коммит. Иначе баг «не воспроизводится» окажется проверкой не той сборки. Запоминай и пользуйся!

Канал: QA❤️4Life
Автор: Евгений Гусинец

1. Снять ту версию, которую проверяешь

git clone <url> забирает репозиторий в первый раз. Дальше репозиторий уже есть, 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, токенов и дампов с людьми.

6. Вопросы с собеседований

Чем fetch отличается от pull? git fetch только скачивает сведения о ветках. Файлы, которые ты проверяешь, не меняются. git pull ещё и вливает удалённую ветку в текущую. Для теста фикса нужен switch на ветку тикета, не один fetch.

Почему в баге нужен хеш коммита, а не имя ветки? Ветку двигают новыми коммитами. Имя остаётся, содержимое нет. Хеш фиксирует сборку, на которой поймал дефект.

Что делать, если pull ругается на локальные изменения? Смотри git status. Не связанные с задачей правки убирай в git stash, обновляй ветку, возвращай git stash pop и разбирай конфликт по строкам.

Источник: Chacon S., Straub B. Pro Git, 2nd ed. Главы про основы, ветки и работу с удалённым репозиторием.