Какие бывают системы контроля версий

Если вернуться назад в прошлое и посмотреть на инструментарий программистов, то можно было убедиться, что инструментарий программиста был не особо богат. Чтобы как то решить проблему связанную с маркированием изменений продукта, например, фиксирование что сделал какой-то программист внес изменения какого-то числа в файл. Раньше делали так: прямо в файл с исходным кодом создавали большую простыню комментариев, где было написана информация о том, кто что делал, что менял. Это противоречит принципам чистого кода, так как в файле с исходным кодом должен находиться лишь код. А нём находится какая-то служебная информация — это неправильно. Умные люди решили всю эту информацию вынести во «вне». Вся служебная информация должна храниться в отдельной системы и мы ее должны как-то получить.

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

Системы контроля версий можно разделить на две большие группы:

  • Централизованные
  • Децентрализованные

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

К децентролизоавнной системе относят системы без какого-то центролизованного сервера. На каждой машине есть репозиторий с которым мы работаем. Другие разработчики видят на сервере только конечные варианты файлов после изменений.

Основные наиболее полулярные системы контроля версий:

Коммерческая. Централизованная Эту систему использует Касперский.

По сути тоже самое, что TFS. Отличается «на вкус и цвет».

Бесплатная. Децентрализованная. Наиболее популярна.

Центролизованная система. Появилась раньше, чем Git.

Преимущества децентрализованных систем контроля версий:

  • Репозиторий хранится не на одной машине.
  • Не требуется постоянное подключение к сети, в которой хранится центральное хранилище.
  • В случае выхода из строя основного сервера фиксация изменений проекта не прекращается.
  • В случае выхода из строя носителя на сервере, на котором находился репозиторий, для восстановления репозитория достаточной найти коллегу, у которого наиболее актуальное состояние репозитория.
  • Сначала работа выполняется работа на локальной машине и только после того, как удостоверились, что все работает правильно, изменения отправляются на сервер и делаются доступными для коллег по работе.
  • Коллеги видят только законченный вариант вашей работы!

На данный момент почти все коммерческие проекты ведутся под управлением системы контроля версий. Благодаря таким системам появилась возможность более гибко вести процесс разработки программного обеспечения. Мы может независимо распределять работу над проектом между разработчиками. Таким образом появилась концепция Future Driven Development.

Почти все IDE поддерживают в виде плагинов системы контроля версий.

Добавить комментарий

Ваш адрес email не будет опубликован.