Git-воркфлоу, история и CI/CD

Как только над репозиторием работает больше одного человека, центральным становится не commit, а история и процесс вливания изменений. Здесь Git из инструмента сохранения превращается в инструмент совместной работы — со своими острыми гранями. Переписывание истории (rebase, amend) удобно локально и опасно на общей ветке. Инструменты спасения (reflog, bisect, cherry-pick) вытаскивают из ситуаций, которые выглядят как катастрофа. А CI/CD автоматизирует то, что раньше делали руками: проверку, сборку и доставку.

Главный принцип, вокруг которого крутятся все эти темы: любая операция, меняющая SHA коммита, безопасна только пока коммит приватный. rebase, amend, cherry-pick создают новые коммиты с новыми хешами; старые становятся недостижимы. Локально это чистка перед push. На ветке, которую уже кто-то забрал к себе, это диверсия — чужая история расходится с вашей. Понимание этого разделяет «до push» и «после push» и делает предсказуемым весь командный процесс. Полная карта — в слоях ниже.

Карта темы

• Rebase против merge — как rebase переносит коммиты и меняет SHA, чем отличается от merge, почему опасен на общей ветке.
• Переписывание истории — amend, fixup, интерактивный rebase; почему это требует force-push и когда допустимо.
• Инструменты спасения — reflog, bisect, cherry-pick, git hooks; как вернуть «потерянное» и найти сломавший коммит.
• Командный процесс — жизненный цикл pull request, Conventional Commits, аннотированные vs lightweight теги, стратегии ветвления.
• CI/CD — что такое непрерывная интеграция и доставка, из чего состоит пайплайн, какие гарантии он даёт.
• Сабмодули и монорепо — как git submodule закрепляет зависимость на коммите, альтернативы, монорепо против полирепо.

Частые ошибки и ловушки

Значение для собеседований

Здесь интервьюер проверяет зрелость работы в команде. Ключевой водораздел — понимает ли кандидат, что операции переписывания истории безопасны только до публикации коммита. Ответ «rebase лучше, потому что история линейная» без оговорки про общую ветку — тревожный сигнал.

Что обычно проверяют:

• rebase vs merge — как каждый влияет на форму истории и SHA, и почему rebase общей ветки опасен.
• Что делают amend и fixup и почему после них нужен force-push.
• Как reflog спасает «потерянные» коммиты и почему это не бэкап.
• git bisect для поиска сломавшего коммита за O(log n) шагов.
• Чем cherry-pick отличается от merge/rebase и когда он уместен.
• Жизненный цикл pull request и что делает его удобным для ревью.
• Что такое CI/CD и какие гарантии даёт пайплайн.

Типичный неверный ответ: «Всегда делай rebase вместо merge — история чище». Это открывает разговор о том, что rebase переписывает SHA, а значит недопустим на ветке, которую уже забрали коллеги — там нужен merge.