Каждый разработчик рано или поздно задаётся вопросами: «что я поменял вчера, после чего всё сломалось?», «как вернуть версию, которая работала на прошлой неделе?», «как вдвоём править один проект и не затирать чужую работу?». На них отвечает система контроля версий (Version Control System, VCS) — программа, которая хранит историю всех изменений проекта. Стандарт индустрии сегодня — Git: его используют почти все компании, и умение работать с ним проверяют на любом собеседовании.

Проблема «final_v2_final»

Без контроля версий папка проекта со временем начинает выглядеть так:

text
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). Коммит содержит состояние файлов, автора, дату и сообщение — что и зачем изменено:

text
Коммит 3   Aysel   12.09   «Добавить форму обратной связи»
Коммит 2   Murad   10.09   «Исправить меню на мобильных»
Коммит 1   Aysel   08.09   «Создать структуру сайта»

Проект вместе с базой всей его истории называется репозиторий (repository, «репо»).

Локальные, централизованные и распределённые системы

Локальные VCS (например, RCS, 1982 год) хранили историю на одном компьютере: работать вместе неудобно, а поломка диска уничтожала всё.

Централизованные системы (CVS, SVN, Perforce) держат полную историю на одном сервере, а разработчики получают с него только текущую версию файлов. Без сети нельзя ни сохранить изменение в историю, ни посмотреть её; если сервер недоступен, стоит вся команда. SVN (Subversion) до сих пор встречается в старых корпоративных проектах и в геймдеве.

Распределённые системы (Git, Mercurial) дают каждому разработчику полную копию репозитория со всей историей. Коммитить, смотреть историю и создавать ветки можно без интернета, а сервер нужен только для обмена изменениями. Если сервер пропадёт, историю можно восстановить с компьютера любого участника.

text
 Централизованная (SVN)                Распределённая (Git)

       [ Сервер ]                           [ Сервер ]
       (история)                            (история)
      /    |     \                         /    |     \
[Aysel] [Murad] [Leyla]              [Aysel]  [Murad]  [Leyla]
 файлы   файлы   файлы               история  история  история
                                     + файлы  + файлы  + файлы

Снимки вместо списка разниц

Многие старые системы хранят первую версию файла и затем цепочку изменений к ней. Git мыслит снимками (snapshots): при каждом коммите он запоминает, как выглядел весь проект целиком. Чтобы не тратить место, неизменённые файлы не копируются — новый снимок просто ссылается на уже сохранённую версию.

text
             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.

История проекта как машина времени

Так выглядит история небольшого реального проекта в терминале (команды разберём позже, сейчас просто посмотрите на результат):

bash
git log --oneline
text
e41b7c2 (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 — какое состояние лежит на сервере. Любой коммит можно открыть и увидеть, что именно в нём изменилось:

diff
 <nav class="menu">
-  <a href="#about">About</a>
+  <a href="#about">About us</a>
+  <a href="#contact">Contact</a>
 </nav>

Строки с - удалены, строки с + добавлены — такое представление называется diff. Благодаря истории можно вернуть файл к любому состоянию и найти коммит, в котором появилась ошибка.

Путь изменения: от правки до main

В команде любое изменение проходит один и тот же путь (каждому шагу посвящены отдельные темы курса):

text
1. Правка         вы меняете файлы в редакторе
      ↓
2. Коммит         фиксируете снимок в своём локальном репозитории
      ↓
3. Push           отправляете коммиты на сервер (например, на GitHub)
      ↓
4. Pull request   просите команду проверить изменения
      ↓
5. Слияние        после code review изменения попадают в главную ветку main

Шаги 1–2 происходят только на вашем компьютере: до push коллеги ваших коммитов не видят. Pull request — функция не самого Git, а хостинга (в GitLab — merge request): там коллеги обсуждают код и нажимают кнопку слияния.

Типичные ошибки

  1. «Git и GitHub — одно и то же». Git работает полностью локально, без аккаунта и интернета. GitHub — лишь одно из мест, куда можно отправить копию репозитория.
  2. «Контроль версий нужен только командам». Даже в одиночку Git позволяет безопасно экспериментировать и откатывать неудачные изменения, а публичные репозитории — часть портфолио.
  3. «Закоммитил — значит, код в безопасности». Коммит хранится только на вашем диске, пока вы не отправили его на сервер. Сломался ноутбук до push — коммиты пропали.
  4. Хранить в репозитории всё подряд. Пароли, .env, node_modules и большие видео в Git не кладут: история помнит всё навсегда (подробнее — в теме о .gitignore).
  5. Один огромный коммит в неделю. Машина времени работает, только если в истории есть остановки. Коммитьте небольшими логичными шагами.

Итог

  • Система контроля версий хранит историю изменений: кто, когда, что и зачем поменял.
  • Коммит — сохранённый снимок проекта с автором, датой и сообщением; репозиторий — проект вместе со всей историей.
  • Централизованные системы (SVN) держат историю на сервере, распределённые (Git) — у каждого разработчика.
  • Git хранит снимки всего проекта, а неизменённые файлы не дублирует.
  • Git — программа на вашем компьютере; GitHub, GitLab и Bitbucket — хостинги с инструментами для команд.
  • Типичный путь изменения: правка → коммит → push → pull request → слияние в main.

Практика

  1. Найдите на своём компьютере папку с файлами вида «final», «копия», «old». Запишите, какие проблемы из этой темы вы уже встречали.
  2. Откройте на GitHub популярный открытый проект (например, vuejs/core) и перейдите в список коммитов. Найдите автора, дату и сообщение последнего коммита, откройте его и посмотрите diff.
  3. Нарисуйте схему команды из трёх разработчиков для централизованной и распределённой системы. Ответьте письменно: что произойдёт в каждом случае, если сервер сломается на сутки?
  4. Вы с другом делаете лендинг для кафе в Баку. Опишите в 5–7 шагах, как изменение «добавить блок с меню» попадает из вашего редактора в ветку main, используя слова: коммит, push, pull request, code review, слияние.

💡 Бесплатная книга Pro Git на официальном сайте Git — отличный справочник на весь курс.