Track
Git — незаменимый инструмент в арсенале современного разработчика, известный своими мощными возможностями контроля версий. Созданный Линусом Торвальдсом в 2005 году для поддержки разработки ядра Linux, Git с тех пор стал основой бесчисленных программных проектов по всему миру. Его эффективность и гибкость в управлении версиями проектов, а также надёжная поддержка совместной работы делают его необходимым для команд любого размера.
Эта статья поможет подготовиться к техническим собеседованиям, разобрав топ‑20 вопросов по Git — от базового до продвинутого уровня. Независимо от того, новичок вы в Git или хотите углубить знания, эти вопросы и ответы помогут продемонстрировать вашу компетентность и успешно пройти интервью.
Базовые вопросы по Git
Если вы относительно недавно используете Git, на собеседовании, скорее всего, будут вопросы об основах и базовых сценариях. Чтобы освежить знания, загляните в курс DataCamp Introduction to Git.
Что такое репозиторий Git?
Репозиторий Git хранит файлы проекта и историю их изменений, обеспечивая контроль версий путём отслеживания правок со временем. Он может находиться локально — в папке на вашем устройстве — или на онлайн‑платформе вроде GitHub. Это позволяет пользователям сотрудничать, откатываться к предыдущим версиям и эффективно управлять разработкой с помощью команд commit, push и pull.
Как работает Git?
Git фиксирует изменения, внесённые в файлы и каталоги проекта, сохраняя «снимки» его состояния. Пользователи могут отслеживать правки, создавать ветки для параллельной разработки, объединять ветки и при необходимости возвращаться к прошлым состояниям. Он также упрощает совместную работу и обеспечивает эффективный контроль версий в проектах по разработке ПО.
Что делает git add?
Команда git add подготавливает изменения к включению в следующий коммит. Она отмечает модификации, добавления или удаления файлов в рабочем каталоге для попадания в предстоящий снимок коммита. Обратите внимание: эта команда не выполняет коммит, а лишь подготавливает изменения к стадированию.
Что делает git push?
Команда git push загружает содержимое локального репозитория в удалённый. Она передаёт зафиксированные изменения из локального репозитория в удалённый, как правило на серверы вроде GitHub или GitLab. Эта команда обеспечивает совместную работу, позволяя делиться изменениями с другими участниками проекта.
Подробнее о git push и git pull — в отдельном руководстве.
Что делает git status?
Команда git status показывает текущее состояние репозитория. Она сообщает, какие файлы изменены, какие подготовлены к следующему коммиту, а какие неотслеживаемые. Это помогает отслеживать прогресс работы и видеть изменения, которые нужно закоммитить или подготовить.
Что такое коммит в Git?
Коммит — это снимок изменений файлов в репозитории в определённый момент времени. Когда вы делаете коммит в Git, вы фактически сохраняете текущее состояние файлов и можете добавить осмысленное сообщение с описанием внесённых изменений (это рекомендуется).
Каждый коммит получает уникальный идентификатор, что позволяет отслеживать историю изменений в репозитории. Коммиты играют ключевую роль в контроле версий: с их помощью можно откатываться к прежним состояниям проекта, просматривать историю и делиться обновлениями для совместной работы.

Загляните в шпаргалку по Git от DataCamp — она пригодится при подготовке к интервью
Что такое ветвление (branching) в Git?
Ветвление — это ответвление от основной линии разработки (обычно это ветка main, ранее называлась master), позволяющее работать над новыми функциями, исправлениями или экспериментами, не затрагивая основную кодовую базу. Это даёт возможность сосуществовать нескольким параллельным линиям разработки в одном репозитории.
Каждая ветка — это отдельная линия развития со своими коммитами, что позволяет разработчикам одновременно работать над разными задачами. Ветвление упрощает сотрудничество, эксперименты и организацию проекта: изменения из одной ветки можно слить обратно в основную, когда они готовы и протестированы.
Что такое конфликт в Git?
Конфликты возникают, когда разные участники вносят несовместимые изменения в одну и ту же часть файла (или нескольких файлов), как правило при слиянии или перебазировании. Git не может разрешить такие противоречия автоматически, поэтому требуется ручное вмешательство пользователя.
Чтобы устранить конфликт, откройте затронутый файл — Git пометит конфликтующие участки маркерами <<<<<<<, ======= и >>>>>>>. Отредактируйте файл, оставив корректный вариант, удалите маркеры, затем:
git add <resolved-file>
git commit
git mergetool делают этот процесс нагляднее и проще.Что такое merge в Git?
Слияние — базовая операция Git, которая упрощает сотрудничество и интеграцию изменений из разных веток проекта. Слияние — это объединение изменений из одной или нескольких веток в одну ветку, обычно в основную (например, master или main).
При слиянии изменения из одной ветки интегрируются в другую, в результате чего создаётся новый коммит, объединяющий истории обеих веток. Подробнее о том, как решать конфликты слияния в Git, читайте в отдельном руководстве.
Вопросы по Git среднего уровня
Что такое удалённый репозиторий (remote) в Git?
Удалённый репозиторий — это репозиторий на сервере или другом компьютере для совместной работы и обмена кодом. Он служит централизованным местом, куда разработчики отправляют локальные изменения и откуда получают изменения других.
Обычно удалённые репозитории настраивают на платформах вроде GitHub, GitLab или Bitbucket. Они поддерживают распределённую разработку и командную работу, предоставляя общее место для хранения и синхронизации кода между множеством участников.
Как откатить коммит, который уже был отправлен и опубликован?
Для отката уже отправленного и опубликованного коммита используйте команду git revert <commit-hash>.
Пошагово это выглядит так:
1. Определите коммит для отката, найдя его хеш. Для этого используйте git log, чтобы просмотреть историю и найти нужный хеш.
2. Имея хеш, выполните команду git revert с этим хешем, чтобы создать новый коммит, отменяющий изменения указанного коммита. Например:
git revert <commit-hash>
3. Git откроет текстовый редактор для сообщения коммита‑отката. При необходимости отредактируйте сообщение, затем сохраните и закройте редактор.
4. После сохранения сообщения Git создаст новый коммит, фактически отменяющий изменения исходного коммита. Этот новый коммит добавится в историю, тем самым откатив изменения.
5. Наконец, отправьте новый коммит в удалённый репозиторий, чтобы сделать откат публичным, командой:
git push origin <branch-name>
Команда git revert создаёт новый коммит, который отменяет изменения оригинального коммита, не переписывая историю. Это безопаснее, чем git reset или git amend, которые переписывают историю и могут создать проблемы для коллег, уже получивших эти изменения.
Что такое git stash?
git stash — это команда, которая временно сохраняет изменения в рабочем каталоге, ещё не готовые к коммиту. Она позволяет отложить модификации, не фиксируя их в репозитории.
Сташим пользоваться удобно при переключении веток, когда вы не хотите ни коммитить, ни терять изменения. Позже вы можете применить сохранённые правки к рабочему каталогу или «вынуть» их из стека stash и продолжить работу.
Что такое git reflog?
git reflog — команда для просмотра журнала ссылок, где фиксируются изменения указателя HEAD и история коммитов, которые вы переключали в репозитории. Она даёт хронологический список последних действий — коммитов, checkout, merge и reset.
Reflog помогает восстановить потерянные коммиты или ветки и понять последовательность действий в репозитории.
Как сделать так, чтобы существующая ветка Git отслеживала удалённую ветку?
Чтобы заставить существующую локальную ветку отслеживать удалённую, используйте команду git branch с опцией --set-upstream-to или -u, указав имя удалённой ветки.
Синтаксис будет таким:
git branch --set-upstream-to=<remote-name>/<branch-name>
или
git branch -u <remote-name>/<branch-name>
Продвинутые вопросы по Git
Как управлять несколькими конфигурациями для разных проектов в Git?
Используйте команду git config с флагами --global, --system или --local, чтобы настраивать параметры на разных уровнях. Кроме того, применяйте includeIf в конфигурации Git, чтобы подключать определённые настройки в зависимости от пути к репозиторию.
Как работать с большими файлами в Git?
Работа с большими файлами может быть затруднительной из‑за роста размера репозитория и падения производительности. Используйте Git LFS, чтобы хранить большие файлы вне репозитория Git, оставляя в нём лишь лёгкие указатели. Это уменьшает размер репозитория и улучшает производительность. Git LFS поддерживает разных провайдеров хранения и бесшовно интегрируется в рабочие процессы Git.
Зачем нужен git submodule и как его обновить?
Команда git submodule управляет внешними зависимостями внутри репозитория Git. Она позволяет подключать внешние репозитории как подмодули в основной репозиторий. Это полезно, если вы хотите включить код из внешних источников, сохраняя его отдельно от основной кодовой базы.
Чтобы обновить подмодуль, выполните следующие шаги:
-
Перейдите в каталог подмодуля внутри основного репозитория.
-
Выполните
git fetch, чтобы получить последние изменения из удалённого репозитория подмодуля. -
Если хотите перейти на последний коммит отслеживаемой ветки подмодуля, используйте
git pull. -
Либо, чтобы переключиться на конкретный коммит или ветку, выполните
git checkoutс нужным хешем или именем ветки. -
После обновления подмодуля до нужного состояния закоммитьте изменения в основном репозитории, чтобы зафиксировать обновлённое состояние подмодуля.
Что такое git cherry-pick и когда его использовать?
git cherry-pick позволяет применить конкретный коммит из одной ветки к другой без слияния всей ветки.
git cherry-pick <commit-hash>
main, но это исправление нужно и в ветке release — вы можете выбрать только этот коммит, а не сливать всю ветку main в release.Это также полезно, если коммит по ошибке сделали не в ту ветку: перенесите его cherry-pick в правильную, а затем откатите там, где ему не место.
Что такое git bisect и для чего он нужен?
git bisect — это инструмент отладки, использующий двоичный поиск для нахождения конкретного коммита, в котором появился баг. Вместо ручной проверки коммитов по одному вы указываете Git, какой коммит «хороший» (без бага), а какой «плохой» (с багом), и Git будет последовательно переключать промежуточные коммиты, каждый раз деля область поиска пополам, пока не найдёт виновника.
git bisect start
git bisect bad # текущий коммит с багом
git bisect good <commit-hash> # этот более ранний коммит был исправен
# Git переключит промежуточный коммит; вы тестируете, затем:
git bisect good # или git bisect bad
# повторяйте, пока Git не найдёт первый «плохой» коммит
git bisect reset # по завершении вернуться к исходному состоянию
Это гораздо быстрее ручного поиска в крупных репозиториях со сотнями коммитов.
Что такое хуки Git (Git hooks) и как их использовать?
Хуки Git — это скрипты, которые автоматически запускаются в определённые моменты рабочего процесса Git. Они находятся в каталоге .git/hooks/ репозитория и могут быть написаны на любом скриптовом языке.
Есть два типа:
-
Клиентские хуки запускаются на вашей машине — например,
pre-commit(перед созданием коммита) илиcommit-msg(проверяет формат сообщения коммита). -
Серверные хуки запускаются на удалённом сервере — например,
pre-receive(до принятия отправленных коммитов).
Распространённый сценарий — использовать хук pre-commit для автоматического запуска линтера или тестов перед разрешением коммита. Это обеспечивает единые стандарты качества кода в команде.
Обратите внимание: хуки не копируются при клонировании репозитория, поэтому команды обычно распространяют их отдельным скриптом или с помощью инструмента вроде pre-commit (пакет Python).
Вопросы о часто путаемых концепциях Git
В чём разница между git fetch и git pull?
Основная разница между git fetch и git pull — в их действии и том, как они обновляют локальный репозиторий.
Команда git fetch получает изменения из удалённого репозитория в локальный. Она обновляет отслеживаемые удалённые ветки (например, origin/master) в локальном репозитории, но не меняет рабочий каталог и не сливает изменения в текущую ветку. После fetch вы можете изучить изменения на удалённой стороне, не затрагивая локальную работу.
Команда git pull также получает изменения из удалённого репозитория, но идёт дальше: она делает fetch и затем сразу сливает эти изменения в текущую ветку. По сути, это git fetch плюс git merge в одном шаге.
Что делает git reset?
Команда git reset переводит текущий HEAD в заданное состояние. Её используют для отмены изменений, снятия файлов со стадии или для перемещения указателя HEAD на другой коммит. Есть три основных режима git reset:
--soft: перемещает HEAD на указанный коммит, сохраняя изменения в индексе. Файлы остаются изменёнными в рабочем каталоге, вы можете их заново закоммитить.
--mixed: перемещает HEAD на указанный коммит, снимая изменения со стадии. Файлы остаются изменёнными в рабочем каталоге, но не подготовлены к коммиту.
--hard: перемещает HEAD на указанный коммит и отбрасывает все изменения в рабочем каталоге и индексе. Используйте с осторожностью: это навсегда удалит незафиксированные изменения.
Важно: Никогда не используйте git reset --hard для коммитов, уже отправленных в общую удалённую ветку. Это переписывает историю и создаст серьёзные проблемы коллегам, которые успели их получить. Для публичных коммитов используйте git revert.
Почему предпочтительнее git push --force-with-lease по сравнению с git push --force?
git push --force-with-lease — более осторожный способ принудительной отправки изменений, чем git push --force, поскольку он предотвращает случайное перезаписывание чужих изменений на удалённом репозитории.
При использовании git push --force вы принудительно отправляете свои изменения, независимо от того, обновлял ли кто‑то ещё ветку после вашего последнего fetch. Это может привести к потере чужой работы.
В отличие от этого, git push --force-with-lease безопаснее: он проверяет, не обновлялась ли удалённая ветка с момента вашего последнего fetch. Если обновлялась, отправка будет отклонена, и вы не перезапишете изменения коллег.
Что такое git rebase и чем он отличается от git merge?
И git rebase, и git merge интегрируют изменения из одной ветки в другую, но делают это по‑разному.
-
git mergeобъединяет истории двух веток, создавая новый «merge‑коммит». Это сохраняет полную историю расхождения и слияния веток, что полезно для аудита и прозрачности в команде. -
git rebaseпереносит (replay) коммиты из одной ветки поверх другой, формируя чистую линейную историю без merge‑коммитов. Лог становится проще для чтения, но история переписывается. Отсюда «золотое правило» rebase: никогда не перебазируйте ветку, над которой работают другие.
В чём разница между git clone и git fork?
Клонирование создаёт локальную копию удалённого репозитория на вашей машине. Вы остаётесь привязаны к тому же репозиторию и можете отправлять изменения обратно (если есть права).
git clone https://github.com/user/repo.git
Форк — стандартный рабочий процесс для вклада в open‑source‑проекты, где у вас нет прямого права записи в оригинальный репозиторий.
Подготовка к собеседованию по Git
Грамотная подача ваших знаний и опыта работы с Git на собеседовании важна, чтобы показать владение контролем версий и навыки командного взаимодействия в разработке ПО.
Вот несколько советов, которым стоит следовать при подготовке к техническому интервью, чтобы эффективно продемонстрировать навыки Git:
Понимайте основы Git
Убедитесь, что вы хорошо понимаете основы Git: репозитории, ветвление, слияние, коммиты и базовые команды — pull, push, clone, commit. Это фундамент вашей беседы на интервью. Полезно также разбираться в принципах контроля версий и различиях между Git и другими системами контроля версий.
Наконец, познакомьтесь с различными методологиями Git — Git Flow, GitHub Flow и GitLab Flow. Оцените плюсы и минусы каждого подхода и поймите, когда какой лучше применять.
Наш полный гид по Git — хорошая отправная точка для изучения основ.
Получайте практический опыт
Чем больше вы пользуетесь Git, тем крепче закрепляются знания. Регулярная практика повышает уверенность в командах и процедурах. Старайтесь включать Git в повседневный рабочий процесс. Экспериментируйте с созданием веток, их слиянием и разрешением конфликтов.
Если вы не уверены, над какими проектами работать для практики Git, участие в open‑source‑проектах на платформах вроде GitHub — отличный способ получить реальный опыт инструментов и процессов командной разработки.
Изучайте типичные проблемы и способы их решения
При работе с Git проблемы неизбежны. Часто встречаются конфликты слияния, состояние detached HEAD, откат изменений и восстановление потерянных коммитов. Диагностика проблем развивает навыки отладки и помогает глубже понять внутренние механизмы Git.
Активно разбирая ошибки и сообщения, вы лучше поймёте, как работает Git, и научитесь эффективно выявлять и устранять неполадки. Такой подход снижает риски и повышает уверенность и мастерство в управлении рабочими процессами контроля версий.
Практикуйте пробные интервью
Пробные интервью помогают выявить пробелы в знаниях Git и навыках коммуникации, чтобы направить подготовку в нужное русло.
Они также дают возможность отточить решение задач — разбирать реалистичные сценарии и упражнения по Git. Такая практика укрепляет уверенность в своих навыках и улучшает умение чётко излагать мысли на собеседовании.
Заключение
Git — мощная система контроля версий, широко используемая в разработке для управления изменениями кода, совместной работы и ведения истории проекта. Знание Git важно на технических собеседованиях: оно демонстрирует владение ключевыми инструментами и процессами, умение сотрудничать и эффективно управлять кодом в команде.
Понимание концепций и команд Git позволяет выстроить эффективный контроль версий, обеспечивая целостность кода, непрерывность проекта и более стройные процессы разработки. Поэтому знание Git бесценно для начинающих инженеров и разработчиков, проходящих технические интервью и строящих карьеру.
Для дальнейшего изучения посмотрите следующие материалы: