Лабораторная работа №1 Установка и настройка распределенной системы контроля версий git. Основные принципы работы

1.1 Теоретическое введение

Распределенная система контроля версий — это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определённой версии.Она позволяет вернуть файлы к состоянию, в котором они были до изменений, вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и вызвал проблему, кто поставил задачу и когда, и многое другое. Использование СКВ также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить. В дополнение ко всему вы получите всё это без каких-либо дополнительных усилий.

Git можно использовать на операционных системах Windows, Linuxи Mac. Для каждой операционной системы предназначен свой файл установки. Также учтена разрядность компьютера и для каждой ОС присутствует программа как для 32-х разрядной системы, так и для 64-х разрядной.

Основные принципы работы с Git

Основное отличие Git’а от любой другой СКВ, это подход Git’а к работе со своими данными.Концептуально, большинство других систем хранят информацию ввиде списка изменений в файлах. Эти системы (CVS, Subversion, Perforce, Bazaar и т.д.) представляют информацию в виде набора файлов и изменений, сделанных в каждом файле, по времени.

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

Рисунок 1 – Хранение данных как снимков проекта во времени

Три состояния

Git имеет три основных состояния, в которых могут находиться ваши файлы: зафиксированном (committed), изменённом (modified) и подготовленном (staged). “Зафиксированный” значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит. Мы подошли к трём основным секциям проекта Git: Git директория (Gitdirectory), рабочая директория (workingdirectory) область подготовленных файлов (stagingarea) (рисунок 2).

Рисунок 2 – Рабочая директория, область stage и директория Git

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

Рабочая директория является снимком версии проекта. Файлы распаковываются из сжатой базы данных в Git директории и располагаются на диске, для того, чтобы их можно было изменять и использовать.

Область подготовленных файлов — это файл, располагающийся в вашей Git директории, в нём содержится информация о том, какие изменения попадут в следующий коммит. Эту область ещё называют “индекс”, однако называть её stage область также общепринято.

Первоначальная настройка Git

После установки Git необходимо настроить среду работы. Это нужно сделать только один раз — при обновлении версии Git’а настройки сохранятся. Но, при необходимости, вы можете поменять их в любой момент, выполнив те же команды снова.

В состав Git’а входит утилита gitconfig , которая позволяет просматривать и настраивать параметры, контролирующие все аспекты работы Git’а, а также его внешний вид. Эти параметры могут быть сохранены в трёх местах:

1. Файл /etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске gitconfig указать параметр --system , то параметры будут читаться и сохраняться именно в этот файл.

2. Файл ~/.gitconfig или ~/.config/git/config хранит настройки конкретного пользователя. Этот файл используется при указании параметра --global .

3. Файл config в каталоге Git’а (т.е. .git/config ) в том репозитории, который вы используете в данный момент, хранит настройки конкретного репозитория.

Имя пользователя

Первое, что вам следует сделать после установки Git’а, — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git’е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:

$ gitconfig --global user.name "Ivanov Ivan"

$ gitconfig --global user.emailivanovvv@example.com

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

Выбор редактора

Теперь, когда вы указали своё имя, самое время выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git’е. По умолчанию Git использует стандартный редактор вашей системы, которым обычно является Vim. Если вы хотите использовать другой текстовый редактор, например, Emacs, можно проделать следующее:

$ gitconfig --global core.editoremacs

Проверканастроек

Если вы хотите проверить используемую конфигурацию, можете использовать команду gitconfig --list , чтобы показать все настройки, которые Git найдёт:

$ gitconfig --list

user.name=John Doe

user.email=johndoe@example.com

color.status=auto

color.branch=auto

color.interactive=auto

color.diff=auto

...

Некоторые ключи (названия) настроек могут появиться несколько раз, потому что Git читает один и тот же ключ из разных файлов (например из /etc/gitconfig и ~/.gitconfig ). В этом случае Git использует последнее значение для каждого ключа.

Также вы можете проверить значение конкретного ключа, выполнив gitconfig<key> :

$ gitconfiguser.name

JohnDoe

Создание репозитория в существующей дирекции

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

$ gitinit

Эта команда создаёт в текущей директории новую поддиректорию с именем .git , содержащую все необходимые файлы репозитория —основу Git-репозитория.

Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит добавить их в индекс и осуществить первый коммит изменений. Добиться этого вы сможете запустив команду gitadd несколько раз, указавиндексируемые файлы, а затем выполнив gitcommit :

$ git add *.c

$ git add LICENSE

$ git commit -m 'initial project version'

Работа с удаленными репозиториями

Чтобы иметь возможность совместной работы над каким-либо Git-проектом, необходимо знать, как управлять удалёнными репозиториями. Удалённые репозитории — это модификации проекта, которые хранятся в интернете или ещё где-то в сети. Их может быть несколько, каждый из которых, как правило, доступен для вас либо только на чтение, либо на чтение и запись. Совместная работа включает в себя управление удалёнными репозиториями и помещение (push) и получение (pull) данных в и из них тогда, когда нужно обменяться результатами работы. Управление удалёнными репозиториями включает умение добавлять удалённые репозитории, удалять те из них, которые больше не действуют, умение управлять различными удалёнными ветками и определять их как отслеживаемые (tracked) или нет и прочее. Данный раздел охватывает все перечисленные навыки по управлению удалёнными репозиториями.

Git умеет работать с четырьмя сетевыми протоколами для передачи данных: локальный, SecureShell (SSH), Git и HTTP. В этой части мы обсудим каждый из них и в каких случаях стоит (или не стоит) их использовать.

Важно понимать, что за исключением протокола HTTP, все эти протоколы требуют, чтобы Git был установлен и работал на сервере.

Примечание:

Если Вы используете локальный протокол, то для того, чтобы вести контроль версий проекта в составе команды на нескольких компьютерах необходимо сделать на каждом из компьютеров папку, доступную для всех (название этой папки лучше сделать одинакоковой). Именно в эти папки и будут клонироваться (копироваться) репозитарии.

Просмотр удалённых репозиториев

Для того, чтобы просмотреть список настроенных удалённых репозиториев, вы можете запустить команду gitremote.

Вы можете также указать ключ -v, чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:

$ gitremote -v

Если у вас больше одного удалённого репозитория, команда выведет их все.

Добавление удалённых репозиториев: gitfetchpb – просматривает удаленный репозиторий и сливает его с веткой

$ gitfetchpb

remote: Counting objects: 43, done.

remote: Compressing objects: 100% (36/36), done.

remote: Total 43 (delta 10), reused 31 (delta 5)

Unpacking objects: 100% (43/43), done.

From https://github.com/paulboone/ticgit

* [new branch] master ->pb/master

* [new branch] ticgit ->pb/ticgit

Ветка master из репозитория сейчас доступна нам под именем pb/master. Ее можно сливать со своими ветками. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду gitremoteadd [shortname] [url]:

$ git remoteorigin

$ git remote add pb https://github.com/paulboone/ticgit

$ git remote -v

origin https://github.com/schacon/ticgit (fetch)

origin https://github.com/schacon/ticgit (push)

pb https://github.com/paulboone/ticgit (fetch)

pb https://github.com/paulboone/ticgit (push)

Теперь вместо указания полного пути вы можете использовать pb.

Получение изменений из удалённого репозитория - Fetch и Pull

Для получения данных из удалённых проектов, следует выполнить:

$ gitfetch [remote-name]

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

Отправка изменений в удаленный репозиторий (Push)

Когда вы хотите поделиться своими наработками, вам необходимо отправить (push) их в главный репозиторий. Команда для этого действия простая: gitpush [remote-name] [branch-name]. Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование, как правило, настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки наработок на сервер:

$ gitpushorigin/master

Просмотр удаленного репозитория

Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду gitremoteshow [remote-name].

Удаление и переименование удалённых репозиториев

Для переименования ссылок в новых версиях Git’а можно вылолнитьgitremoterename, это изменит сокращённое имя, используемое для удалённого репозитория. Например, если вы хотите переименовать pb в paul, вы можете это сделать при помощи gitremoterename:

$ git remote rename pbpaul

$ git remote

origin

paul

Стоит упомянуть, что это также меняет для вас имена удалённых веток. То, к чему вы обращались как pb/master, теперь стало paul/master.

Определение состояния файлов

Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда gitstatus . Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого:

$ git status

On branch master

nothing to commit, working directory clean

Это означает, что у вас чистый рабочий каталог, другими словами – в нем нет отслеживаемых измененных файлов.

Отслеживание новых файлов

Для того чтобы начать отслеживать (добавить под версионный контроль) новый файл, используется команда gitadd . Чтобы начать отслеживание файла README, вы можете выполнить следующее:

$ gitadd README

Ветвление в Git

Ветка (branch) в Git — это легко перемещаемый указатель на один из этих коммитов. Имя основной ветки по умолчанию в Git — master .

Когда вы делаете коммиты, то получаете основную ветку, указывающую на ваш последний коммит. Каждый коммит автоматически двигает этот указатель вперед (рисунок 3).

Ветка “master” в Git — это не специальная ветка. Она точно такая же, как и все остальные ветки. Она существует почти во всех репозиториях только лишь потому, что ее создает команда gitinit , а большинство людей не меняют ее название.

Рисунок 3 – Ветка и история коммитов

Создание новой ветки

Когда вы создаете ветку, то создается новый указатель для дальнейшего перемещения. Допустим вы хотите создать новую ветку с именем “testing” Вы можете это сделать командой gitbranch :

$ gitbranchtesting

В результате создается новый указатель на тот же самый коммит, в котором вы находитесь (рисунок 4).

Рисунок 4 – Две ветки указывают на одну и ту же последовательность коммитов, HEAD указывает на ветку

При помощи команды gitlog можно узнать, куда указывают указатели веток.

$ git log --oneline --decorate

f30ab (HEAD, master, testing) add feature #32 - ability to add new