Контроль версий (Version Control)

Контроль версий (или контроль исходного кода) — это система для записи изменений в наборе файлов с течением времени так, чтобы конкретные версии можно было позже вспомнить, сравнить и восстановить, и чтобы несколько человек могли работать над одной кодовой базой, не перезаписывая работу друг друга. Git сегодня является доминирующей распределённой системой контроля версий (заменив для большинства новых проектов более старые централизованные системы, такие как Subversion и CVS), обычно размещаемой на платформах вроде GitHub, GitLab или Bitbucket. Почему это важно для создателей AI/SaaS-продуктов: контроль версий — это субстрат, на котором держится всё остальное в современной цепочке инструментов разработки — CI/CD запускается коммитами и pull request'ами, код-ревью происходит по дифам, развёртывания привязаны к конкретным коммитам/тегам, так что вы всегда можете ответить на вопрос «какой именно код сейчас работает в продакшне», а откаты — это просто «развернуть предыдущий коммит». Без этого совместная работа практически невозможна за пределами одного разработчика, а восстановление после плохого изменения означает ручную археологию вместо `git revert`. Как это работает: система контроля версий хранит полную историю проекта как последовательность коммитов, каждый из которых представляет собой снимок файлов в этот момент плюс метаданные (автор, временная метка, сообщение и указатель на родительский коммит(ы)). Распределённые системы, такие как Git, дают каждому разработчику полную копию всей истории локально, поэтому большинство операций (просмотр истории, создание веток, коммит) происходят мгновенно и офлайн; синхронизация с другими происходит через явные push/pull к общему удалённому репозиторию. Ветвление позволяет разрабатывать функцию изолированно от стабильной ветки `main`; слияние объединяет эту работу обратно, при этом система автоматически комбинирует неконфликтующие изменения и отмечает конфликты для разрешения человеком. Практический пример: разработчик хочет добавить тёмную тему в SaaS-дашборд. Он выполняет `git checkout -b feature/dark-mode`, чтобы создать новую ветку от `main`, вносит изменения в пять файлов и коммитит их постепенно с помощью `git commit -m "add theme context provider"` и `git commit -m "wire dark mode toggle into settings page"`. Тем временем коллега сливает несвязанное исправление в `main`. Разработчик выполняет `git pull origin main` (или делает rebase), Git автоматически сливает несвязанные изменения, поскольку они затронули разные файлы, он отправляет свою ветку и открывает pull request, и после ревью она сливается в `main` — полная история каждого промежуточного коммита остаётся доступной для изучения навсегда через `git log`. Шесть месяцев спустя, если в функции тёмной темы обнаружится баг, любой в команде может точно проследить, какой коммит его внёс и что ещё изменилось вместе с ним, не полагаясь на чью-либо память о произошедшем.