Как работают Git и коммиты?

Что проверяют

Для тестировщика Git это не столько команды, сколько умение понять, что вошло в сборку, переключиться на ветку фичи и найти изменение, которое сломало функцию. Следом обычно спрашивают, чем merge отличается от rebase или как найти коммит, после которого появился баг.

Как отвечать

Покажите модель, а потом команды. Git хранит не диффы, а снимки: коммит это объект, который ссылается на дерево файлов проекта, на родительский коммит (у коммита слияния их два), автора и сообщение. Идентификатор коммита это хеш от содержимого, поэтому изменить коммит нельзя, можно только создать новый. Ветка это подвижный указатель на коммит, HEAD показывает, где вы сейчас.

Изменения проходят три зоны: рабочий каталог, индекс (git add) и история (git commit). Удалённый репозиторий синхронизируется отдельно: git fetch только скачивает, git pull скачивает и сливает.

Что реально нужно в работе QA:

• git log --oneline --graph и git show <hash>: что и когда вошло в ветку;
• git diff main...feature: что изменила фича, чтобы спланировать регресс не по всему продукту;
• git switch: переключиться на ветку для проверки, старый вариант git checkout;
• git bisect: бинарный поиск по истории. Отмечаете хороший и плохой коммит, Git сам предлагает середину, а с git bisect run и автотестом поиск идёт без вас;
• git blame: кто и в каком коммите менял строку, к кому идти с вопросом.

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

Где спотыкаются

Говорят, что коммит хранит только изменения. Логически это снимок всего проекта, а дифф Git вычисляет при показе; сжатие дельтами внутри pack-файлов это деталь хранения.

Путают fetch и pull и удивляются неожиданному коммиту слияния в локальной ветке.

Не знают про bisect и ищут сломавший коммит, вручную перебирая сборки подряд. Упомянуть его на собеседовании QA почти всегда плюс.