Автоматизация тестирования без Git означает тесты которые работают только на твоей машине: без CI-пайплайна, без ревью кода, без возможности работать с разработчиками. Любая роль по автоматизации тестирования требует одного и того же воркфлоу: ответвился от main, написал тесты, запушил в GitHub, открыл пул реквест, CI запустил сьют автоматически. В этом гайде: 10 команд которые используешь ежедневно, ветковый воркфлоу принятый в большинстве команд и как подключить GitHub Actions к репозиторию с тестами.

Что делает Git

Git отслеживает изменения в файлах во времени. Каждое сохранённое изменение («коммит») записывается с описанием, временной меткой и именем автора. Видно полную историю каждого файла, можно вернуться в любое прошлое состояние и работать над изменениями не затрагивая основную кодовую базу до готовности.

Для QA-инженеров Git служит для сохранения тестовой работы, обмена ею с разработчиками и запуска в CI/CD. Без репозитория CI-пайплайна не существует.

Установка Git

Windows

Скачиваешь с git-scm.com и устанавливаешь. При установке выбираешь «Use Git from the command line and also from 3rd-party software».

Mac

В Терминале запускаешь xcode-select --install. Git включён.

Проверка

git --version
# git version 2.44.0

10 команд которые используешь в 90% случаев

Начальная настройка (один раз)

# Сказать Git кто ты
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Создание или клонирование репозитория

# Инициализировать новый репозиторий в текущей папке
git init

# Клонировать существующий репозиторий с GitHub
git clone https://github.com/username/repository-name.git

Большинство QA-инженеров чаще делают clone чем init: обычно подключаешься к существующему проекту.

Просмотр изменений

# Посмотреть какие файлы изменились
git status

# Посмотреть конкретные изменения в файлах
git diff

Запускай git status постоянно. Показывает точно где ты находишься.

Сохранение работы (основной воркфлоу)

# Добавить конкретные файлы в стейдж (список «готово к коммиту»)
git add tests/login.spec.ts
git add pages/LoginPage.ts

# Или добавить все изменённые файлы
git add .

# Закоммитить стейджированные изменения с сообщением
git commit -m "Add login test cases with negative scenarios"

Стейдж → коммит. Это цикл сохранения. Сообщение описывает что и зачем изменил.

Синхронизация с удалённым репозиторием (GitHub)

# Получить последние изменения с GitHub
git pull

# Отправить свои коммиты на GitHub
git push

Сначала pull, потом push. Всегда тяни перед пушем, чтобы избежать конфликтов.

Работа с фичами (ветки)

# Создать новую ветку и переключиться на неё
git checkout -b feature/add-login-tests

# Посмотреть все ветки
git branch

# Переключиться на существующую ветку
git checkout main

Полный воркфлоу обычного дня

Как выглядит работа с Git на практике в типичный день:

# 1. Начало дня: получаешь последние изменения
git pull

# 2. Создаёшь ветку для своей работы
git checkout -b test/payment-flow-automation

# 3. Пишешь тесты в VS Code
# ... (tests/payment.spec.ts создан/изменён)

# 4. Проверяешь что изменилось
git status
# On branch test/payment-flow-automation
# Changes not staged for commit:
#   modified:   tests/payment.spec.ts
# Untracked files:
#   pages/PaymentPage.ts

# 5. Добавляешь файлы в стейдж
git add tests/payment.spec.ts
git add pages/PaymentPage.ts

# 6. Коммитишь с понятным сообщением
git commit -m "Add payment flow tests: happy path and card decline scenarios"

# 7. Пушишь на GitHub
git push origin test/payment-flow-automation

# 8. Открываешь пул реквест на GitHub (в браузере)

GitHub: хостинг удалённого репозитория

GitHub хранит твой репозиторий онлайн. Основные действия на GitHub:

Создание репозитория

1. Идёшь на github.com → New repository

2. Даёшь название

3. Выбираешь Public или Private

4. Нажимаешь Create

Подключение локального репо к GitHub

# После создания репо на GitHub подключаешь локальную папку
git remote add origin https://github.com/yourusername/your-repo.git
git push -u origin main

Пул реквесты

Когда закончил работу в ветке, открываешь пул реквест на GitHub. Он показывает сделанные изменения, позволяет коллегам делать ревью и оставлять комментарии, и после апрува сливает изменения в основную ветку.

Для QA-инженеров в команде: тестовый код проходит тот же процесс ревью что и код разработчиков. Открываешь PR, получаешь ревью, мёрджишь.

Для портфолио: публичный репозиторий на GitHub служит стандартным способом показать работу работодателям. Что в него положить: Как создать QA-портфолио на GitHub, которое приносит офферы (Playwright).

.gitignore: что не отслеживать

Некоторые файлы не должны попадать в Git: результаты сборки, секреты, node_modules. Создаёшь файл .gitignore в корне репозитория:

# Зависимости Node (всегда игнорируются, устанавливаются через npm install)
node_modules/

# Результаты и отчёты тестов Playwright
test-results/
playwright-report/

# Файлы окружения которые могут содержать секреты
.env
.env.local

# Файлы ОС
.DS_Store
Thumbs.db

npm init playwright@latest создаёт .gitignore автоматически. Проверь что в нём перед первым коммитом.

Ветки: зачем они нужны QA

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

main               # стабильный, готовый к проду код
feature/add-search # новая фича в разработке
bugfix/login-error # исправление бага
test/checkout-flow # новый тест в написании

Паттерн принятый в большинстве команд:

1. Ветка main всегда стабильна

2. Все создают feature/test-ветки для своей работы

3. Работа ревьюится в пул реквестах

4. Одобренные изменения мёрджатся в main

5. CI/CD запускается автоматически когда изменения попадают в main

Как QA-инженер ты будешь создавать ветки для новых тест-сьютов, обновлений тестов и воспроизведения багов.

Конфликты слияния: что это и как решать

Конфликт слияния происходит когда два человека изменили одно и то же место в одном файле и Git не может объединить их автоматически.

<<<<<<< HEAD
await expect(page.getByText('Success')).toBeVisible();
=======
await expect(page.getByRole('alert')).toHaveText('Success');
>>>>>>> feature/update-assertions

Секция <<<<<<< HEAD: твоя версия. Секция >>>>>>> feature/update-assertions: входящая версия. Нужно выбрать одну (или объединить вручную), удалить маркеры конфликта и закоммитить.

Большинство конфликтов в тестовых репозиториях легко решаются. Чаще всего они возникают в общих файлах: playwright.config.ts или Page Object файлах которые трогают несколько человек.

Git log: история изменений

# Посмотреть последние коммиты
git log --oneline
# a3f2c1d Add payment tests
# b7e9a04 Fix login page locator after UI update
# c2d1f8e Add item creation test with validation scenarios

# Посмотреть изменения в конкретном коммите
git show a3f2c1d

# Посмотреть кто последним менял каждую строку файла
git blame tests/login.spec.ts

git log и git blame нужны когда надо понять почему тест написан именно так, или с какого коммита тест начал падать.

GitHub Actions: CI-пайплайн

Когда тесты в GitHub, GitHub Actions может запускать их автоматически при каждом пуше. Базовый воркфлоу:

# .github/workflows/playwright.yml
name: Playwright Tests
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test

Этот файл предлагает создать npm init playwright@latest. После добавления в репозиторий GitHub запускает тесты при каждом пуше и пул реквесте.

Шпаргалка по командам

# Настройка
git config --global user.name "Name"
git config --global user.email "email"

# Ежедневные
git status              # что изменилось
git pull                # получить последнее с удалённого
git add file.ts         # добавить файл в стейдж
git add .               # добавить все изменённые файлы
git commit -m "message" # сохранить стейджированные изменения
git push                # отправить на удалённый

# Ветки
git checkout -b branch-name   # создать и переключиться
git checkout main              # переключиться на main
git branch                     # список веток
git merge branch-name          # влить ветку в текущую

# История
git log --oneline              # последние коммиты
git diff                       # несохранённые изменения
git show commit-hash           # изменения в коммите

FAQ

Нужна командная строка или можно использовать GUI?

Оба варианта работают. VS Code имеет встроенную поддержку Git (панель Source Control) которая покрывает большинство ежедневных операций без командной строки. GitHub Desktop: ещё один вариант. Командную строку стоит освоить, потому что она встречается в CI/CD скриптах и на удалённых серверах, но начинать с GUI нормально.

В чём разница между Git и GitHub?

Git: программа контроля версий которая работает локально. GitHub: сайт который хостит Git-репозитории удалённо. GitLab и Bitbucket: альтернативы GitHub. Git работает без GitHub; GitHub хранит и шарит твои Git-репозитории.

Что писать в сообщениях коммитов?

Конкретно. «Add login tests» слабо. «Add negative login tests: wrong password, empty fields, SQL injection» полезно. Хорошее сообщение коммита отвечает: что изменилось и зачем (не как именно, это видно из кода).

Случайно закоммитил в main. Что делать?

Без паники. Если не пушил:

git reset HEAD~1  # отменить последний коммит, сохранить изменения
git checkout -b my-branch  # создать нормальную ветку
git add .
git commit -m "message"

Если пушил, а команда использует защищённую ветку main, спроси тимлида. Никогда не делай force-push в main без согласования с командой.

Случайно удалил файл. Можно восстановить?

Да, если коммитил его раньше:

git checkout HEAD -- path/to/file.ts

Одна из самых полезных возможностей Git. Можно восстановить всё что когда-либо было закоммичено.

→ See also: CI/CD для QA: сравнение GitHub Actions, Jenkins и GitLab | Как создать QA-портфолио на GitHub, которое приносит офферы (Playwright)