Каждый разработчик рано или поздно задаётся вопросами: «что я поменял вчера, после чего всё сломалось?», «как вернуть версию, которая работала на прошлой неделе?», «как вдвоём править один проект и не затирать чужую работу?». На них отвечает система контроля версий (Version Control System, VCS) — программа, которая хранит историю всех изменений проекта. Стандарт индустрии сегодня — Git: его используют почти все компании, и умение работать с ним проверяют на любом собеседовании.
Проблема «final_v2_final»
Без контроля версий папка проекта со временем начинает выглядеть так:
my-site/
├── index.html
├── index_old.html
├── index_backup_12_09.html
├── index_final.html
├── index_final_v2.html
├── index_final_v2_FINAL.html
└── index_final_v2_FINAL_Murad_fixes.htmlНепонятно, какая версия актуальная и чем копии отличаются, кто и зачем внёс правку. Вернуться можно только к копии, которую вы не забыли сделать, а вдвоём приходится пересылать архивы и вручную переносить чужие изменения.
Система контроля версий решает это иначе: в папке остаётся один index.html, а история хранится отдельно. Каждая сохранённая точка истории называется коммит (commit). Коммит содержит состояние файлов, автора, дату и сообщение — что и зачем изменено:
Коммит 3 Aysel 12.09 «Добавить форму обратной связи»
Коммит 2 Murad 10.09 «Исправить меню на мобильных»
Коммит 1 Aysel 08.09 «Создать структуру сайта»Проект вместе с базой всей его истории называется репозиторий (repository, «репо»).
Локальные, централизованные и распределённые системы
Локальные VCS (например, RCS, 1982 год) хранили историю на одном компьютере: работать вместе неудобно, а поломка диска уничтожала всё.
Централизованные системы (CVS, SVN, Perforce) держат полную историю на одном сервере, а разработчики получают с него только текущую версию файлов. Без сети нельзя ни сохранить изменение в историю, ни посмотреть её; если сервер недоступен, стоит вся команда. SVN (Subversion) до сих пор встречается в старых корпоративных проектах и в геймдеве.
Распределённые системы (Git, Mercurial) дают каждому разработчику полную копию репозитория со всей историей. Коммитить, смотреть историю и создавать ветки можно без интернета, а сервер нужен только для обмена изменениями. Если сервер пропадёт, историю можно восстановить с компьютера любого участника.
Централизованная (SVN) Распределённая (Git)
[ Сервер ] [ Сервер ]
(история) (история)
/ | \ / | \
[Aysel] [Murad] [Leyla] [Aysel] [Murad] [Leyla]
файлы файлы файлы история история история
+ файлы + файлы + файлыСнимки вместо списка разниц
Многие старые системы хранят первую версию файла и затем цепочку изменений к ней. Git мыслит снимками (snapshots): при каждом коммите он запоминает, как выглядел весь проект целиком. Чтобы не тратить место, неизменённые файлы не копируются — новый снимок просто ссылается на уже сохранённую версию.
index.html style.css app.js
Коммит 1 → index v1 style v1 app v1
Коммит 2 → index v2 style v1 ↺ app v1 ↺
Коммит 3 → index v2 ↺ style v2 app v1 ↺
↺ — файл не менялся: Git не копирует его, а ссылается на сохранённую версиюПоэтому любую версию проекта можно получить целиком и быстро, а каждый снимок защищён контрольной суммой — хешем вида 9d03f5a…: если данные повреждены, Git это заметит. Подробности — в разделе «Git изнутри».
Git — это не GitHub
Git — программа, которая работает на вашем компьютере. Её создал Линус Торвальдс в 2005 году для разработки ядра Linux. Git бесплатный, открытый и работает без интернета и аккаунтов.
GitHub, GitLab и Bitbucket — онлайн-сервисы (хостинги), где хранятся копии Git-репозиториев. Они добавляют инструменты для команд: pull requests, code review, задачи (issues), CI/CD.
| Инструмент | Что это | Главное назначение |
|---|---|---|
| Git | программа на вашем компьютере | история, коммиты, ветки |
| GitHub | веб-сервис (принадлежит Microsoft) | хостинг, pull requests, GitHub Actions, open source |
| GitLab | веб-сервис, можно развернуть на своём сервере | хостинг, встроенный CI/CD |
| Bitbucket | веб-сервис компании Atlassian | хостинг, интеграция с Jira |
Аналогия: Git — фотоаппарат, который делает снимки проекта, а GitHub — облачный альбом, где их обсуждают с командой. Фотографировать можно и без альбома.
💡 Вопрос «чем Git отличается от GitHub?» часто задают на собеседованиях. Короткий ответ: Git — инструмент контроля версий, GitHub — сервис для хранения репозиториев и совместной работы на основе Git.
История проекта как машина времени
Так выглядит история небольшого реального проекта в терминале (команды разберём позже, сейчас просто посмотрите на результат):
git log --onelinee41b7c2 (HEAD -> main, origin/main) Merge pull request #12 from aysel/contact-form
9d03f5a Validate contact form fields
6ab2e18 Add contact form
3c7f9e0 Fix mobile menu overlap
b58d41a Add course cards section
71e2c9d Add header and navigation
0f3a6b4 Initial commit: project structureКаждая строка — один коммит, новые сверху. Слева — короткий хеш (уникальный идентификатор), справа — сообщение. HEAD -> main показывает, где вы сейчас находитесь, а origin/main — какое состояние лежит на сервере. Любой коммит можно открыть и увидеть, что именно в нём изменилось:
<nav class="menu">
- <a href="#about">About</a>
+ <a href="#about">About us</a>
+ <a href="#contact">Contact</a>
</nav>Строки с - удалены, строки с + добавлены — такое представление называется diff. Благодаря истории можно вернуть файл к любому состоянию и найти коммит, в котором появилась ошибка.
Путь изменения: от правки до main
В команде любое изменение проходит один и тот же путь (каждому шагу посвящены отдельные темы курса):
1. Правка вы меняете файлы в редакторе
↓
2. Коммит фиксируете снимок в своём локальном репозитории
↓
3. Push отправляете коммиты на сервер (например, на GitHub)
↓
4. Pull request просите команду проверить изменения
↓
5. Слияние после code review изменения попадают в главную ветку mainШаги 1–2 происходят только на вашем компьютере: до push коллеги ваших коммитов не видят. Pull request — функция не самого Git, а хостинга (в GitLab — merge request): там коллеги обсуждают код и нажимают кнопку слияния.
Типичные ошибки
- «Git и GitHub — одно и то же». Git работает полностью локально, без аккаунта и интернета. GitHub — лишь одно из мест, куда можно отправить копию репозитория.
- «Контроль версий нужен только командам». Даже в одиночку Git позволяет безопасно экспериментировать и откатывать неудачные изменения, а публичные репозитории — часть портфолио.
- «Закоммитил — значит, код в безопасности». Коммит хранится только на вашем диске, пока вы не отправили его на сервер. Сломался ноутбук до push — коммиты пропали.
- Хранить в репозитории всё подряд. Пароли,
.env,node_modulesи большие видео в Git не кладут: история помнит всё навсегда (подробнее — в теме о.gitignore). - Один огромный коммит в неделю. Машина времени работает, только если в истории есть остановки. Коммитьте небольшими логичными шагами.
Итог
- Система контроля версий хранит историю изменений: кто, когда, что и зачем поменял.
- Коммит — сохранённый снимок проекта с автором, датой и сообщением; репозиторий — проект вместе со всей историей.
- Централизованные системы (SVN) держат историю на сервере, распределённые (Git) — у каждого разработчика.
- Git хранит снимки всего проекта, а неизменённые файлы не дублирует.
- Git — программа на вашем компьютере; GitHub, GitLab и Bitbucket — хостинги с инструментами для команд.
- Типичный путь изменения: правка → коммит → push → pull request → слияние в main.
Практика
- Найдите на своём компьютере папку с файлами вида «final», «копия», «old». Запишите, какие проблемы из этой темы вы уже встречали.
- Откройте на GitHub популярный открытый проект (например, vuejs/core) и перейдите в список коммитов. Найдите автора, дату и сообщение последнего коммита, откройте его и посмотрите diff.
- Нарисуйте схему команды из трёх разработчиков для централизованной и распределённой системы. Ответьте письменно: что произойдёт в каждом случае, если сервер сломается на сутки?
- Вы с другом делаете лендинг для кафе в Баку. Опишите в 5–7 шагах, как изменение «добавить блок с меню» попадает из вашего редактора в ветку main, используя слова: коммит, push, pull request, code review, слияние.
💡 Бесплатная книга Pro Git на официальном сайте Git — отличный справочник на весь курс.