Файл: Система управления версиями git и российский сервис хранения исходного кода gitflic.pdf

29
2. СИСТЕМА УПРАВЛЕНИЯ ВЕРСИЯМИ GIT
Вторая глава посвящена системе управления версиями Git. Будут по- дробно рассмотрены все этапы использования репозитория Git от создания до управления ветками. В ходе описания команд Git будет продемонстриро- вано внутреннее устройство репозитория. Из этой главы читатель получит полное представление о Git как инструменте управления версиями и сможет начать использовать его в своей работе. Дальше практика, практика и ещё раз практика.
2.1. Особенности и преимущества Git
Git является распределённой системой управления версиями. Это значит, что полная версия репозитория находится на локальном компью- тере. Нет необходимости постоянно сохранять изменения в удалённом ре- позитории и загружать из него обновления. Всё, что происходит на локаль- ном компьютере, остаётся только на локальном компьютере. Во внешний мир уходят только проверенные версии, поэтому никто не узнает о неуда- чах, ошибках и откровенных ляпах. Копии репозитория могут находиться на нескольких компьютерах: домашнем, офисном, дачном, и на всех компь- ютерах будут одни и те же версии файлов. Если есть необходимость выпол- нить работу на «новом» компьютере, репозиторий может быть перенесён на него очень быстро. В общем, полная свобода перемещений.
Git даёт полный контроль над версиями. Коммиты можно удалять, из- менять, менять местами, объединять, разделять, перемещать между ветками.
Основной инструмент Git – это ветки. Ветки создаются для проверки решения подзадач, для выбора одного варианта из нескольких, для помощи коллеге, для сохранения идеи «на будущее». Создать ветку, переключиться между ветками, слить ветки, удалить ветку – эти операции выполняются по- стоянно в ходе работы над проектом. Ветки – то, ради чего существует си- стема управления версиями. Ветки и есть версии.
Git предоставляет гибкий инструмент управления коммитами.

30
Перед созданием коммита можно посмотреть, что в него войдёт и отредак- тировать список файлов, при необходимости. Можно посмотреть историю коммитов для одного файла или для всей ветки. Сравнить версии файла в различных коммитах. Удалить коммит, восстановить рабочую версию из коммита.
Git позволяет заморозить изменения без создания коммита. Если нужно срочно переключиться на другую ветку, а текущая ветка ещё не го- това для коммита, то её можно заморозить. Изменения не будут потеряны, и не придётся создавать «технологический коммит», не несущий смысловой нагрузки.
Git позволяет организовать работу в команде. Каждый програм- мист работает в своей ветке, что ускоряет разработку за счёт разделения её на несколько потоков. Перед добавлением ветки в проект она отправляется на проверку и рецензию. При необходимости код, содержащийся в ветке, дорабатывается. В результате в проект попадает только проверенный код.
Программисты видят результаты работы коллег и могут обмениваться иде- ями, устраивать консультации, совместные обсуждения, оказывать помощь.
Для Git существует большое количество бесплатных удалённых
репозиториев, таких как GitHub, GitFlic, BitBucket.
2.2. Установка и настройка Git для Windows
Для использования Git его необходимо установить на компьютер и настроить. Для установки Git на компьютер, работающий под управлением опе- рационной системы Windows, необходимо скачать дистрибутив с официаль- ного сайта Git: www.git-scm.com, запустить его и выбрать необходимые опции, предлагаемые установщиком. Здесь будут пояснены две наиболее важные оп- ции. Не беда, если в процессе установки будут выбраны «не те» опции, их можно будет изменить после установки с помощью команды git config.
Выбор имени основной ветки. Git предлагает имя для основной ветки, но лучше придумать своё. В этом случае, при обновлении версии Git, имя основной ветки не изменится. Выберите опцию “Override the default branch name for new repositories” и введите имя основной ветки в поле ввода.

31
Настройка запуска Git из консоли. Выберите опцию “Git from the com- mand line and also from 3
rd
-party software”. Это позволит запускать Git не только из консоли Git Bash, но и из консоли Windows и других приложений
(например, сред разработки).
После завершения установки на компьютере появится папка, содер- жащая программы:
− Git Bash – оболочка работы с Git, основанная на Bash;
− Git CMD – окно командной строки Windows для работы с Git;
− Git FAQs – ссылка на сайт с ответами на наиболее частые вопросы про Git;
− Git GUI – графическая оболочка для работы с Git;
− Git release notes – ссылка на сайт с информацией о текущей и преды- дущих версиях Git.
Что использовать для работы с Git: Git Bash, Git CMD, Git GUI – каж- дый из пользователей должен решить самостоятельно. В настоящем изда- нии для демонстрации примеров будет использоваться Git Bash, поскольку
Bash является оболочкой, доступной и в Windows, и в Linux, что делает при- меры воспроизводимыми в различных операционных системах.
2.3. Основные понятия
Ниже приведено формальное описание терминов, которые будут ис- пользоваться в процессе изложения материала.
1. Репозиторий. Любая папка файловой системы может быть преоб- разована в репозиторий Git. После преобразования внутри этой папки по- явится папка .git/, содержащая дерево изменений проекта.
2. Рабочая директория. Все папки и файлы внутри репозитория за исключением .git/. С файлами, находящимися в рабочей директории, проис- ходят основные изменения в рамках работы над проектом.
3. Индекс. Файл, расположенный в папке .git/, содержит список фай- лов, подготовленных для добавления в коммит.
4. Коммит. Файл, который хранит изменённые файлы, имя автора коммита, время создания коммита. Каждый коммит имеет уникальное имя,

32 позволяющее вернуть рабочую директорию в состояние, которое было до внесения изменений, зафиксированных в коммите.
5. Указатель. Ссылка, которую использует Git или программист, чтобы сослаться на коммит.
6. Ветка. Последовательность коммитов. Для ссылки на ветку ис- пользуется указатель на последний коммит ветки. В репозитории изна- чально содержится одна ветка. В дальнейшем может быть добавлено не- ограниченное количество независимых веток.
2.4. Настройка Git, команда git config
После установки Git встраивается в операционную систему и влияет на её поведение на системном, глобальном и локальном уровне. В соответ- ствии с этим, существуют три файла настроек:
1. Системные. Распространяются на всех пользователей операцион- ной системы. Файл с системными настройками Git называется gitconfig и расположен в директории C:\Program Files\Git\etc\.
2. Глобальные. Распространяются на все репозитории, созданные под логином пользователя. Файл с глобальными настройками Git называ- ется .gitconfig и расположен в директории C:/User/<имя пользователя>/.
3. Локальные. Влияют на настройки одного репозитория. Файл с настройками называется config и расположен в директории .git/ репозитория.
Для изменения настроек можно отредактировать файл конфигурации в текстовом редакторе или воспользоваться командой git config. Эта ко- манда позволяет изменить или посмотреть значение параметров конфигура- ции Git.
Формат команды git config:
git config <ключ> <параметр> <значение>
Ключ задаёт область действия параметра. Возможные значения:
--global – указывает на то, что будут изменяться настройки файла gitconfig;
--system – указывает на то, что будут изменяться настройки файла
.gitconfig;

33
--local – указывает на то, что будут изменяться настройки файла config
(это значение ключа установлено по умолчанию).
Параметр указывает, какая настройка будет изменена. Возможные значения:
– user.name – имя пользователя;
– user.email – адрес электронной почты пользователя.
Значение – текстовая строка, задающая значение параметра.
В следующем примере изменяются имя пользователя и его e-mail в глобальных настройках.
$ git config --global user.name 'Git_Book'
$ git config --global user.email 'git_book@home.com'
После выполнения приведённых команд файл .gitconfig будет выгля- деть следующим образом:
[user] name = Git_Book email = git_book@home.com
[credential "https://gitflic.ru"] provider = generic
Поля name и email содержат значения, заданные соответствующими командами Git, приведёнными выше.
2.5. Создание локального репозитория, команда git init
Команда git init создаёт новый локальный репозиторий в той папке, в которой она была выполнена.
Формат команды git init:
git init <параметр>
Один из возможных параметров задаёт имя главной ветки проекта:
--initial-branch=<имя ветки>
В примере ниже создаётся репозиторий в папке Learn_git. Имя глав- ной ветки этого репозитория Main_branch.

34
/c
$ mkdir Learn_git
/c
$ cd Learn_git
/c/Learn_git
$ git init --initial-branch='Main_branch'
Initialized empty Git repository in C:/Learn_git/.git/
/c/Learn_git (Main_branch)
Признаком того, что папка является репозиторием Git, будет название ветки в скобках после указания пути к папке.
В папке Learn_git командой git init была создана папка .git со следую- щей структурой вложенных папок.
└───.git
├───hooks
├───info
├───objects
│ ├───info
│ └───pack
└───refs
├───heads
└───tags
Назначение этих папок и их содержимое будет поясняться далее, по мере изучения команд Git и создаваемых ими объектов.
2.6. Логическая структура Git
Логически репозиторий состоит из трёх частей: рабочая директория; файлы, подготовленные для включения в очередной коммит (Staging area); хранилище файлов предыдущих версий (архив).
В рабочей директории находятся файлы, в которые программист вносит текущие изменения.
Staging area включает изменённые файлы, которые планируется включить в очередной коммит.
Архив содержит все предыдущие версии файлов проекта.
На рисунке 2.1 показана диаграмма «перемещения» файлов между ло- гическими частями репозитория.

35
Рисунок 2.1 – Диаграмма перемещения файлов
Работа программиста, использующего Git, выглядит следующим обра- зом. Редактирование файлов в рабочей директории. Git следит за тем, какие файлы были изменены, и может сформировать список изменённых файлов. Ко- гда программист решит, что файл содержит изменения, которые необходимо зафиксировать, он даёт Git команду подготовить файл для сохранения в архиве.
Git преобразует файл в формат, удобный для хранения, и размещает его в ар- хивной папке .git. Этот файл находится в промежуточном состоянии. Он уже в архиве, но ещё не включён в историю изменений. Это Staging area. Когда все файлы, включающие логически завершённую часть решаемой задачи, разме- щены в Staging Area, программист даёт Git команду включить файлы из Staging area в историю изменений. Git формирует структуры, описывающие произо- шедшие изменения, и сохраняет их в папке .git.
2.7. Состояния файлов, команда git status
Файлы, находящиеся в рабочей директории, могут находиться в од- ном из двух состояний: отслеживаемые и не отслеживаемые. В число отсле- живаемых входят все файлы, которые хотя бы один раз попадали в Staging area. Про файлы, ни разу не попадавшие в Staging area, Git знает только то, что они существуют, и не отслеживает происходящие в них изменения.
Отслеживаемые файлы делятся на три категории: неизменённые, из- менённые, подготовленные к коммиту. На рисунке 2.2 показана диаграмма

36 перехода файлов из одного состояния в другое.
Рисунок 2.2 – Диаграмма изменения состояния файла
Для того чтобы файл стал отслеживаемым, его необходимо поместить в Staging area. Например, для того чтобы файл, скопированный из другой папки, стал частью репозитория, его необходимо включить в коммит (даже, если в этот файл не будут внесены никакие изменения).
Для того чтобы файл стал не отслеживаемым, его необходимо удалить из рабочей директории. После удаления файл останется в архиве, и его можно будет восстановить.
Файл становится изменённым, если в него внесены изменения.
Файл становится Staged (подготовленным к коммиту) после соответ- ствующей команды программиста. При этом новая версия файла будет со- хранена в архиве, но не внесена в историю изменений.
После того, как был выполнен коммит, все файлы из Staged area пере- ходят в состояние неизменённых и остаются отслеживаемыми.
Для определения состояния файлов, находящихся в рабочей директо- рии, предназначена команда git status.

37
-v – для изменённых файлов показывать текст, который был изменён.
Для примера, рассмотренного ранее, в директорию Learn_git были до- бавлены два файла (File1.txt, File2.txt) и пустая директория Dir1. File1 содер- жит текст: Example1. File2 содержит текст: Example2. Ниже показан резуль- тат выполнения команды git status после добавления файлов и директории.
$ git status
On branch Main_branch
No commits yet
Untracked files:
(use "git add ..." to include in what will be committed)
File1.txt
File2.txt nothing added to commit but untracked files present (use "git add" to track)
Интерпретация информации, выведенной Git по команде git status, следующая:
− текущая ветка – Main_branch;
− до сих пор не было сделано ни одного коммита;
− имеются не отслеживаемые файлы File1.txt, File2.txt. Git рекомен- дует добавить их в Staging area с помощью команды add;
− сообщается, что ничего не добавлено в коммит, но имеются не от- слеживаемые файлы.
Перед тем, как выполнять действия по добавлению файлов в Staging area и затем в коммит, необходимо рассмотреть, как Git хранит внутреннюю информацию.
2.8. Объекты Git
Всё, что сохраняет Git в архиве, называется объектом. Объекты хра- нятся в директории .git/objects. В настоящий момент, для рассматриваемого примера, директория .git/objects содержит две директории info и pack (см. раздел 2.5) и ни одного файла с объектами.
Объекты в Git бывают трёх типов:
1. Blob (binary large object) – большой двоичный объект. Из названия следует, что это двоичный файл. Blob создаётся для каждого файла и всех

38 его версий, сохранённых в архиве. Blob содержит имя файла и его содержи- мое в сжатом виде, Blob формируется, когда файл добавляется в Staging area.
2. Tree (дерево) – двоичное представление графа, описывающего связи между файлами, хранящимися в архиве. Граф формируется для каж- дой директории, включённой в архив. Формирование графа происходит в про- цессе выполнения коммита. Граф содержит информацию о том, какие файлы и директории содержатся в директории, которую описывает граф. Описание хранится в виде имён blob-объектов и имён других объектов типа Tree.
3. Коммит – содержит информацию об авторе коммита, дате и вре- мени выполнения коммита, комментарий и ссылку на объект Tree, который описывает корневую директорию репозитория.
Ещё один элемент внутреннего устройства Git, не являющийся объек- том, это двоичный файл index (индекс). Этот файл хранит ссылки на blob- объекты, которые добавляются в Staging area. Фактически файл index и есть
Staging area. В дальнейшем термин «добавить в Staging area» будет приме- няться как синоним термина «добавить в индекс». Во время выполнения ко- манды add, упоминавшейся в примере прошлого раздела, происходит формиро- вание blob-объекта для добавляемого файла. Blob-объект добавляется в дирек- торию .git/objects, а имя этого blob-объекта записывается в файл index.
Blob-объект формируется по следующему алгоритму.
1. На первом шаге формируется текстовой файл, который начинается с ключевого слова blob. После слова blob через пробел записывается длина исходного текстового файла в байтах и нулевой байт (\0). После нулевого байта записывается содержимое исходного текстового файла. В рассмотрен- ном выше примере файл File1.txt содержит текст Example1. Для этого файла результат выполнения первого шага создания blob-объекта будет выглядеть следующим образом: blob 8\0Example1.
2. Для полученного на первом шаге файла с помощью алгоритма SHA-1 формируется хеш-значение, состоящее из 40 шестнадцатеричных цифр.
Первые две цифры хеш-значения являются именем подкаталога каталога
.git/objects, в котором будет храниться blob-объект. Остальные 38 шестна- дцатеричных цифр являются именем blob-объекта. Хеш-значение использу- ется для того, чтобы все хранящиеся в архиве файлы имели различные имена хранения. Даже если два файла имеют одинаковое исходное имя, но различное содержание, их хеш-значения будут различными. Первые две