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 устроен: три места, где живут твои файлы

Чтобы не путаться в командах, нужно понять одну ключевую идею: в 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 2.43.0 — всё готово. Если команда не найдена — скачай Git с официального сайта git-scm.com.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

!Цикл работы с Git: редактирование → staging → коммит → push на GitHub

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Где 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 (запрос на слияние) — коллеги смотрят и комментируют.

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

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

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

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

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

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

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

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

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

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

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

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

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

!Схема веток: main, ветка тестов для фичи, ветка регрессии — как они расходятся и сливаются

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

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

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

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

Именование веток: соглашения для 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 — это запрос на слияние ветки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

!Визуальное разрешение конфликта в VS Code: две версии файла и кнопки выбора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод:

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

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

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

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

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

!Шпаргалка по полезным командам Git для QA: stash, blame, log, diff, bisect

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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