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

GutHub

GitHub — крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки. Веб-сервис основан на системе контроля версий Git и разработан на Ruby on Rails и Erlang компанией GitHub, Inc.

Ссылка: https://github.com/

GitLab

GitLab — веб-инструмент жизненного цикла DevOps с открытым исходным кодом, представляющий систему управления репозиториями кода для Git с собственной вики, системой отслеживания ошибок, CI/CD пайплайном и другими функциями. Код изначально был написан на Ruby, а некоторые его части были позже переписаны на Go.

Ссылка: https://gitlab.com/

Bitbucket

Bitbucket — веб-сервис для хостинга проектов и их совместной разработки, основанный на системах контроля версий Mercurial и Git.

Ссылка: https://bitbucket.org/

Tree (дерево) — структура данных, отражающая иерархические зависимости. По сути весь проект Git — это ориентированных граф.

Корневой узел — самый верхний узел дерева.

Корень — одна из вершин, по желанию наблюдателя.

Лист — узел, не имеющий дочерних элементов.

Commit (фиксация) — некоторые изменения проекта, которые запоминаются системой, обладают единым комментарием и уникальным хэшем SHA-1 (есть споры касательно этого алгоритма, он имеет ограниченность уникальных значений). Первый коммит является корневым узлом дерева. Все последующие коммиты могут быть как листьями, так и корневыми узлами.

Snapshot (снимок) — образ файловой системы проекта. Git хранит не дельту между двумя коммитами. Git  в каждом коммите хранит состояние всей файловой системы проекта на момент коммита. Git в целях экономии места хранит только измененный файл, а на те файлы, которые не были изменены, осуществляет доступ по ссылке.

HEAD — указатель на текущий коммит, то есть коммит, чей snapshot отражен в файловой системе. Указывает на состояние проекта.

Как Git видит проект

Проект — это дерево. Узлами дерева являются коммиты. Каждый коммит характеризуется сообщением, набором файлов, которые претерпели изменения, ссылки на неизменные файлы, уникальных хэш SHA-1, с помощью которого можно идентифицировать коммит.

В проект определяется определенная последовательность коммитов, которые группируются в ветвь. Ветви не влияют друг на друга. Ветви «растут» сами по себе (пока не выполнится слияние). Для фиксации того, кто и когда делал изменения, к коммиту прикрепляется временная метка и имя автора.

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

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

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

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

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

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

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

• TFS (Microsoft)

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

• Mercurial

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

• Git

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

• SVN (Subvervion)

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

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

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

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

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