Контроль версий
Git — это распределённая система контроля версий: она хранит историю проекта как цепочку коммитов-снимков, у каждого есть родитель. Полная копия репозитория лежит локально, поэтому почти все операции — коммит, ветвление, просмотр истории — работают без сервера. Это и делает Git основой командной разработки: изолированные ветки, параллельная работа, управляемое слияние.
Тема выстроена от базы к операциям, вокруг которых больше всего путаницы. Первая линия — удалённая работа: fetch только скачивает, pull ещё и вливает — смешивать их опасно. Вторая — интеграция: merge сохраняет реальный граф, rebase переписывает историю в линейную, и золотое правило — не переписывать уже опубликованное. Третья — точечные операции вроде cherry-pick для переноса одного исправления. Разбор — в слоях ниже.
Карта темы
- Основы Git — коммит-снимок, родитель, ветка и распределённая природа локальной копии.
- Fetch против pull — чем скачивание отличается от скачивания со слиянием и что такое submodule.
- Модель ветвления — git-flow, trunk-based и зачем команде соглашение о ветках.
- Merge против rebase — нелинейный граф против линейной истории и золотое правило rebase.
- Rebase и интерактивный режим — перенос коммитов на новую базу, squash, reword и чистка ветки.
- Cherry-pick — перенос одного коммита между ветками с новым хешем, backport hotfix.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Считать Git «облаком с последней версией файла» | Теряется вся модель истории, веток и снимков |
Путать fetch и pull | pull неожиданно вливает и меняет рабочую ветку |
| Rebase уже опубликованных общих коммитов | Переписанная история заставляет коллег восстанавливаться |
Думать, что rebase сохраняет реальный граф | rebase переписывает коммиты с новыми хешами — история линейна |
Считать, что cherry-pick переносит коммит с тем же хешем | Создаётся новый коммит с новым хешем |
| Отсутствие соглашения о ветках | Хаос: непонятно, где начинается работа и как правки идут в прод |
Значение для собеседований
Git спрашивают как проверку командной дисциплины: понимаете ли вы, что безопасно делать на общей ветке. Кандидат, который называет золотое правило — «не rebase-ить опубликованное» — и объясняет разницу графа merge и линейной истории rebase, показывает, что работал в команде, а не только коммитил в одиночку.
Что обычно проверяют:
- Что такое Git и коммит; почему система распределённая.
- Разница
fetchиpull; зачем сначала смотреть, потом вливать. mergeпротивrebaseи когда rebase опасен.- Точечные операции:
cherry-pickдля backport, интерактивный rebase для чистки.
Типичный неверный ответ: «rebase всегда лучше merge, история чище». На общих ветках rebase переписывает опубликованные коммиты и ломает работу коллегам — чистота истории не стоит сломанного графа у всей команды.