Git: основные понятия

Git – это система для управления разработкой информационного ресурса, например, кода программы, для чего сервис и создавался.

Каждый раз при сохранении состояния файла проекта (создании коммита) Git сохраняет помещённый в него файл, предоставляя пользователю ссылку к нему.

Git запоминает новый файл, только если он имеет отличия от предыдущей версии этого файла, который уже присутствует в системе.

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

Таким образом, Git представляет развитие размещённых в него данных проекта как динамическую древовидную систему изменений первоначально размещённого в него файла проекта.

Иными словами, если привести грубую аналогию, то Git – это усовершенствованная система «Сtrl+C».

Репозиторий – это папка проекта, расположенная на отключаемом от сети устройстве, например, да и чаще всего, на компьютере.

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

Создание репозитория заключается в назначении локального каталога в качестве контролируемого Git.

При наличии каталога проекта, который требуется поместить под версионный контроль системы, необходимо в командной строке следует перейти в него

$ cd C:/Users/user/my_project

После этого следует выполнить команду $ git init, в результате чего в выбранной папке создаётся подкаталог *.git

В данном подкаталоге на локальном устройстве создаётся вся необходимая для взаимодействия с Git инфраструктура, ключевыми элементами которой являются файлы Head, index, каталоги objects и refs.

Файл Head оглавляет операционную (текущую) ветку

Файл index сохраняет содержимое индекса.

В каталоге objects размещаются базы данных объектов Git.

В каталоге refs помещены ссылки на объекты коммитов каталога objects (ветки,теги).

Для резервного копирования или клонирования репозитория достаточно будет скопировать только подкаталог *.git.

При добавлении под контроль Git какого-либо файла, его следует добавить в индекс и произвести первый коммит изменений. Добавление происходит с помощью повторения команды:

$ git add *.*

$ git add License

После завершения выбора необходимо «закрыть» выполнение

$ git comit –m ‘Initial project version’

В результате возникает репозиторий с отслеживаемыми файлами и первоначальным коммитом.

В случае необходимости склонировать имеющийся репозиторий, надо выполнить команду

$ git clone https://github.com/librarygit1/librarygit1 – создаёт подкаталог в каталоге

или

$ git clone https://github.com/librarygit1/librarygit1 ourlibrarygit – создаёт подкаталог в каталоге ourlibrarygit

Применяемый протокол https:// может быть заменён на git://

git://github.com/librarygit1/librarygit1

или

user@server:path/to/repo.git – использует протокол SSH.

результате клонирования с сервера забираются все имеющиеся версии всех имеющихся файлов каталога.

Ветка в Git – кратко – это указатель последовательности измененных файлов.

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

Несколько веток можно свести в один коммит.

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

Между ветками в проекте в Git можно с лёгкостью переключаться, ветки могут также сливаться между собой, образуя из своих файлов один «узловой» файл.

Создание новой ветки в Git происходит с помощью команды git branch, и для ветки с именем experiment это можно организовать следующим образом:

$ git branch experiment

В результате появляются ветки master и experiment, указывающие на один и тот же коммит.

Слияние веток в Git – обратный процесс.

Допустим, следует произвести слияние каталога из 3-х файлов. Все их необходимо добавить в индекс и создать коммит.

При индексации происходит вычисление контрольной суммы каждого файла (SHA-1), каждый из файлов сохраняется в репозиторий, а контрольная сумма попадёт в индекс.

В Git такой файл называет blob-объект — большой бинарный объект:

$ git add README test.rb EXAMPLELICENSE

$ git commit -m ‘Initial commit’

При выполнении команды git commit, создающей коммит, Git вычисляет контрольные суммы каждого подкаталога, сохраняет его в репозитории как объект древа каталогов, а потом создаёт объект коммита с метаданными и указателем на основное дерево проекта, что даёт возможность воссоздать этот снимок в случае необходимости.

После выполнения операции в репозитории Git появится пять объектов: 3 blob-объекта (по одному на каждый файл из предыдущих коммитов), объект древа каталогов, содержащий список файлов и соответствующих им blob’ов, а также объект коммита, содержащий метаданные и указатель на объект древа каталогов.

Ветка в данной случае – перемещаемый указатель на один из предшествующих коммитов.

Указатель на основной ветке всегда указывает на последний коммит даже если он создан на любой из иных веток проекта. То есть указатель на ветке master хронологически перемещается вместе с коммитами на других ветках и встаёт напротив последнего из них по времени создания.

Для того, чтобы пользователь мог понять, в какой ветке он непосредственно находится, используется специальный указатель HEAD, а визуализация вызывается с помощью команды git log (опиция называется decorate)

Результат вызова команды:

$ git log –oneline –decorate

k10zx (HEAD -> master, experiment) Add feature #15 – ability to add new formats to the central in 66ac6 Fix bug #1323 – stack overflow under certain conditions 96ca6 Initial comit

показывают, что на коммит k10zx указывает как ветка master, так и experiment.

Переключение между ветками осуществляется командой git checkout. Например, для переключения на ветку experiment необходимо ввести команду

$ git checkout experiment

В результате HEAD будет указывать на ветку experiment.

При развитии проекта создадим следующий коммит 15xd3, находясь на ветке experiment. При этом он сохранится, даже если мы вернёмся обратно на ветку master, что автоматически вернёт нас на коммит k10zx.

Если по какой-либо причине возникла необходимость создать другой вариант проекта, отличный от коммита 15xd3, следует вернуться на предыдущий коммит k10zx, перейдя в ветку master, и создать новую ветвь от этого коммита.

Коммит – одно из важнейших понятий, описывающих работу с Git.

Если коротко, то коммит – это процесс сохранения состояния проекта (объекта, файла) в системе Git.

Каждый раз при создании коммита (сохранении состояния проекта) Git сохраняет его в виде объекта, который содержит указатель на «снимок» (snapshot) подготовленных данных, имя автора и его реквизиты (e-mail), сообщение и указатель на коммит (родителя) или коммиты (родителей), которые являются непосредственными предшественниками этого коммита.

У  первоначального коммита проекта родитель отсутствует.

Для коммита, появившегося в результате слияния двух и более веток, обязательны несколько родителей – по количеству сходящихся веток.

Помещая в коммит файл, предоставляя к нему ссылку, Git запоминает новый файл, только если он имеет отличия от предыдущей версии этого файла, который уже присутствует в системе. Git представляет свои данные как, скажем, поток таких «снимков» файла проекта.

Таким образом, можно сделать вывод, что в системе Git, если рассматривать её с точки зрения архитектуры, коммит является узлом ветвящегося древа сохранения данных, в множестве которых запечатлены несовпадающие варианты объектов проекта.

Мердж – это процесс слияния веток проекта.

Используется команда

$ git merge

После команды перечисляются ветки проекта, которые необходимо объединить

Выглядит это примерно так:

git merge [-n] [–stat] [–no-commit] [–squash] [–[no-]edit]

         [–no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]

         [–[no-]allow-unrelated-histories]

         [–[no-]rerere-autoupdate] [-m <msg>] [-F <file>]

         [–into-name <branch>] [<commit>…​]

git merge (–continue | –abort | –quit)

Пусть имеется следующая история проекта и текущая ветвь проекта является master:

           A—B—C info

          /

    D—E—F—G master

Затем “git merge info” воспроизведет изменения, внесённые в ветку темы с момента ее отклонения от master (в точке E) до ее текущей фиксации (C) поверх master, и запишет результат в новую фиксацию вместе с именами двух родительских коммитов и сообщением из журнала пользователя, описывающим изменения. Перед операцией ORIG_HEAD устанавливается на вершину текущей ветви (C).

           A—B—C info

          /                \

    D—E—F—G—H master

Второй синтаксис (“git merge –abort”) следует запускать только после того, как слияние привело к конфликтам. В этом случае, если введена команда “git merge –abort” система прервет процесс слияния и попытается восстановить состояние до слияния. Однако если при запуске слияния были внесены незафиксированные изменения (и особенно если эти изменения были дополнительно изменены после запуска слияния), “git merge –abort” в некоторых случаях не сможет восстановить исходные (до слияния) изменения.

Предупреждение: Не рекомендуется запускать git merge с нетривиальными незафиксированными изменениями: хотя это возможно, это может привести вас в состояние, из которого трудно выйти в случае конфликта.

Третий синтаксис (“git merge –continue”) может быть запущен только после того, как конфликт, к которому привело слияние, разрешён.

Таким образом, Git – это система управления вариантами проекта, основными понятиями которой являются: проект, репозиторий, ветка, пуш, мердж, коммит, слияние, разделение.