Система контроля версий. Разбираемся, что это такое, на примере Git

г. Минск, ул. Притыцкого, 2/3, 3 этаж, офис 23

Что такое система контроля версий

Представьте, что вы работаете с какой-то информацией, будь то статья блога или код сайта. В процессе работы вам постоянно приходится вносить правки: что-то добавлять, что-то удалять. Каждое такое изменение, можно сказать, приводит к созданию определённой «версии» вашего творения.

И вот, после N-ного количества изменений, вы понимаете, что необходимо вернуть какой-то кусок информации, который вы ранее удалили. Ctrl+Z может, конечно, помочь. Но вернёт назад лишь на пару шагов. А что, если этих шагов слишком много? А что, если эта информация была удалена, предположим, неделю назад?

Тут вас может посетить мысль: здорово было бы иметь какую-нибудь историю всех вносимых в продукт изменений (историю всех «версий»). Так вот, созданием таких историй и занимаются системы контроля версий (Version Control System, VCS).

Система контроля версий [ далее: СКВ ] — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое. (Википедия)

При чём тут разработка

Возможность вернуть удалённую информацию — это далеко не единственное преимущество систем контроля версий. Вот примерный их перечень:

  • Ведение полной истории всех изменений проекта;
  • Возможность возврата назад, с сохранением истории текущих изменений;
  • Предоставление информации о том, кто, когда и какие изменения вносил;
  • Возможность параллельной работы нескольких людей над одним проектом;
  • Возможность разделения проекта на несколько независимых версий.

Использование СКВ — неотъемлемая часть нынешней разработки. Главная задача, которую помогает решить СКВ — организация командной работы.

Раньше для работы нескольких людей над одним проектом, приходилось:

  1. Получать свежую версию кода из хранилища (флешка, сервер, облако);
  2. Вносить туда свои правки;
  3. Формировать новую версию (теперь она будет свежая);
  4. Передавать её в хранилище.

Такой способ работы казался вполне сносным, несмотря на все трудности:

  • Работать с кодом приходилось поочерёдно;
  • Не было гарантий, что вносимые человеком изменения не будут стёрты другим разработчиком;
  • Тяжело было определить, кто, когда и какие изменения вносил;
  • Размер архива проекта сильно рос с каждой новой версией;
  • В целом человеческий фактор имел слишком большое влияние.

С появлением СКВ появилась возможность оптимизировать этот процесс.

Теперь все разработчики могут работать с кодом проекта параллельно, не опасаясь, что их работа будет утеряна, ведь если что-то попало в СКВ, то это остаётся в истории проекта навсегда (без шуток).

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

А поиск по истории всех изменений стал удобным и вышел практически на безграничные возможности.

Все говорят про какой-то Git

Существует несколько типов систем контроля версий:

1. Локальные: история всех версий и рабочий код (список файлов) хранятся на одном компьютере.

Схема локальной системы контроля версий
Схема локальной системы контроля версий

2. Централизованные: история версий хранится на удалённом сервере, а рабочий код на нескольких компьютерах. Компьютеры связаны с одним сервером.

Схема централизованной системы контроля версий
Схема централизованной системы контроля версий

3. Распределённые: рабочий код хранится на нескольких компьютерах, а история всех версий хранится как на удалённом сервере, так и на каждом из этих компьютеров. Все компьютеры связаны с сервером, но ещё дополнительно связаны между собой.

Схема распределенной системы контроля версий
Схема распределенной системы контроля версий

Наиболее распространёнными в разработке являются распределённые системы. В частности из-за реализации принципа «Храни яйца в разных корзинах». Ведь даже при потере данных на удалённом сервере, они есть на других носителях, и любой из компьютеров может временно заменить собой сервер, чтобы работа продолжалась без перебоев.

Так вот Git — это самая популярная распределённая система контроля версий. Кроме того она бесплатна и имеет открытый исходный код (Open Source). С его помощью построены рабочие процессы у таких гигантов отрасли, как Google, Microsoft, Android, Meta, Twitter, Linux и т. д.

Немного контекстной терминологии

В Git есть несколько основных сущностей и понятий. В целом их определения помогут довольно чётко проследить всю суть системы Git.

Репозиторий — специальный каталог, в котором хранятся файлы проекта и вся история их изменений. Проще говоря, это папка, которая содержит всё, что необходимо для управления всей системой контроля версий.

Ветка (branch) — копия (ответвление) основного кода проекта. Их создают, чтобы «безболезненно» работать над проектом, без отключения его от клиентов. Например: на рабочий сайт, нужно добавить новый функционал. Вместо того, чтобы останавливать работу всего сайта, создаётся его копия (ветка). На ней дорабатывается нужный функционал. А когда всё настроено и проверено, эта ветка вливается в основную. И вы получаете рабочий сайт с новым функционалом.

Коммит (commit) [ говорят: закоммитить ] — тот самый слепок (версия) информации в истории проекта. Вообще коммиты являются основными кирпичиками всей системы. Каждая ветка проекта (новый функционал) состоит из коммитов, каждый из которых решает какую-нибудь одну микрозадачу. Например: есть задача — добавление формы обратной связи на сайт. Эту задачу можно разбить на несколько подзадач: сверстать форму, настроить её отправку, настроить валидацию данных, настроить передачу данных владельцу сайта, настроить формирование отчёта об отправке посетителю сайта. Так вот условно говоря каждая выполненная подзадача будет сохранена в ветке в виде коммита.

Пуш (push) [ говорят: пушнуть ] — отправка изменений (коммитов) с локального компьютера разработчика на удалённый сервер (репозиторий).

Пулл (pull) [ говорят: пульнуть ] — получение актуальных изменений (коммитов) из удалённого сервера на локальный компьютер.

Мерж (merge) [ говорят: смержить ] — объединение перемещающихся изменений (коммитов). Довольно часто при совместной работе над проектом получается так, что разные разработчики вносят изменения в один и тот же файл. Так вот чтобы изменения обоих в итоге не потерялись, в процессе объединения (мержа) система предупреждает о наличии конфликтов. Когда полученные конфликты решены, т. е. сформирован файл с изменениями обоих разработчиков, запускается ещё один мерж.

Git и GitHub — это одно и то же?

Нет. =)

Git — это набор инструментов для работы с историей изменений в проекте.
GitHub — это сайт (сервис) для хостинга IT-проектов.

Он выступает в качестве удалённого сервера для хранения репозиториев. Является самой большой библиотекой проектов с открытым исходным кодом. Сервис предоставляет огромный набор инфраструктурных инструментов, построенных вокруг проектов, использующих Git. Если вам знакомо понятие Open Source, то во многом именно благодаря GitHub и подобным сервисам такое явление в принципе стало возможно.

Пример работы с Git

Предположим, у вас есть интернет-магазин, работу которого поддерживает несколько разработчиков. Сайт интернет-магазина расположен на вашем основном домене, и находится в рабочем состоянии. Заказы поступают регулярно.

Вы хотите его доработать. Например: настроить микроразметку у товаров, добавить расчёт доставки и реализовать интеграцию со складом. При этом сайт не должен прекращать работу. И за выполнение каждой из задач отвечают разные люди.

При грамотном подходе к разработке, помимо основного сайта (т.н. production) у вас должен быть настроен отдельный сайт для тестирования и отладки доработок (т.н. dev). Причём dev — полная независимая копия production.

Каждый разработчик работает с кодом на собственном (локальном) компьютере. Один добавляет микроразметку, второй — расчёт доставки, третий — интеграцию со складом. Затем все эти доработки внедряются на dev-сайт. Сайт тестируется и доводится до полностью рабочей версии, без багов.

И только когда всё проверено и исправно работает, полученный код переносится на production, т. е. на основной сайт.

Итого: вам не придётся отключать сайт на несколько дней для его доработки. Максимум — на несколько минут для переноса готовых доработок в production.

Стоит отметить, что во всей полученной инфраструктуре Git занимает лишь небольшую часть всего инструментария. Но без Git построить такой процесс было бы крайне затруднительно. Он помогает наладить командную работу, отвечает за грамотное объединение всех доработок и ведение полной истории изменений.

Кому подходит Git

В целом использование Git окажется огромным плюсом при разработке проектов любой сложности: от промо-лендинга до нагруженного функционалом интернет-магазина.

Выгода от его использования очевидна.:

  • у вас всегда есть вся история изменений в проекте;
  • есть возможность безболезненного добавления нового функционала;
  • есть возможность легко организовать командную разработку.

Но одного Git-а не достаточно, чтобы «сделать красиво». Для грамотной организации разработки через Git нужна слаженность команды, общий инструментарий разработчиков, довольно высокий уровень компетенции сотрудников, а главное — чёткое понимание, для чего вам Git.

К слову в нашей компании команда разработчиков активно использует Git для работы на проектах любой сложности.

Надеемся, что статья была для вас полезной и полученная информация поможет вам в будущем. А ещё мы будем рады помочь вам в вопросах SEO-продвижения, рекламы в интернете, разработки сайтов и запуска продаж на маркетплейсах. Оставляйте заявку ниже:

Узнать стоимость и условия

* — поля, обязательные для заполнения
г. Минск, ул. Притыцкого, 2/3, 3 этаж, офис 23