Вопросы по Git на собеседовании: 25 вопросов с ответами

Git проверяют почти на любом собеседовании разработчика, тестировщика или DevOps-инженера: иногда отдельным блоком, иногда между делом («как бы вы откатили неудачный релиз?»). Интервьюеру важно не столько знание флагов, сколько понимание модели: что такое коммит, куда указывает ветка, что переписывает история. Ниже — 25 вопросов, которые встречаются чаще всего, с ответами того уровня, который производит хорошее впечатление.

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

Базовые вопросы

1. Что такое Git и чем распределённая система контроля версий отличается от централизованной?

Git — распределённая система контроля версий: она хранит историю изменений проекта и позволяет нескольким людям работать над ним параллельно. В централизованных системах (например, SVN) полная история лежит на одном сервере, а у разработчика — только рабочая копия. В Git каждый клон содержит всю историю, поэтому коммиты, ветки, просмотр истории и слияния работают локально и без сети.

Отсюда практические плюсы: высокая скорость, работа офлайн, отсутствие единой точки отказа. Сервер вроде GitHub или GitLab в Git — просто договорённость команды о «главной» копии, а не техническая необходимость.

2. Из каких трёх областей состоит работа с Git?

Рабочая директория (файлы на диске), индекс или staging area (подготовленный снимок следующего коммита) и локальный репозиторий (папка .git с историей). git add переносит изменения из рабочей директории в индекс, git commit — из индекса в репозиторий.

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

3. Зачем нужен индекс, если можно коммитить сразу?

Индекс позволяет собрать коммит осознанно: из десяти изменённых файлов закоммитить три, относящиеся к одной задаче, а остальное оставить. С git add -p можно выбрать даже отдельные фрагменты внутри файла.

Это основа атомарных коммитов: один коммит — одно логическое изменение. Такую историю легко читать, ревьюить, откатывать через revert и переносить через cherry-pick.

4. Что такое коммит с точки зрения внутреннего устройства Git?

Коммит — объект, который хранит ссылку на дерево (tree) — снимок всех файлов проекта, ссылки на родительские коммиты, автора, коммиттера, даты и сообщение. Идентифицируется хешем SHA-1 (в новых версиях есть экспериментальная поддержка SHA-256) от всего содержимого.

Ключевая мысль: Git хранит снимки, а не диффы. Неизменённые файлы не дублируются — дерево просто ссылается на тот же blob. Поскольку хеш зависит от родителя, изменить старый коммит, не изменив хеши всех последующих, невозможно.

5. Что такое ветка и что такое HEAD?

Ветка — это всего лишь подвижный указатель на коммит, файл в .git/refs/heads/ с хешем внутри. Поэтому создание ветки в Git мгновенно и ничего не копирует. При новом коммите указатель текущей ветки сдвигается на него.

HEAD — указатель на то, где вы сейчас находитесь; обычно он указывает на ветку (ref: refs/heads/main). Если переключиться на конкретный коммит или тег, HEAD будет указывать прямо на коммит — это состояние detached HEAD.

6. Что такое detached HEAD и чем оно опасно?

Это состояние, когда HEAD указывает на коммит, а не на ветку, например после git switch --detach v1.0 или git checkout a1b2c3d. Смотреть код и даже коммитить можно, но новые коммиты не принадлежат ни одной ветке.

Если после этого переключиться на другую ветку, такие коммиты станут недостижимыми и со временем будут удалены сборщиком мусора. Чтобы сохранить работу, создайте ветку: git switch -c fix-from-detached. Если уже ушли — хеш найдётся в git reflog.

7. Чем git fetch отличается от git pull?

git fetch скачивает новые коммиты и обновляет remote-tracking ветки вроде origin/main, но не трогает ваши локальные ветки и файлы. git pull — это fetch плюс интеграция: по умолчанию merge, с флагом --rebase или настройкой pull.rebase=true — rebase.

Опытные разработчики часто делают fetch отдельно, смотрят git log HEAD..origin/main и только потом решают, как интегрировать изменения.

8. Как работает .gitignore и почему файл всё ещё отслеживается, хотя добавлен в него?

.gitignore задаёт шаблоны файлов, которые Git не должен предлагать к добавлению: зависимости, сборку, логи, локальные конфиги с секретами. Правила действуют только для неотслеживаемых файлов.

Если файл уже был закоммичен, игнор на него не влияет. Нужно убрать его из индекса, оставив на диске: git rm --cached config.local.php, и закоммитить это удаление. Проверить, какое правило срабатывает, помогает git check-ignore -v путь.

Ветки, слияние и конфликты

9. Что такое fast-forward merge?

Если целевая ветка не ушла вперёд с момента ответвления, Git при слиянии просто сдвигает её указатель на последний коммит вливаемой ветки — без нового коммита. История остаётся линейной.

Флаг --no-ff заставляет создать merge-коммит даже в этом случае: так в истории видно, что группа коммитов была отдельной фичей. Флаг --ff-only, наоборот, разрешает только fast-forward и отказывается, если нужен настоящий merge.

10. Как возникает конфликт слияния и как его разрешить?

Конфликт возникает, когда в обеих ветках изменены одни и те же строки файла (или файл удалён в одной ветке и изменён в другой), и Git не может решить автоматически. Он останавливает слияние и помечает места маркерами <<<<<<<, =======, >>>>>>>.

git status                 # список файлов с конфликтами
# правим файлы, оставляя правильный вариант
git add app.js
git commit                 # для merge; для rebase — git rebase --continue

Хороший ответ включает и профилактику: маленькие ветки, частый pull из основной ветки, договорённости о форматировании. А также git merge --abort, если нужно отступить.

11. Чем отличаются merge и rebase?

merge объединяет две ветки, создавая merge-коммит с двумя родителями; существующие коммиты не меняются, история честно отражает параллельную работу. rebase переносит коммиты вашей ветки поверх другой ветки, создавая их копии с новыми хешами; история получается линейной.

Обычное правило: rebase — для приведения в порядок своей локальной ветки перед публикацией, merge — для интеграции в общие ветки. Rebase опубликованных коммитов, на которых работают другие, приводит к дублям и путанице.

12. Что такое интерактивный rebase и для чего он нужен?

git rebase -i HEAD~5 открывает список последних пяти коммитов, где для каждого можно выбрать действие: pick — оставить, reword — изменить сообщение, edit — остановиться и поправить, squash и fixup — слить с предыдущим, drop — удалить. Строки можно переставлять.

Типичный сценарий — перед pull request превратить «wip», «fix typo», «ещё фикс» в два-три осмысленных коммита. Удобная связка: git commit --fixup=<hash> и затем git rebase -i --autosquash.

13. Что делает squash merge и когда его выбирают?

При squash merge все коммиты ветки сжимаются в один коммит в целевой ветке (git merge --squash или кнопка на GitHub/GitLab). Основная ветка получает по одному коммиту на фичу.

Плюс — чистая история main. Минус — теряется детальная история внутри фичи, и Git не считает исходную ветку слитой, поэтому git branch -d откажется её удалять без -D.

14. Что такое cherry-pick и когда он уместен?

git cherry-pick <hash> применяет изменения одного коммита к текущей ветке, создавая новый коммит с тем же содержимым, но другим хешем. Классический случай — перенести исправление бага из develop в ветку релиза или хотфикса.

Злоупотреблять им не стоит: один и тот же фикс живёт в двух коммитах, а при последующем слиянии веток возможны конфликты. Флаг -x добавляет в сообщение ссылку на исходный коммит.

Отмена изменений и восстановление

15. Чем отличаются git reset --soft, --mixed и --hard?

Режим	Указатель ветки	Индекс	Рабочая директория
--soft	сдвигается	не меняется	не меняется
--mixed (по умолчанию)	сдвигается	сбрасывается	не меняется
--hard	сдвигается	сбрасывается	сбрасывается, правки теряются

git reset --soft HEAD~3 удобен, чтобы переделать три последних коммита в один. --hard опасен для незакоммиченных правок: их не вернёт даже reflog.

16. Чем git revert отличается от git reset?

reset перемещает указатель ветки назад, фактически переписывая историю. revert создаёт новый коммит, который отменяет изменения указанного, и ничего не переписывает.

Поэтому для опубликованных коммитов в общей ветке правильный ответ — revert: история коллег не ломается, отмена сама видна в логе. Для merge-коммита нужно указать основного родителя: git revert -m 1 <hash>.

17. Как восстановить коммиты после случайного git reset --hard?

Через git reflog: он хранит историю перемещений HEAD и веток локально (по умолчанию записи живут около 90 дней). Находим запись до неудачной команды и возвращаемся:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~2
# 9f8e7d6 HEAD@{1}: commit: Добавить оплату
git reset --hard 9f8e7d6

Важная оговорка: reflog спасает только закоммиченное. Изменения, которые никогда не попадали в коммит (или хотя бы в stash), восстановить через Git нельзя.

18. Как отменить изменения в файле и убрать его из индекса?

Современные команды — git restore app.js (вернуть файл к состоянию индекса) и git restore --staged app.js (убрать из индекса, сохранив правки). Раньше для этого использовали git checkout -- app.js и git reset HEAD app.js; они по-прежнему работают.

19. Что такое git stash и какие у него подводные камни?

git stash временно сохраняет незакоммиченные изменения и очищает рабочую директорию — например, чтобы срочно переключиться на хотфикс. Вернуть их можно через git stash pop или apply.

Подводные камни: по умолчанию не сохраняются неотслеживаемые файлы (нужен -u); при pop возможен конфликт, и тогда запись не удаляется из списка; stash легко забыть. Для долгой работы лучше коммит в отдельную ветку.

Продвинутые вопросы и командная работа

20. Как найти коммит, который сломал функциональность?

С помощью git bisect — двоичного поиска по истории. Указываете заведомо плохой и хороший коммиты, а Git переключает вас на середину диапазона, пока не найдёт виновника за log2(N) шагов.

git bisect start
git bisect bad                 # текущая версия сломана
git bisect good v2.3.0         # здесь всё работало
# проверяем и отвечаем good/bad, пока Git не назовёт коммит
git bisect reset

Если есть скрипт проверки, процесс автоматизируется: git bisect run npm test.

21. Почему git push --force опасен и чем его заменить?

--force перезаписывает удалённую ветку вашей версией, и коммиты, которые коллеги успели запушить, исчезают с сервера. Безопаснее git push --force-with-lease: он перезапишет ветку, только если она на сервере в том состоянии, которое вы видели при последнем fetch.

Принудительный push нормален для собственной feature-ветки после rebase; в main и другие общие ветки его обычно запрещают защитой веток на сервере.

22. Какие Git workflow вы знаете?

GitHub Flow: одна основная ветка, всегда готовая к деплою, и короткие feature-ветки, которые вливаются через pull request после ревью и CI. Git Flow: ветки main и develop, плюс feature/*, release/* и hotfix/*; подходит для продуктов с версионными релизами. Trunk-based development: все интегрируются в trunk очень часто, недоделанное прячется за feature flags.

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

23. Что такое pull request и что в нём проверяют?

Pull request (в GitLab — merge request) — запрос на слияние ветки, который проходит код-ревью и автоматические проверки CI перед вливанием. Это функция платформы (GitHub, GitLab, Bitbucket), а не самого Git.

Хороший PR небольшой, решает одну задачу, имеет понятное описание и связан с задачей в трекере. Ревьюер смотрит на корректность, читаемость, тесты и на то, не попали ли в PR лишние файлы или секреты.

24. Какие правила хорошего сообщения коммита вы соблюдаете?

Короткий заголовок (до 50–72 символов) в повелительном наклонении — «Добавить валидацию email», затем пустая строка и тело, объясняющее «почему», а не «что» (что изменилось, видно в диффе). Многие команды используют Conventional Commits: feat:, fix:, docs:, refactor:.

Такие сообщения позволяют генерировать changelog, быстро находить нужное через git log --grep и понимать мотивы изменений через годы.

25. Что вы сделаете, если случайно запушили пароль в репозиторий?

Первым делом — отозвать и перевыпустить секрет: он уже скомпрометирован, даже если удалить его через минуту (клоны, форки, кэш). Затем убрать файл из отслеживания, добавить в .gitignore и при необходимости вычистить историю инструментами вроде git filter-repo с последующим force push и предупреждением команды.

Интервьюер здесь проверяет приоритеты: кандидат, который начинает с переписывания истории и забывает про ротацию ключа, отвечает неправильно.

Как подготовиться к вопросам по Git

Самый надёжный способ — не заучивать ответы, а прогнать каждый сценарий руками в тестовом репозитории: создать конфликт и разрешить его, сделать reset --hard и восстановиться через reflog, сжать коммиты интерактивным rebase. На собеседовании по Git часто дают практическую задачу или просят нарисовать граф коммитов до и после команды — если вы это делали сами, ответ рисуется легко.

Полезно также пройти короткий тест по гиту для самопроверки: попробуйте без подсказок ответить, что произойдёт с историей после git rebase main или git revert HEAD. Если на вопрос «что изменится в трёх зонах» вы отвечаете уверенно, база у вас есть.

Итог

Собеседование по Git почти всегда сводится к трём темам: модель данных (коммиты, ветки, HEAD, индекс), интеграция изменений (merge, rebase, конфликты, fetch и pull) и безопасная отмена (reset, revert, reflog). Добавьте понимание командного workflow и pull request — и вы закроете подавляющее большинство вопросов. Все эти сценарии, включая командную работу и продвинутые инструменты, отрабатываются на практике в курсе по Git.