Система контроля версий: что это, какие бывают и как начать с Git

Система контроля версий (VCS, version control system) — программа, которая хранит историю изменений файлов проекта: что изменилось, кто и когда это сделал. Она позволяет вернуться к прежнему состоянию и объединять работу нескольких людей без ручного копирования папок.

Ниже — виды систем, сравнение Git, SVN и Mercurial и базовый цикл Git от первого коммита до конфликта слияния. Примеры проверены на Git 2.43 (Linux) и 2.50 (macOS) 23 сентября 2026 года.

Мини-словарь: четыре слова, которые путают

• Репозиторий — хранилище проекта вместе с историей. В Git это скрытая папка .git внутри каталога проекта.
• Коммит — зафиксированное состояние проекта с автором, датой и сообщением. Из коммитов складывается история.
• Ветка — именованная линия разработки, указатель на последний коммит этой линии.
• Слияние (merge) — объединение изменений из двух веток в одну.

И еще пара: Git — программа контроля версий, а GitHub и GitLab — сервисы для удаленных копий Git-репозиториев и обсуждения изменений. Git работает и без них.

Зачем нужен контроль версий

Без VCS история проекта живет в именах файлов вроде report_final_2.docx, а работа вдвоем над одним файлом заканчивается перезаписью чужих правок. VCS показывает построчную разницу между версиями, позволяет отменить неудачное изменение, вести параллельные ветки и хранит автора и причину каждой правки.

Граница: VCS не заменяет резервное копирование. Репозиторий на единственном диске пропадет вместе с диском, поэтому историю держат еще и в удаленной копии.

Виды систем контроля версий

Централизованной системе нужен доступ к серверу, не обязательно к интернету: сервер может стоять в локальной сети. В распределенной коммиты и ветки работают офлайн, сеть нужна для обмена (git push, git pull). Оговорка: git clone --depth 1 дает неполную копию без старой истории, так делают в CI ради скорости.

Git, Subversion и Mercurial: что выбрать

Как выбирать. Новый проект или первое знакомство — Git: на нем работают GitHub, GitLab, CI/CD и большинство команд. SVN остается там, где он уже внедрен, и там, где много больших бинарных файлов: блокировка не дает двоим одновременно править одну текстуру. Mercurial берут, если он уже используется в проекте.

Сам Git хранит любые файлы, но не умеет сливать изображения или видео, а каждая версия большого файла раздувает историю. Расширение Git LFS (не Git по умолчанию) заменяет такие файлы указателями, а содержимое держит на отдельном сервере.

Как Git хранит изменения: три области

Файл в Git проходит три места: рабочий каталог (файлы, которые вы редактируете) -> индекс, или staging (то, что войдет в следующий коммит) -> коммит (зафиксированное состояние). Команда git add переносит изменение в индекс, git commit фиксирует индекс.

Упрощенно коммит — снимок всего проекта. Точнее: коммит ссылается на полное дерево файлов, но неизмененные файлы не копируются, а переиспользуются из прошлых коммитов.

Базовый цикл Git: полный пример

Скрипт создает репозиторий, делает коммит, ведет изменение в ветке и вливает его в main. Запуск — в bash (Linux, macOS, Git Bash на Windows) в пустой папке.

mkdir hello && cd hello
git init -b main
git config user.name "Anna"
git config user.email "anna@example.com"

echo "Привет" > greeting.txt
git status --short
git add greeting.txt
git status --short
git commit -m "Первая версия приветствия"

git switch -c feature
echo "Пока" >> greeting.txt
git commit -am "Добавлено прощание"

git switch main
git merge feature
git log --oneline --graph --format="%s"
cat greeting.txt

Главное в выводе (хеши коммитов у вас будут другими):

?? greeting.txt
A  greeting.txt
[main (root-commit) 1e5a239] Первая версия приветствия
Switched to a new branch 'feature'
[feature 3639034] Добавлено прощание
Switched to branch 'main'
Updating 1e5a239..3639034
Fast-forward
* Добавлено прощание
* Первая версия приветствия
Привет
Пока

Разбор по шагам:

Конфликт слияния: ошибка и исправление

Конфликт возникает, когда две ветки по-разному изменили одну и ту же строку. Продолжим тот же репозиторий:

git switch -c polite
printf 'Здравствуйте\nПока\n' > greeting.txt
git commit -qam "Вежливое приветствие"
git switch main
printf 'Привет всем\nПока\n' > greeting.txt
git commit -qam "Приветствие для всех"
git merge polite
cat greeting.txt

Фактический результат:

CONFLICT (content): Merge conflict in greeting.txt
Automatic merge failed; fix conflicts and then commit the result.
<<<<<<< HEAD
Привет всем
=======
Здравствуйте
>>>>>>> polite
Пока

Выше ======= версия текущей ветки, ниже — вливаемой. Исправление — оставить нужный текст без маркеров и закоммитить:

printf 'Здравствуйте, все\nПока\n' > greeting.txt
git add greeting.txt
git commit -m "Слияние веток main и polite"
git log --oneline --graph --format="%s"

*   Слияние веток main и polite
|\
| * Вежливое приветствие
* | Приветствие для всех
|/
* Добавлено прощание
* Первая версия приветствия

Как вернуться к прежней версии

Для коммитов, уже отправленных в общий репозиторий, безопаснее git revert. Команда git reset переписывает историю и годится только для локальных коммитов, которые еще никто не забрал.

Секреты и .gitignore

Пароли, токены и файлы .env не должны попадать в репозиторий. Список исключений пишут в .gitignore до первого коммита:

echo "API_KEY=secret123" > .env
printf '.env\n' > .gitignore
git status --short
git check-ignore -v .env

?? .gitignore
.gitignore:1:.env   .env

check-ignore подтверждает, какое правило скрыло .env. Если секрет уже закоммичен и отправлен, удаление файла новым коммитом не помогает: он остается в истории и в чужих копиях. Ключ нужно отозвать и выпустить новый, чистка истории — только дополнительная мера.

Если не получилось

Дальше: удаленный репозиторий на GitHub или GitLab, git push и git pull, затем pull request (в GitLab — merge request) с ревью. Цель — свой репозиторий с осмысленной историей, влитой веткой и разрешенным конфликтом. Подробно о фиксации изменений, правке сообщения и составе коммита — в статье git commit: как сделать коммит в Git.

Выводы

• Система контроля версий хранит историю изменений, дает откатиться и объединять работу нескольких людей; резервное копирование она не заменяет.
• Централизованным (SVN) для коммита нужен сервер, распределенные (Git, Mercurial) держат полную историю у каждого участника и работают офлайн.
• Для нового проекта обычно выбирают Git; SVN остается там, где он внедрен или нужна блокировка больших бинарных файлов.
• Базовый цикл Git: init -> add -> commit -> switch -c -> merge; конфликт решается правкой файла, add и commit.
• Отменять опубликованные коммиты безопаснее через git revert, а секреты держать в .gitignore с первого коммита.

Где применяется / связь с практикой

FAQ

Можно ли хранить в Git не код, а документы?
Да, но построчное сравнение и слияние работают для текстовых форматов (Markdown, CSV, конфиги). Версии .docx и изображений Git сохранит, но автоматически слить правки не сможет.

Delta Lake — это аналог Git?
Нет. Delta Lake — формат таблиц для озер данных с транзакциями и доступом к прошлым версиям таблицы, а не система контроля версий исходного кода.

Стоит ли изучать SVN в 2026 году?
Отдельно — только если он используется на проекте, куда вы идете. Базовые понятия (коммит, ветка, слияние, конфликт) переносятся, поэтому при переходе с Git на SVN осваивать нужно в основном команды и работу с центральным сервером.