Зачем инженеру Git в 2026 году, если у всех и так всё работает

У большинства из нас Git живёт на уровне пяти команд: clone, add, commit, push, pull. И этого правда хватает. До первого конфликта посреди rebase, когда терминал пишет что-то про detached HEAD, а в файле появляются странные <<<<<<< и >>>>>>>. До git push --force, после которого коллега спрашивает в чате, куда делись его три дня работы.

Дальше у многих один сценарий: гугл, первая подходящая команда со Stack Overflow, а если не помогло, то rm -rf и свежий clone. Работает, но ощущение, что идёшь по минному полю с завязанными глазами, никуда не девается.

Обычная продуктовая команда, пятница, 18:40. Мониторинг краснеет, сервис отвечает ошибками, а безопасники пишут, что у одной из виртуалок наружу открыт 22 порт. И в репозиторий лезут сразу все:

• Инфраструктурщик. Инфраструктура описана в Terraform, значит, её история это история коммитов. git log по модулю и git blame на строке с 0.0.0.0/0 за минуту показывают, кто и зачем открыл доступ. Откат делается через git revert и тоже остаётся в истории, с автором и причиной.
• GitOps-инженер. Деплой идёт через Argo CD: merge в нужную ветку это выкатка, а revert этого merge это откат. Но если с утра кто-то сделал rebase общей ветки и переписал историю, придётся разбираться, что откатывать. В GitOps разница между merge и rebase перестаёт быть вопросом с собеседования, потому что ошибка ломает уже не свою ветку, а прод.
• Тестировщица. Ей нужно найти ревизию, на которой появился баг, собрать её и воспроизвести. Если коммиты внятные, а теги стоят по SemVer, это десять минут. Если в истории сорок коммитов с текстом «fix» и «wip», это целый вечер.
• Техписатель. Документация лежит в git рядом с кодом и проходит то же ревью, поэтому в понедельник никто не гадает, какая версия runbook правильная.
• ML-инженер. Модели и датасеты на Hugging Face это обычные git-репозитории с Git LFS, и ответ на вопрос «на чём учили модель» лежит в истории коммитов.

Ни один из этих пятерых не пишет продуктовый код, и все работают с Git каждый день.

В 2026 году в репозиторий пишет не только человек. Кодинг-агенты заводят ветки, делают серии коммитов и приносят pull request, иногда по два параллельно и в соседние файлы. Код появляется быстрее, а всё остальное остаётся на человеке: прочитать diff, разрулить конфликт, откатить то, что агент натворил в три часа ночи, и не потерять нормальные изменения.

Чем больше изменений генерирует машина, тем дороже стоит умение работать с историей. reflog возвращает «удалённый» коммит. После reset не страшно. Интерактивный rebase превращает двадцать коммитов агента в три понятных перед ревью. Это навыки того, кто отвечает за результат.

Многие знакомятся с Git через GitHub и привыкают считать их одним целым. На самом деле Git распределённый: каждый клон хранит полную историю, а сервером может быть любая машина, до которой есть SSH. Свой bare-репозиторий поднимается за несколько минут без внешних платформ. Узнавать об этом лучше заранее, а не в день, когда доступ к сервису закончился внезапно.

Мы хотели, чтобы после курса Git перестал быть набором заклинаний и стал понятным инструментом.

Начинаем с устройства: blob, tree, commit, tag, граф коммитов и SHA. Когда видишь, что ветка это просто указатель на коммит, а коммит никуда не девается после reset, команды перестают казаться опасными. Потом переходим к ежедневной работе: Conventional Commits, SemVer, ветки, rebase, конфликты, reset, restore, revert, reflog, cherry-pick и чистка истории перед pull request. Ближе к концу поднимаем собственный git-сервер по SSH, разбираем, как делать PR, который приятно ревьюить, и сравниваем Git Flow, GitHub Flow и trunk-based. Для тех, кто автоматизирует, есть работа с Git из Python через GitPython.

Формат рассчитан на тех, кто работает: 2–3 часа в будний день, короткие скринкасты и статьи на 5–15 минут. Каждый день заканчивается практикой, куратор её проверяет и даёт обратную связь.

В конце студенты собираются в команды и получают проект: рабочий MVP и бэклог готовых изменений. Один становится мейнтейнером, остальные переносят изменения в свои ветки и оформляют merge request. Дальше всё как в жизни: ревью друг друга, конфликты, договорённость о флоу и релизный тег. Писать код не нужно. Проекты взяты из инженерной жизни: nginx с TLS, Terraform-модуль для EC2, ротатор бэкапов, docker-стек, сервис коротких ссылок, API на Go. Язык проекта на результат не влияет.