Разбор сложных вопросов по Git: внутреннее устройство, стратегии слияния, работа с LFS и восстановление данных. Подготовьтесь к интервью.
Git — это контентно-адресуемая файловая система. На собеседованиях уровня Senior важно понимать, что происходит в директории .git при выполнении команд. Основные типы объектов в Git: blob (содержимое файла), tree (структура директорий), commit (метаданные и ссылка на дерево) и tag.
Git использует SHA-1 (или SHA-256 в новых версиях, что стало актуально к 2026 году для защиты от коллизий). Хеш генерируется на основе содержимого объекта. Если два файла в разных ветках идентичны, Git сохранит только один blob, экономя место.
Это классический вопрос, где проверяют не только знание синтаксиса, но и понимание чистоты истории коммитов.
Главное правило: никогда не делайте rebase публичных веток (main/master/develop). Это меняет хеши коммитов, что заставляет других разработчиков вручную исправлять расхождения в своих локальных копиях.
С версии 2.34 стратегией по умолчанию стала ort (Ostensibly Recursive’s Twin). Она быстрее и корректнее обрабатывает переименования файлов. На собеседовании могут спросить, как Git понимает, что файл был переименован, а не удален и создан заново. Ответ: Git не хранит метаданные о переименовании, он вычисляет сходство контента (similarity index) между удаленными и добавленными файлами во время операции слияния.
В 2026 году работа с ML-моделями и тяжелыми ассетами требует использования Git LFS. Вместо больших файлов в репозитории хранятся текстовые указатели (pointers), а сами данные лежат на удаленном сервере. Также стоит упомянуть Scalar — инструмент от Microsoft, интегрированный в Git, который оптимизирует работу с гигантскими монорепозиториями через частичное клонирование (partial clone) и разреженные индексы (sparse-checkout).
«Я сделал hard reset и потерял коммиты, что делать?» — стандартная проверка на стрессоустойчивость. Ответ: git reflog. Git хранит историю перемещения указателя HEAD в течение 30-90 дней (по умолчанию). Даже если ветка удалена, коммиты остаются в базе объектов, пока не отработает сборщик мусора (garbage collector).
Cherry-pick полезен для переноса конкретного фикса из одной ветки в другую без полного слияния. Squash используется при слиянии Pull Request, чтобы объединить 20 промежуточных коммитов («fix typo», «add logs») в один осмысленный функциональный блок. Это стандарт де-факто в современных CI/CD процессах.
Опытный разработчик должен знать про git hooks. В 2026 году практически в любом проекте настроены pre-commit хуки для запуска линтеров и тестов. Важно упомянуть, что хуки не пушатся в репозиторий автоматически, для их синхронизации в команде используют такие инструменты, как Husky (для JS) или Lefthook (универсальный).
Это коммиты, на которые не ссылается ни одна ветка или тег. Обычно появляются после `git commit --amend`, `rebase` или удаления веток. Они не удаляются мгновенно, а хранятся в базе до запуска `git gc`.
`git fetch` загружает изменения с сервера в локальные ветки отслеживания (например, origin/main), но не меняет состояние вашего рабочего каталога. `git pull` — это комбинация `fetch` и последующего `merge` (или `rebase`, если настроено). На больших проектах безопаснее использовать fetch + merge.
Формально в Git нет такого понятия. Git не умеет отслеживать пустые папки. `.gitkeep` — это соглашение сообщества: создание пустого файла с таким именем позволяет закоммитить директорию, которая иначе была бы проигнорирована.
Если ветка общая, лучше использовать `git revert`. Это создаст новый коммит, отменяющий изменения старого, не переписывая историю. Если вы работаете один и уверены в безопасности, можно использовать `git reset --hard` и `git push --force-with-lease`.
