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

Что такое Git и зачем он нужен тестировщику

Представь: ты три дня переписывал тест-кейсы для модуля авторизации, а потом разработчик говорит — «мы откатили фичу, возвращайся к старой версии». Ты открываешь папку и видишь файлы test_cases_final.xlsx, test_cases_final2.xlsx, test_cases_FINAL_правки.xlsx, test_cases_FINAL_правки_v2_USE_THIS.xlsx. Какой из них был «до»? Непонятно. Именно в этот момент понимаешь, зачем тестировщику нужен Git.

Папка с файлами — это не система контроля версий

Многие QA-специалисты хранят тестовую документацию в Google Docs или просто в папках на диске. Это работает, пока ты один и пока изменений мало. Но как только в команде появляется второй тестировщик, или нужно поддерживать тесты для нескольких версий продукта одновременно — начинается хаос.

Git — это система контроля версий (Version Control System, VCS). Если объяснять совсем просто: Git — это умный журнал изменений, который помнит каждую версию твоих файлов, кто и когда их менял, и позволяет в любой момент вернуться к любой точке в прошлом.

Представь, что ты пишешь книгу и после каждой главы делаешь фотографию рукописи. Если через месяц захочешь вернуться к тому, как выглядела третья глава две недели назад — просто достаёшь нужную фотографию. Git делает именно это, только с твоими файлами.

Git — это не просто инструмент разработчиков. Это инструмент любого специалиста, который работает с файлами, которые меняются со временем.

Что именно хранит тестировщик в Git

Прежде чем разбираться, как работает Git, важно понять — что ты будешь в нём хранить. Для QA-инженера это несколько категорий файлов.

Тест-кейсы и чек-листы — если ты пишешь их в текстовом формате (Markdown, CSV, YAML), Git будет отслеживать каждое изменение построчно. Ты всегда увидишь, какой шаг теста был добавлен, удалён или изменён.

Автотесты — скрипты на Python, Java, JavaScript или любом другом языке. Это код, и Git создан именно для кода. Ты сможешь видеть историю каждого файла с тестами, откатываться к рабочей версии, если что-то сломалось.

Тестовые данные — конфигурационные файлы, JSON с тестовыми наборами, SQL-скрипты для подготовки базы данных.

Тестовая документация — README с описанием тестового стенда, инструкции по запуску тестов, описание тестовой среды.

Всё это можно и нужно хранить в Git. Это превращает хаотичный набор файлов в структурированный, версионированный проект.

Как Git устроен: три места, где живут твои файлы

Чтобы не путаться в командах, нужно понять одну ключевую идею: в Git у файлов есть три «места обитания».

Рабочая директория (working directory) — это обычная папка на твоём компьютере. Ты открываешь файл, редактируешь его — это происходит здесь.

Область подготовки (staging area, или индекс) — промежуточный буфер. Сюда ты кладёшь изменения, которые хочешь сохранить в следующей «точке сохранения». Это как корзина в магазине: ты выбираешь товары (изменения), кладёшь их в корзину, и только потом идёшь на кассу.

Репозиторий (repository) — постоянное хранилище всех «точек сохранения». Каждая такая точка называется коммит (commit). Репозиторий хранит всю историю проекта.

Процесс выглядит так: ты редактируешь файл в рабочей директории → добавляешь изменения в staging area → создаёшь коммит, который навсегда сохраняется в репозитории. Именно поэтому нельзя «случайно потерять» сохранённые данные — Git хранит всё.

Git и GitHub — это разные вещи

Это одна из самых частых точек путаницы у новичков, поэтому разберём сразу.

Git — программа, которая работает на твоём компьютере. Она управляет историей изменений локально.

GitHub, GitLab, Bitbucket — это веб-платформы, где репозитории хранятся в интернете. Они позволяют команде работать вместе: один тестировщик отправил изменения на GitHub, другой их скачал и продолжил работу.

Что это	Где работает	Зачем нужно
Git	На твоём компьютере	Версионирование файлов локально
GitHub / GitLab	В интернете (сервер)	Хранение и совместная работа

Аналогия: Git — это Microsoft Word с функцией «история версий», а GitHub — это Google Drive, где ты хранишь этот документ и делишься им с командой. Одно без другого работает, но вместе — намного мощнее.

В большинстве компаний используют GitLab (особенно если компания хочет держать код на своих серверах) или GitHub. Как тестировщик, ты будешь работать с обоими — принципиальной разницы в базовых операциях нет.

Почему тестировщику Git нужен не меньше, чем разработчику

Есть распространённое заблуждение: Git — это для программистов, а тестировщику достаточно Jira и Excel. Но посмотри на реальные сценарии из работы QA.

Сценарий 1: Откат к старой версии тестов. Продукт вернулся к предыдущей версии API. Тебе нужны тест-кейсы, которые были актуальны три недели назад. С Git — одна команда, и ты видишь файлы в том состоянии, в котором они были тогда.

Сценарий 2: Параллельная работа. Ты тестируешь фичу А, коллега — фичу Б. Оба редактируете один и тот же файл с регрессионными тестами. Без Git — конфликт и потеря чужих изменений. С Git — система сама поможет объединить правки.

Сценарий 3: Понять, кто и зачем изменил тест. Тест падает, но ты не понимаешь почему. С Git ты смотришь историю файла и видишь: три дня назад Иван изменил шаг 4 и написал в комментарии «обновил под новый дизайн формы». Вот твоя зацепка.

Сценарий 4: Работа с автотестами вместе с разработчиками. Автотесты живут в том же репозитории, что и код продукта. Чтобы добавить новый тест или исправить упавший — нужно уметь работать с Git так же, как разработчик.

По данным learnqa.ru, около 60% тестировщиков работают с Git каждый день, а 90% компаний используют Git как основную систему контроля версий. Это уже не «приятный бонус» в резюме — это базовый навык.

Распределённость: почему это важно для тебя

Git называют распределённой системой контроля версий. Это значит, что у каждого члена команды на компьютере хранится полная копия репозитория со всей историей. Не просто последняя версия файлов, а вся история изменений с самого начала проекта.

Что это даёт тебе на практике? Ты можешь работать офлайн — в самолёте, на даче, при проблемах с интернетом. Все операции с историей, создание коммитов, просмотр изменений — всё работает локально. Только когда нужно поделиться изменениями с командой, потребуется подключение.

Это также означает, что потерять работу почти невозможно. Если сервер GitHub упадёт — у каждого члена команды есть полная копия. Если ты случайно удалишь файл — Git поможет его восстановить из истории.

Именно поэтому Git стал стандартом индустрии. Как отмечает habr.com, Git используется в подавляющем большинстве IT-компаний — от стартапов до корпораций. Освоив его один раз, ты получаешь навык, который работает везде.

В следующей статье мы перейдём от теории к практике: создадим первый репозиторий, сделаем коммит и отправим изменения на GitHub. Но уже сейчас главное понять: Git — это не страшно и не только для разработчиков. Это твой инструмент для спокойной, организованной работы без страха что-то потерять.

Основы работы с Git: репозиторий, коммит и push

Знаешь это ощущение, когда долго откладываешь что-то «сложное», а потом оказывается, что там всего три шага? С Git именно так. Девяносто процентов ежедневной работы тестировщика покрывается пятью командами — и сегодня ты их освоишь на конкретных примерах из QA-практики.

Установка и первичная настройка

Прежде всего убедись, что Git установлен. Открой терминал (в Windows это Git Bash или PowerShell, на Mac и Linux — стандартный терминал) и введи:

git --version

Если видишь что-то вроде git version 2.43.0 — всё готово. Если команда не найдена — скачай Git с официального сайта git-scm.com.

После установки нужно представиться Git — один раз, и навсегда. Эти данные будут записаны в каждый твой коммит, чтобы коллеги знали, кто сделал изменение:

git config --global user.name "Анна Тестова"
git config --global user.email "anna@company.com"

Это не логин для GitHub — просто подпись под твоими изменениями. Как имя на полях рукописи.

Создаём первый репозиторий для тестов

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

mkdir shop-tests
cd shop-tests
git init

Команда git init создаёт скрытую папку .git внутри твоей директории. Именно там Git хранит всю историю изменений. Не трогай эту папку руками — Git управляет ею сам.

Теперь создай первый файл. Например, чек-лист для тестирования корзины:

# Создаём файл (можно сделать это в любом редакторе)
touch cart_checklist.md

Открой файл в редакторе и добавь несколько строк:

# Чек-лист: Корзина покупок

- [ ] Добавить товар в корзину
- [ ] Изменить количество товара
- [ ] Удалить товар из корзины
- [ ] Применить промокод

Сохрани файл. Теперь посмотри, что думает Git:

git status

Ты увидишь примерно такой вывод:

Untracked files:
  cart_checklist.md

Git говорит: «Я вижу этот файл, но ещё не слежу за ним». Файл существует в рабочей директории, но в историю ещё не попал.

Staging area: выбираем, что войдёт в коммит

Как мы разобрали в первой статье, перед коммитом нужно добавить изменения в staging area — промежуточную зону. Делается это командой git add:

git add cart_checklist.md

Снова проверь статус:

git status

Теперь файл в разделе Changes to be committed — он готов к сохранению.

Зачем нужна эта промежуточная зона? Представь: ты за день изменил пять файлов. Три из них — готовые, проверенные изменения. Два — незаконченные черновики. Staging area позволяет добавить в коммит только три готовых файла, оставив черновики на потом. Это очень удобно в реальной работе.

Если хочешь добавить все изменённые файлы сразу:

git add .

Точка означает «всё в текущей папке». Используй с осторожностью — убедись, что не добавляешь лишнего.

Создаём коммит: сохраняем точку в истории

Коммит — это снимок состояния твоих файлов в конкретный момент времени. Каждый коммит получает уникальный идентификатор (хеш) и сообщение, которое ты пишешь сам.

git commit -m "Добавить чек-лист для корзины покупок"

Флаг -m означает «message» — сообщение коммита. Это очень важная часть: по сообщениям коммитов ты и твои коллеги будете читать историю проекта.

Плохие сообщения коммитов — одна из самых распространённых проблем. Вот наглядное сравнение:

Плохо	Хорошо
правки	Обновить шаги теста авторизации под новый UI
fix	Исправить опечатку в тест-кейсе TC-042
изменения	Добавить тест-кейсы для сброса пароля
wip	Добавить негативные сценарии для формы оплаты

Хорошее сообщение отвечает на вопрос: «Что изменилось и зачем?». Через три месяца ты откроешь историю и сразу поймёшь, что происходило в проекте.

После коммита проверь историю:

git log --oneline

Увидишь что-то вроде:

a3f1c2d Добавить чек-лист для корзины покупок

Буквенно-цифровой код слева — это сокращённый хеш коммита. По нему можно обратиться к этому снимку в любой момент.

Подключаем GitHub и делаем push

Локальный репозиторий — хорошо, но для командной работы нужно хранить код в интернете. Создай аккаунт на github.com (это бесплатно), затем создай новый репозиторий через интерфейс сайта — кнопка «New repository». Назови его shop-tests, оставь пустым (без README).

GitHub покажет тебе инструкцию. Для нашего случая нужны две команды:

# Говорим Git, где находится удалённый репозиторий
git remote add origin https://github.com/твой-логин/shop-tests.git

# Отправляем изменения на GitHub
git push -u origin main

remote add origin — добавляем «адрес» удалённого репозитория. Слово origin — это просто стандартное имя для основного удалённого репозитория, можно было назвать иначе, но так принято.

push — отправляем наши коммиты на сервер. Флаг -u связывает локальную ветку с удалённой, чтобы в будущем писать просто git push без дополнительных параметров.

После этого открой GitHub в браузере — твой файл уже там.

Полный цикл: добавляем ещё тест-кейсы

Теперь закрепим цикл на практике. Добавь в репозиторий файл с тест-кейсами для авторизации:

# Создаём файл
touch auth_test_cases.md

Добавь содержимое:

# Тест-кейсы: Авторизация

## TC-001: Успешный вход
**Шаги:** Ввести валидный email и пароль → нажать "Войти"
**Ожидаемый результат:** Пользователь перенаправлен в личный кабинет

## TC-002: Неверный пароль
**Шаги:** Ввести валидный email и неверный пароль → нажать "Войти"
**Ожидаемый результат:** Сообщение об ошибке "Неверный пароль"

Теперь стандартный цикл:

git add auth_test_cases.md
git commit -m "Добавить тест-кейсы для авторизации (TC-001, TC-002)"
git push

Три команды — и изменения в истории и на GitHub. Именно этот цикл add → commit → push ты будешь повторять каждый день.

Клонирование: получаем чужой репозиторий

Когда ты приходишь в новую команду или начинаешь работать с существующим проектом, нужно получить репозиторий себе на компьютер. Для этого используется git clone:

git clone https://github.com/company/project-tests.git

Git создаст папку project-tests и скачает туда все файлы вместе со всей историей коммитов. После этого ты можешь работать с проектом локально.

Как посмотреть, что изменилось

Прежде чем делать коммит, полезно убедиться, что ты сохраняешь именно то, что хотел. Команда git diff показывает разницу между текущим состоянием файла и последним коммитом:

git diff cart_checklist.md

Строки со знаком + — добавленные, со знаком - — удалённые. Это очень удобно, когда ты редактировал файл и хочешь освежить память перед коммитом.

Если изменения уже добавлены в staging area, используй:

git diff --staged

Откат изменений: когда что-то пошло не так

Одна из главных ценностей Git — возможность вернуться назад. Вот самые частые сценарии для тестировщика.

Случайно изменил файл и хочешь вернуть как было (изменения ещё не в staging):

git restore cart_checklist.md

Добавил файл в staging, но передумал (хочешь убрать из staging, не теряя изменений):

git restore --staged cart_checklist.md

Хочешь посмотреть файл в том виде, каким он был в конкретном коммите:

git show a3f1c2d:cart_checklist.md

Где a3f1c2d — хеш нужного коммита из git log.

Эти команды покрывают большинство ситуаций, когда что-то пошло не так. Git устроен так, что пока изменение не закоммичено — его легко отменить. А закоммиченное — можно найти в истории и восстановить. Именно это делает работу с тестовой документацией в Git такой надёжной.

Ветки и управление тестовой документацией

Вот типичная ситуация из жизни QA-команды. Продукт выпускает версию 2.0 с новым модулем оплаты — ты пишешь тесты для него. Одновременно нужно поддерживать тесты для версии 1.5, которая ещё в продакшне. И параллельно коллега правит регрессионные тесты. Все работают с одними и теми же файлами. Без веток это катастрофа. С ветками — обычный рабочий день.

Что такое ветка и почему это не «копия папки»

Ветка (branch) в Git — это независимая линия разработки. Но важно понять: ветка не копирует все файлы проекта. Это просто указатель на определённый коммит в истории.

Представь дерево. Ствол — это основная ветка (main). В какой-то момент от ствола отходит ветвь — это новая ветка. Она растёт независимо, но помнит, откуда выросла. Когда работа на ветке закончена, её можно «вернуть в ствол» — слить с основной веткой.

Создание ветки в Git — мгновенная операция. Git не копирует файлы, он просто создаёт новый указатель. Именно поэтому ветки в Git дешёвые: их можно создавать хоть под каждую задачу.

Ветки в работе тестировщика: реальные сценарии

Прежде чем смотреть на команды, разберём — когда тестировщику нужны ветки.

Тесты для новой фичи. Разработчики делают фичу в своей ветке feature/payment-v2. Ты создаёшь ветку tests/payment-v2 и пишешь тесты там. Когда фича готова — обе ветки сливаются в main.

Поддержка нескольких версий продукта. Версия 1.5 в продакшне, версия 2.0 в разработке. Ветки tests/v1.5 и tests/v2.0 позволяют поддерживать оба набора тестов независимо.

Эксперименты с тест-кейсами. Хочешь переструктурировать тест-кейсы, но не уверен, что новая структура лучше? Создай ветку, попробуй — если не понравится, просто удали ветку. Основная документация не пострадает.

Ревью тестовой документации. В хороших командах тест-кейсы проходят ревью так же, как код. Ты создаёшь ветку, пишешь тесты, открываешь Pull Request (запрос на слияние) — коллеги смотрят и комментируют.

Основные команды для работы с ветками

Посмотреть, какие ветки существуют и на какой ты сейчас:

git branch

Звёздочка * показывает текущую ветку. Например:

* main
  tests/payment-v2
  tests/regression-update

Создать новую ветку и сразу переключиться на неё — самая частая операция:

git switch -c tests/payment-v2

Флаг -c означает «create». После этой команды ты уже находишься в новой ветке и все коммиты будут идти туда.

Переключиться на существующую ветку:

git switch main

Удалить ветку (когда работа завершена и ветка слита):

git branch -d tests/payment-v2

Практика: ведём тесты для двух версий продукта

Разберём конкретный рабочий сценарий. У нас есть репозиторий с тестами, в main лежат актуальные тесты. Нужно написать тесты для новой фичи — формы обратной связи.

# Убеждаемся, что мы на main и он актуален
git switch main
git pull

# Создаём ветку для новых тестов
git switch -c tests/feedback-form

Теперь создаём файл с тест-кейсами:

touch feedback_form_tests.md

Пишем тест-кейсы, сохраняем, делаем коммит:

git add feedback_form_tests.md
git commit -m "Добавить тест-кейсы для формы обратной связи (TC-101 — TC-108)"

В это время коллега нашёл баг в существующих тестах и исправил их в main. Нам нужно получить его изменения в нашу ветку. Для этого обновляем нашу ветку относительно main:

git merge main

Git возьмёт новые коммиты из main и добавит их в нашу ветку. Если изменения не пересекаются — слияние пройдёт автоматически.

Слияние веток: merge

Когда тесты написаны, проверены и готовы — сливаем ветку в main:

# Переключаемся на main
git switch main

# Сливаем нашу ветку
git merge tests/feedback-form

Git объединит изменения. Если в main и в нашей ветке менялись разные файлы — слияние пройдёт автоматически и создастся merge-коммит, который зафиксирует объединение.

После успешного слияния ветку можно удалить — она выполнила свою задачу:

git branch -d tests/feedback-form

Именование веток: соглашения для QA-команды

Хаотичные имена веток — это боль при командной работе. Когда в репозитории 20 веток с названиями test1, new, anna_branch, fix — никто не понимает, что где. Хорошая практика — договориться о системе именования.

Вот популярные соглашения для QA:

Тип ветки	Шаблон	Пример
Тесты для фичи	tests/название-фичи	tests/user-profile
Исправление тест-кейса	fix/описание	fix/tc042-wrong-expected-result
Регрессионные тесты	regression/версия	regression/v2.1
Автотесты	auto/модуль	auto/checkout-flow
Эксперимент	experiment/идея	experiment/bdd-format

Слэш / в имени ветки — просто часть названия, не папка. Но многие Git-клиенты отображают такие ветки сгруппированно, что удобно.

Pull Request: тест-кейсы на ревью

В командной работе ветки обычно не сливают напрямую командой merge. Вместо этого открывают Pull Request (PR) на GitHub или Merge Request (MR) на GitLab — это запрос на слияние ветки.

Процесс выглядит так:

1. Ты пишешь тест-кейсы в своей ветке и пушишь её на GitHub: git push origin tests/feedback-form
2. На GitHub открываешь Pull Request: «Хочу слить tests/feedback-form в main»
3. Коллеги видят твои изменения, оставляют комментарии прямо к строкам файла
4. Ты вносишь правки, делаешь новые коммиты в ту же ветку — PR обновляется автоматически
5. После одобрения ветка сливается в main

Это мощный инструмент для качества тестовой документации. Ревью тест-кейсов через PR — стандартная практика в зрелых QA-командах. Ты видишь точно, какие строки изменились, можешь обсудить конкретный шаг теста прямо в контексте изменения.

Просмотр истории ветки: кто и что менял

Один из самых полезных сценариев — понять, как эволюционировал конкретный тест-кейс. Посмотреть историю изменений конкретного файла:

git log --oneline -- auth_test_cases.md

Увидишь все коммиты, которые затрагивали этот файл. Чтобы посмотреть, что именно изменилось в конкретном коммите:

git show a3f1c2d

А чтобы увидеть, кто менял каждую строку файла и в каком коммите — команда git blame (дословно «обвинить», но на практике просто «кто написал эту строку»):

git blame auth_test_cases.md

Каждая строка будет помечена хешем коммита, именем автора и датой. Очень удобно, когда нужно понять контекст изменения: «Почему в TC-002 ожидаемый результат такой? Кто это написал и когда?»

Rebase: альтернатива merge для чистой истории

Есть ещё один способ обновить ветку относительно main — rebase. Вместо merge-коммита он «переносит» твои коммиты поверх актуального main, как будто ты начал работу с самой свежей версии.

git switch tests/feedback-form
git rebase main

История становится линейной — без merge-коммитов. Это выглядит чище, но есть важное правило: никогда не делай rebase для веток, которые уже запушены и используются другими людьми. Rebase переписывает историю коммитов, и у коллег возникнут проблемы при следующем pull.

Для тестировщика простое правило: используй merge для обновления своей ветки из main — это безопаснее. Rebase — для опытных пользователей Git, когда команда договорилась об этом подходе.

Ветки — это то, что превращает Git из «умного архива» в полноценный инструмент командной работы. Освоив их, ты сможешь работать параллельно с коллегами, не мешая друг другу, и поддерживать тесты для нескольких версий продукта одновременно.

Совместная работа в команде и разрешение конфликтов

Два тестировщика одновременно редактируют один и тот же файл с регрессионными тестами. Один добавляет новые шаги в TC-015, другой в это же время переименовывает тот же тест-кейс. Оба делают коммит. Оба пушат. И тут Git говорит: «Стоп. Я не знаю, какую версию оставить». Это конфликт — и это нормальная часть командной работы, а не катастрофа.

Как устроена совместная работа: общая картина

В реальной команде репозиторий один, а людей много. Каждый работает в своей ветке (как мы разобрали в предыдущей статье), но рано или поздно все ветки сливаются в main. Именно в момент слияния и возникают конфликты.

Стандартный рабочий цикл в команде выглядит так:

1. Перед началом работы — получить свежие изменения из main
2. Работать в своей ветке, делать коммиты
3. Периодически обновлять свою ветку из main (чтобы не отставать)
4. Когда готово — открыть Pull Request, пройти ревью
5. После одобрения — слить в main

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

Получаем изменения от коллег: fetch и pull

Когда коллеги запушили изменения на GitHub, тебе нужно их получить. Для этого есть две команды.

git fetch — скачивает новые коммиты с сервера, но не меняет твои локальные файлы. Ты можешь посмотреть, что изменилось, прежде чем применять:

git fetch origin
git log origin/main --oneline  # смотрим, что появилось

git pull — скачивает и сразу применяет изменения к твоей текущей ветке. Это fetch + merge в одной команде:

git pull origin main

Когда использовать что? fetch — когда хочешь сначала посмотреть, что изменилось, и только потом решить, применять ли. pull — в большинстве случаев, когда просто хочешь получить свежую версию.

Хорошая привычка — начинать рабочий день с git pull в основной ветке. Это как проверить почту утром: узнаёшь, что произошло, пока тебя не было.

Анатомия конфликта: что происходит внутри файла

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

Когда Git обнаруживает конфликт, он останавливает слияние и помечает проблемные места прямо в файле специальными маркерами. Вот как это выглядит в файле regression_tests.md:

## TC-015: Авторизация через Google

<<<<<<< HEAD
**Шаги:** Нажать "Войти через Google" → выбрать аккаунт → подтвердить
**Ожидаемый результат:** Пользователь авторизован, редирект на главную
=======
**Шаги:** Нажать "Войти через Google" → выбрать аккаунт
**Ожидаемый результат:** Пользователь авторизован
>>>>>>> tests/regression-update

Разберём маркеры:

• <<<<<<< HEAD — начало твоей версии (текущая ветка)
• ======= — разделитель между двумя версиями
• >>>>>>> tests/regression-update — конец версии из ветки, которую сливаешь

Git буквально говорит: «Вот два варианта одного места. Я не знаю, какой правильный — реши сам».

Разрешаем конфликт: пошаговый процесс

Конфликт — это не ошибка Git, это сигнал: «Здесь нужно человеческое решение». Вот как его разрешить.

Шаг 1. Посмотри, в каких файлах конфликты:

git status

Файлы с конфликтами будут помечены как both modified.

Шаг 2. Открой файл в редакторе. Найди все блоки с маркерами <<<<<<<. Их может быть несколько в одном файле.

Шаг 3. Для каждого конфликтного блока прими решение: оставить свою версию, версию коллеги, или написать третий вариант, объединяющий оба.

В нашем примере правильный вариант — объединить: шаги из первой версии более полные, но ожидаемый результат из второй версии тоже нужно дополнить. Итоговый файл после разрешения конфликта:

## TC-015: Авторизация через Google

**Шаги:** Нажать "Войти через Google" → выбрать аккаунт → подтвердить
**Ожидаемый результат:** Пользователь авторизован, редирект на главную

Все маркеры (<<<<<<<, =======, >>>>>>>) удалены. Файл выглядит как обычный текст.

Шаг 4. Добавь разрешённый файл в staging и завершай слияние:

git add regression_tests.md
git commit -m "Разрешить конфликт в TC-015: объединить шаги и ожидаемый результат"

Git создаст merge-коммит, фиксирующий результат объединения.

Инструменты для разрешения конфликтов

Редактировать конфликты вручную в текстовом файле — рабочий вариант, но есть удобнее. Большинство современных редакторов и IDE умеют показывать конфликты визуально.

VS Code — при открытии файла с конфликтом показывает кнопки прямо над каждым блоком: «Принять текущее», «Принять входящее», «Принять оба», «Сравнить». Это намного быстрее ручного редактирования.

IntelliJ IDEA / PyCharm — встроенный трёхпанельный редактор конфликтов: слева твоя версия, справа версия коллеги, в центре — результат. Ты кликаешь стрелками, выбирая нужные куски.

GitKraken, SourceTree — графические Git-клиенты с визуальным разрешением конфликтов. Удобны, если ты предпочитаешь работать без терминала.

Для тестировщика, который работает с Markdown-файлами тест-кейсов, VS Code — оптимальный выбор: лёгкий, бесплатный, с отличной поддержкой Git.

Как минимизировать конфликты: практические советы

Лучший конфликт — тот, которого не было. Вот что реально помогает в QA-команде.

Договоритесь о структуре файлов. Если каждый тестировщик отвечает за свой модуль и хранит тест-кейсы в отдельных файлах — конфликты почти исчезают. Один файл = один владелец.

Обновляйте ветку чаще. Чем чаще ты делаешь git merge main в свою ветку, тем меньше накапливается расхождений.

Делайте маленькие коммиты и короткие ветки. Ветка, которая живёт два дня и содержит 10 коммитов, сливается намного легче, чем ветка за три недели с 80 коммитами.

Общайтесь с командой. Если знаешь, что коллега тоже работает с файлом regression_tests.md — скажи ему. Договоритесь, кто какую часть редактирует. Git помогает разрешать конфликты, но не заменяет коммуникацию.

Работа с общим репозиторием: fork и upstream

В некоторых командах (особенно в open source или при работе с репозиторием разработчиков) используется модель fork. Ты создаёшь собственную копию репозитория на GitHub, работаешь в ней, а потом предлагаешь изменения в оригинальный репозиторий через Pull Request.

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

# Клонируешь свой fork
git clone https://github.com/твой-логин/project-tests.git

# Добавляешь ссылку на оригинальный репозиторий
git remote add upstream https://github.com/company/project-tests.git

# Получаешь обновления из оригинала
git fetch upstream
git merge upstream/main

upstream — стандартное имя для оригинального репозитория, от которого сделан fork. Это позволяет держать свою копию актуальной.

Что делать, если push отклонён

Ты делаешь git push и видишь ошибку:

! [rejected] main -> main (fetch first)
error: failed to push some refs

Это значит: пока ты работал, кто-то запушил изменения в ту же ветку, и твоя локальная версия устарела. Git не позволяет перезаписать чужую работу.

Решение простое:

git pull origin main   # получаем свежие изменения
# если есть конфликты — разрешаем их
git push origin main   # теперь push пройдёт

Никогда не используй git push --force на общих ветках (main, develop). Это перезапишет историю и уничтожит чужие коммиты. --force допустим только в своей личной ветке, которую никто больше не использует.

Совместная работа в Git — это навык, который приходит с практикой. Первый конфликт всегда пугает, второй — уже понятен, а десятый — просто рутина. Главное помнить: Git не теряет данные. Даже если что-то пошло не так — в истории всё сохранено, и можно разобраться.

Полезные приёмы Git для ежедневных задач QA

Ты уже умеешь делать коммиты, работать с ветками и разрешать конфликты. Это фундамент. Но между «знать основы» и «работать быстро и уверенно» — пропасть из маленьких приёмов, которые опытные QA-инженеры используют каждый день, а новички о них не догадываются. Эта статья — именно про них.

git stash: убрать незаконченную работу на полку

Классическая ситуация: ты на полпути пишешь тест-кейсы для новой фичи, файлы изменены, но коммитить рано — работа не закончена. И тут прилетает срочный баг в продакшне: «Нужно срочно проверить регрессию, переключись на main!»

Если попробуешь переключить ветку с незакоммиченными изменениями, Git либо откажет, либо потащит незаконченные файлы с собой. Оба варианта плохие.

Решение — git stash. Это команда, которая временно «прячет» все незакоммиченные изменения в специальный буфер, возвращая рабочую директорию в чистое состояние:

git stash
# Saved working directory and index state WIP on tests/feedback: "черновик TC-201"

Теперь рабочая директория чистая. Переключайся на main, делай срочную работу. Когда вернёшься — достань изменения обратно:

git stash pop

pop достаёт последнее сохранённое состояние и удаляет его из буфера. Если хочешь посмотреть, что лежит в stash, не применяя:

git stash list
# stash@{0}: WIP on tests/feedback: черновик TC-201
# stash@{1}: WIP on tests/auth: незаконченный TC-055

Можно хранить несколько stash-записей и применять конкретную:

git stash apply stash@{1}

apply в отличие от pop не удаляет запись из списка — удобно, если хочешь применить одно и то же состояние несколько раз.

Полезный приём: давай stash-записям имена, чтобы не путаться:

git stash push -m "черновик тестов для формы оплаты"

git log: читаем историю как детектив

git log --oneline ты уже знаешь. Но история проекта — это кладезь информации, если уметь её читать.

Посмотреть историю конкретного файла — незаменимо, когда тест-кейс ведёт себя странно и хочешь понять, что с ним происходило:

git log --oneline -- auth_test_cases.md

Посмотреть, что именно изменилось в каждом коммите для этого файла:

git log -p -- auth_test_cases.md

Флаг -p показывает полный diff каждого коммита. Это как читать журнал операций: видишь каждое добавление и удаление строк с датой и автором.

Найти коммиты по ключевому слову в сообщении — удобно, когда помнишь, что «что-то делал с TC-042», но не помнишь когда:

git log --oneline --grep="TC-042"

Посмотреть историю за последнюю неделю:

git log --oneline --since="1 week ago"

Красивый граф веток в терминале — помогает понять, как ветки расходились и сливались:

git log --oneline --graph --all

Вывод выглядит примерно так:

* a1b2c3d (HEAD -> main) Слить тесты для формы обратной связи
|\
| * d4e5f6a (tests/feedback-form) Добавить негативные сценарии TC-108
| * g7h8i9j Добавить базовые тест-кейсы TC-101 — TC-107
|/
* k1l2m3n Обновить регрессионные тесты для авторизации

git blame: кто написал эту строку и зачем

Тест-кейс TC-033 содержит странный шаг, который не соответствует текущему поведению системы. Кто его добавил и почему? git blame покажет автора и коммит для каждой строки файла:

git blame auth_test_cases.md

Вывод:

a3f1c2d (Иван Петров  2024-03-15) ## TC-033: Восстановление пароля
d4e5f6a (Анна Тестова 2024-04-02) **Шаги:** Нажать "Забыли пароль"
d4e5f6a (Анна Тестова 2024-04-02) **Ожидаемый результат:** Письмо на email

Видишь: строку с ожидаемым результатом добавила Анна 2 апреля. Можно посмотреть тот коммит целиком:

git show d4e5f6a

И прочитать сообщение коммита: «Обновить TC-033 под новый флоу сброса пароля после редизайна». Теперь понятно, почему шаг такой — и можно обсудить с Анной, актуально ли это сейчас.

git diff: сравниваем версии тест-кейсов

Разработчик говорит: «Мы изменили поведение модуля оплаты в этом спринте». Тебе нужно понять, какие тест-кейсы затронуты. Сравни текущую версию файла с версией из прошлого спринта:

# Сравнить текущее состояние с конкретным коммитом
git diff a3f1c2d -- payment_tests.md

# Сравнить два коммита между собой
git diff a3f1c2d d4e5f6a -- payment_tests.md

# Сравнить две ветки
git diff main tests/payment-v2 -- payment_tests.md

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

git bisect: найти коммит, который сломал тест

Это один из самых мощных и недооценённых инструментов Git. Представь: автотест работал три недели назад, а сейчас падает. За это время было 40 коммитов. Какой из них сломал тест?

git bisect использует бинарный поиск: делит историю пополам, ты проверяешь — работает или нет, Git снова делит пополам. За 6–7 шагов находит виновный коммит из 40.

# Начинаем поиск
git bisect start

# Говорим, что текущее состояние — плохое (тест падает)
git bisect bad

# Говорим, что три недели назад было хорошо
git bisect good a3f1c2d

# Git переключает на средний коммит — проверяем тест
# Если тест работает:
git bisect good
# Если тест падает:
git bisect bad

# Git продолжает делить пополам...
# В итоге выдаёт: "d4e5f6a is the first bad commit"

# Завершаем поиск
git bisect reset

После нескольких итераций Git точно укажет на коммит, который сломал тест. Смотришь git show d4e5f6a — видишь, что именно изменилось. Это экономит часы отладки.

.gitignore: что не нужно хранить в репозитории

Не всё, что лежит в папке с тестами, нужно версионировать. Файл .gitignore говорит Git, какие файлы игнорировать.

Создай файл .gitignore в корне репозитория:

# Логи тестовых прогонов
*.log
test-results/
allure-results/

# Временные файлы редактора
.DS_Store
*.swp
.idea/
.vscode/

# Зависимости (если используешь Python или Node.js)
__pycache__/
node_modules/
venv/

# Конфигурация с секретами
.env
config/local.yml

Что точно не нужно в репозитории:

• Логи тестовых прогонов (они генерируются каждый раз заново)
• Папки с результатами тестов (Allure, JUnit XML)
• Файлы с паролями и токенами (.env, конфиги с секретами)
• Системные файлы (.DS_Store на Mac, Thumbs.db на Windows)
• Папки зависимостей (node_modules, venv)

Что точно нужно:

• Тест-кейсы и чек-листы
• Скрипты автотестов
• Конфигурационные файлы без секретов
• README и документация

Алиасы: сокращаем длинные команды

Некоторые команды Git длинные, но используются каждый день. Алиасы позволяют создать короткие псевдонимы:

# Короткий статус
git config --global alias.st status

# Красивый лог
git config --global alias.lg "log --oneline --graph --all"

# Быстрое создание ветки
git config --global alias.new "switch -c"

После этого вместо git log --oneline --graph --all пишешь просто git lg. Вместо git switch -c tests/new-feature — git new tests/new-feature.

Теги: отмечаем важные точки в истории

Тег (tag) — это именованная метка на конкретном коммите. В отличие от ветки, тег не двигается — он всегда указывает на одно и то же место в истории.

Для тестировщика теги полезны, чтобы отмечать версии тестовой документации, соответствующие релизам продукта:

# Создать тег для текущего коммита
git tag v2.1-tests

# Создать тег с описанием
git tag -a v2.1-tests -m "Тест-кейсы для релиза 2.1: добавлены тесты оплаты и профиля"

# Посмотреть все теги
git tag

# Отправить теги на GitHub
git push origin --tags

# Переключиться на состояние репозитория в момент тега
git checkout v2.1-tests

Когда через полгода нужно будет вернуться к тестам, которые были актуальны для версии 2.1 — просто переключаешься на тег. Никаких поисков «а какой это был коммит».

Восстановление удалённых файлов и коммитов

Случайно удалил файл с тест-кейсами? Не паникуй.

# Восстановить удалённый файл из последнего коммита
git restore auth_test_cases.md

# Восстановить файл из конкретного коммита
git restore --source=a3f1c2d auth_test_cases.md

Сделал коммит с ошибкой в сообщении и хочешь исправить (только если ещё не запушил):

git commit --amend -m "Правильное сообщение коммита"

Нужно отменить последний коммит, но сохранить изменения в файлах:

git reset --soft HEAD~1

HEAD~1 означает «один коммит назад от текущего». Изменения вернутся в staging area — можешь переделать коммит.

И самый мощный инструмент восстановления — git reflog. Он хранит историю всех перемещений HEAD за последние 90 дней. Даже если ты сделал reset --hard и «потерял» коммиты — они всё ещё в reflog:

git reflog
# a3f1c2d HEAD@{0}: reset: moving to HEAD~1
# d4e5f6a HEAD@{1}: commit: Добавить тест-кейсы TC-201

Видишь коммит d4e5f6a, который «потерял»? Восстанови его:

git checkout d4e5f6a
git switch -c recovery/lost-tests

Git — это система, из которой очень сложно что-то потерять безвозвратно. Если изменение было закоммичено хоть раз — оно где-то есть.

Быстрая шпаргалка для ежедневной работы QA

Собери эти команды в закладки — они покрывают 95% ситуаций в реальной работе:

Задача	Команда
Спрятать незаконченную работу	git stash
Вернуть спрятанное	git stash pop
Кто изменил эту строку	git blame файл
История конкретного файла	git log --oneline -- файл
Что изменилось в коммите	git show хеш
Найти сломавший коммит	git bisect start/good/bad
Отметить версию тегом	git tag -a v1.0 -m "описание"
Восстановить удалённый файл	git restore файл
Исправить последний коммит	git commit --amend
История всех действий	git reflog

Git — это не просто инструмент хранения файлов. Для тестировщика это система, которая делает работу прозрачной, воспроизводимой и безопасной. Ты всегда знаешь, что изменилось, кто изменил и когда. Ты можешь вернуться в любую точку прошлого. Ты можешь работать параллельно с командой, не боясь потерять чужую работу или свою. Именно это превращает хаотичный набор файлов в профессиональный, управляемый проект.