Система контроля версий (далее – СКВ) – это программное обеспечение (далее – ПО), которое помогает разработчикам работать в команде при разработке ПО и сохранять всю историю работы над проектом.
Ниже указаны основные функции СКВ:
- Позволяет разработчикам работать над проектом одновременно
- Запрещает переписывать изменения друг друга
- Сохраняет каждую версию ПО
Существует два типа СКВ:
- Централизованные СКВ
- Распределённые (Децентрализованные) СКВ
В рамках данного курса мы рассмотрим только распределённые СКВ на примере Git.
Распределённые СКВ (РСКВ)
Централизованные СКВ используют центральный сервер для хранения всех файлов и позволяет команде взаимодействовать. Но данный тип СКВ подвержен большой опасности – выходу из строя центрального сервера. Если с сервером что-то происходит, то работа над проектом прекращается, так как разработчики не имеют доступа к исходному коду. А если данные на сервере утеряны, то (если нет резерва) данные теряются безвозвратно.
Именно поэтому, в настоящее время именно распределённые СКВ пользуются огромной популярностью.
Клиент РСКВ не только проверяет крайние изменения базовой директории, но также является и резервным хранилищем проекта. Если сервер выходит из строя, базовая версия может быть восстановлена с помощью клиентской машины. Таким образом Git не полагается на центральный сервер, благодаря чему мы можем работать с Git и выполнять большинство операция даже тогда, когда мы находимся не в сети. Мы можем подтверждать изменения, создавать новые ветки, просматривать историю изменений и т.д. при работе оффлайн. После этого нам необходимо только подключиться к сети и опубликовать наши крайние изменения.
Базовая терминология Git
- Рабочая директория и плацдарм (Working Directory and Staging Area)
Рабочая директория – это место, где файлы проверяются. Git не отслеживает каждый изменённый файл. Когда мы выполняем операцию commit, Git ищет все файлы, которые находятся в рабочей директории. И подтверждаются только те файлы, которые в ней находятся.
Давайте рассмотрим небольшой пример.
- Мы изменяем файл в рабочей директории
- Мы добавляем эти файлы в плацдарм
- Мы выполняем подтверждение изменений (commit), тем самым удаляя файлы из плацдарма. После выполнения операции push файлы находятся в Git репозитории. Предположим, что у нас есть два файла Developer.java и Project.java и мы хотим выполнить две разные операции commit для каждого из них. Мы добавляем один файл в плацдарм и выполняем операцию commit, после чего повторяем эту же процедуру с другим файлом.Пример:
# Первый commit
[корень_проекта]$ git add Developer.java
[корень_проекта]$ git commit -m "Adding Developer class"
# Второй commit
[корень_проекта]$ git add Project.java
[корень_проекта]$ git commit -m "Adding Project class"
- Локальный репозиторий (Local Repository)
Git предоставляет личное рабочее пространство для работы с проектом, который называется локальным репозиторием. Разработчик вносит изменения в проект в этом репозитории и, после подтверждения изменений, они становятся частью локальной копии. Пользователь может выполнить множество изменений, которые будут храниться только на его машине до тех пор, пока он не отправит их в центральный репозиторий. - Дерево (Tree)
Дерево – это объект, который представляет собой директорию. Он хранит бинарные большие объекты как под-директории. Дерево – это бинарный файл, который хранит ссылки на, так называемые, Blobs и деревья, которые представлены SHA1 хэшем объекта дерева. - Бинарный Большой Объект (Blob)
Binary Large Object – это файл, который представляет версию файла. Он содержит данные файла, но не хранит его метаданные. Это двоичный объект и базе данных Git он называется SHA1 хэшем файла. В Git доступ к файлам обеспечивается не по имени, а по содержанию. - Коммит (Commit)
Коммит хранит текущее состояние репозитория, он также называется SHA1 хэшем. Мы можем представить, что commit – это элемент связного списка. Каждый такой элемент имеет ссылку на родительский элемент. Из этого элемента мы можем откатиться назад с помощью ссылки на предыдущий элемент для того. Если у коммита есть несколько родительских коммитов, то это означает, что он был создан путём слияния двух ветвей. - Клон (Clone)
Операция Clone создаёт экземпляр репозитория. Данная операция не только проверяет рабочую копию, но также становится хранилищем самого репозитория (зеркалом – mirror). Разработчик может выполнять множество операций на локальной машине, а после подключения к сети все данные могут быть синхронизированы. - Ветвь (Branch)
Ветви используются для создания отдельной версии разработки. По умолчанию, Git имеет главную ветвь, которая называется master. Когда нам необходимо реализовать какой-либо функционал, или исправить ошибку, мы создаём отдельную ветвь и выполняем необходимую работу. После того как задача выполнена, мы выполняем слияние с основной ветвью Git и удаляем ненужную ветвь. Это позволяет всегда хранить рабочую версию проекта и вносить уже полностью готовые и протестированные изменения в основную ветвь. Каждая ветвь имеет заголовок (HEAD), который является ссылкой на крайний коммит ветви. Когда мы выполняем операцию commit, HEAD обновляется. - Вытягивать (Pull)
Данная операция копирует все изменения из удалённого репозитория на локальную машину. Она используется для синхронизации локального репозитория с центральным. - Толчок (Push)
Операция Push копирует изменения из локального репозитория в удалённый. Она используется для синхронизации центрального репозитория с локальным. - Пересмотр (Revision)
Revision представляет собой версию исходного кода и представлена коммитами, которые, в свою очередь, определяются SHA1 хэшами. - URL
URL представляет локацию репозитория и хранится в конфигурационном файле. - Заголовок (HEAD)
HEAD – это ссылка, которая всегда указывает на крайний коммит ветви. Когда мы выполняем операцию commit, HEAD обновляется и переводится на крайний коммит. Заголовки ветви хранятся в директории .git/refs/heads/.
На этом мы заканчиваем рассмотрение базовых принципов Git.
В следующей статье мы рассмотрим процесс установки Git.