Git

Git — это распределённая система контроля версий, созданная Линусом Торвальдсом в 2005 году (изначально для управления исходным кодом ядра Linux), которая стала фактическим стандартом для отслеживания изменений в программных проектах. «Распределённость» — ключевое архитектурное отличие от более старых систем: локальный клон каждого разработчика содержит всю историю проекта, а не только последний снимок, что делает большинство операций быстрыми и работающими офлайн, а также делает систему устойчивой (нет единой точки отказа — любой клон может восстановить полную историю). Сам Git — это лишь базовый движок; платформы вроде GitHub, GitLab и Bitbucket добавляют поверх него хостинг, pull request'ы, отслеживание задач и CI/CD. Почему это важно для создателей AI/SaaS-продуктов: Git фактически является обязательной инфраструктурой — почти каждая система CI/CD, рабочий процесс код-ревью и конвейер развёртывания предполагают Git в основе, а AI-агенты для написания кода (Claude Code, Copilot, Cursor) все работают, читая и записывая Git-репозитории и генерируя коммиты/дифы. Владение базовыми концепциями Git (коммиты, ветки, слияния, rebase) стало почти базовым требованием для любого технического участника современной кодовой базы. Как это работает: Git отслеживает содержимое как граф неизменяемых, адресуемых по содержимому объектов — каждый коммит идентифицируется хешем SHA-1/SHA-256 своего содержимого и метаданных и указывает на дерево файлов на момент этого снимка плюс на свой родительский коммит(ы). Ветка — это просто перемещаемый указатель на коммит; «переключение» (checkout) на ветку обновляет ваши рабочие файлы в соответствии со снимком этого коммита. Распространённые команды: `git add` индексирует изменения, `git commit` фиксирует их снимком, `git branch`/`git checkout -b` создаёт ветки и переключается между ними, `git merge` объединяет истории веток, `git rebase` переигрывает коммиты на новой базе для линейной истории, а `git push`/`git pull` синхронизируются с удалённым репозиторием. Практический пример: разработчик, исправляющий баг, запускает `git log --oneline -- src/auth.js`, чтобы увидеть каждый коммит, затронувший файл авторизации, находит коммит, вызвавший регрессию, и запускает `git show a1b2c3d`, чтобы увидеть точно, что изменилось. Он подтверждает, что это виновник, а затем либо аккуратно откатывает изменение с помощью `git revert a1b2c3d` (создавая новый коммит, отменяющий изменение и сохраняющий историю), либо переносит исправление из другой ветки с помощью `git cherry-pick f4e5d6c`. Поскольку клон каждого коллеги содержит ту же полную историю, любой в команде может провести то же расследование самостоятельно, не нуждаясь в специальном доступе к серверу — без обращения в центральную операционную команду, без ожидания серверных разрешений, просто локальная команда Git, отвечающая на вопрос за секунды.