Что такое Git

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

Короткий ответ на интервью может звучать так:

Git это распределенная система контроля версий. Она помогает отслеживать изменения в коде, работать параллельно в ветках, объединять изменения команды и синхронизировать локальную историю с удаленным репозиторием.

Слово распределенная важно. У вас есть локальная копия репозитория с историей, поэтому можно делать commit, создавать ветки и смотреть историю без постоянного подключения к серверу. Сервер нужен, чтобы обмениваться изменениями с командой.

Не начинайте с редких команд. Сначала дайте определение, затем покажите рабочий цикл и только потом добавляйте нюансы. Так ответ звучит уверенно и не превращается в список команд без смысла.

Хорошая структура ответа:

1. Git хранит историю изменений.
2. Он распределенный и работает локально.
3. Основной цикл: изменить файлы, выбрать изменения, сделать commit, отправить ветку.
4. Для команды важны ветки, pull request, merge и решение конфликтов.
5. Аккуратность нужна, чтобы не потерять чужие изменения, не добавить секреты и не сломать сборку.

Если у вас был реальный опыт, добавьте один короткий пример. Например: в проекте я работал через feature-ветки, открывал pull request, исправлял замечания и перед merge проверял diff, тесты и конфликты. Замените детали на свои. Не выдумывайте процессы, которых у вас не было.

В базовом сценарии Git проходит несколько состояний. Сначала вы меняете файлы в рабочей директории. Затем выбираете изменения для коммита через staging area. После этого создаете commit, а потом синхронизируете ветку с удаленным репозиторием.

git status
git diff
git add src/components/Button.tsx
git commit -m "Fix button loading state"
git push origin feature/button-loading

Практический смысл здесь не в запоминании команд. Важно показать, что вы контролируете, какие изменения попадают в историю. Перед git add и git commit стоит смотреть git status и git diff, иначе легко отправить временный лог, лишний файл или случайную правку конфигурации.

Git сам по себе не равен GitHub. Git работает локально. GitHub, GitLab или Bitbucket обычно хранят удаленную копию репозитория и добавляют командные инструменты: pull request, code review, права доступа, issues и запуск CI.

Корректная формулировка: я делаю коммиты локально, затем отправляю ветку в удаленный репозиторий через push, открываю pull request и после ревью изменения попадают в основную ветку.

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

Во frontend Git часто пересекается с файлами, где ошибка заметна не сразу. Конфликт в JSX может собрать проект, но сломать состояние компонента, обработку loading или error, фокус после открытия модального окна или очистку эффекта. Изменение lockfile может поменять версии зависимостей у всей команды и дать другой bundle. Случайно добавленный .env может привести к утечке токенов.

Поэтому в ответе полезно сказать не только, что вы знаете commit, branch и merge. Добавьте, что вы проверяете diff, не коммитите секреты, разбираете конфликты по смыслу и не переписываете общую историю без согласования. Это показывает практическую зрелость.

Ветка в Git это указатель на коммит. Благодаря этому ветки дешевые, и команда может вести несколько задач параллельно. Обычно frontend-разработчик создает feature-ветку, делает изменения, отправляет ее в удаленный репозиторий и открывает pull request.

Конфликт возникает, когда Git не может сам понять, как объединить изменения. Например, два разработчика поменяли один и тот же компонент или один переименовал файл, а другой изменил его содержимое. В такой ситуации нужно собрать правильное итоговое состояние, удалить конфликтные маркеры, проверить UI и завершить merge.

// Плохой подход: выбрать всю свою версию и не проверить чужую правку.
// Риск: вы потеряете исправление бага, обработку error/loading,
// cleanup в useEffect или изменение контракта props.

Что может сломаться: компонент отправит лишний запрос, покажет устаревшее состояние, потеряет фокус или перестанет обрабатывать ошибку. Безопаснее открыть конфликтный файл, понять, какие изменения пришли из каждой ветки, при необходимости спросить автора соседней правки и проверить итоговый сценарий в приложении. Если конфликт затронул запросы или эффекты, проверьте отмену запроса и cleanup.

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

Если вас спрашивают про rebase или force push, не отвечайте категорично. Лучше сказать: для своей ветки я могу использовать rebase, если это принято в команде. Общую ветку не переписываю, потому что это может сломать историю у других разработчиков.

Сильный ответ на вопрос Что такое Git не должен быть длинной лекцией. Достаточно показать три уровня понимания: что это за инструмент, как вы им пользуетесь в обычной задаче и какие риски контролируете в команде.

Короткая версия для интервью:

Git это распределенная система контроля версий. Она хранит историю изменений, дает работать в ветках и объединять изменения команды. В обычной задаче я создаю ветку, делаю осмысленные коммиты, проверяю diff, отправляю ветку в удаленный репозиторий и прохожу review. Отдельно слежу за конфликтами, секретами, lockfile и тем, чтобы не переписывать общую историю без договоренности.