Система управления версиями программа Git

Размещено на http://www.allbest.ru/

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

34ac2 fixed bug #1328 - stack overflow under certain conditions

98ca9 initial commit of my project

Переключение веток

Чтобы переключиться на существующую ветку, выполните команду gitcheckout. Давайте переключимся на ветку “testing”: $ gitcheckouttesting

В результате указатель HEAD переместится на ветку testing.

Какой в этом смысл? Давайте сделаем еще один коммит (рисунок 5):

$ vimtest.rb

$ git commit -a -m 'made a change'

Рисунок 5 - Указатель на ветку HEAD переместился вперед после коммита

Чтобы переключиться на ветку master: $ gitcheckoutmaster

Эта команда сделала две вещи. Она переместила указатель HEADназад на ветку “master” и вернула файлы в рабочем каталоге в то состояние, которое было сохранено в снимке (snapshot), на который указывает ветка.

Переключение веток меняет файлы в рабочем каталоге

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

Удаленные ветки (имя удаленного репозитория)/(имя ветки)

Клонировали репозиторий.



Если еще кто-то склонировалрепозиторий или кто-то еще правит на сервере данные, то истории продолжаются по-разному:

Для синхронизации служит команда gitfetchorigin

Для создания своей ветки, аналогичной удаленной, можно воспользоваться командой:

Gitcheckout -b (имя ветки) (удаленный репозиторий)/(ветка)

Это дает локальную ветку, над которой можно работать, она будет начинаться там же, где и серверная ветка.

Получение изменений осуществляется командой gitfetch

Примерработы с ветками:

$ git checkout -b iss53

Равнозначно $git branch iss53

$ gitcheckout iss53

$ git checkout master

$ git checkout -b hotfix

$ vim index html

$ git commit -a -m `fixed the broken email address'

$ git checkout master

$ git merge hotfix

Удаление ветки: gitbranch -d hotfix

Можно влить ветку master в iss53: gitmergemaster, а можно ветку iss53 в master.

Перенос на ветку, в которой хотели внести изменения:

$ git checkout master

$ git merge iss53



Теперь можно удалить ветку iss53: $ gitbranch -Diss53

Конфликты при слиянии

Иногда процесс слияния не идёт гладко. Если вы изменили одну и ту же часть файла по-разному в двух ветках, которые собираетесь слить, Git не сможет сделать это чисто.Git не создает новый коммит для слияния. Он приостанавливает этот процесс до тех пор, пока вы не разрешите конфликт вручную. Если вы хотите посмотреть, какие файлы не прошли слияние (на любом этапе после возникновения конфликта), выполните команду gitstatus. Всё, что имеет отношение к конфликту слияния и что не было разрешено, отмечено как unmerged. Git добавляет стандартные маркеры к файлам, которые имеют конфликт, так что вы можете открыть их вручную и разрешить эти конфликты. В верхней части блока (всё что выше =) это версия из HEAD (вашей ветки master, так как именно на неё вы перешли перед выполнением команды merge), всё, что находится в нижней части - содержимое сливаемой ветки. Чтобы разрешить конфликт, вы должны либо выбрать одну из этих частей, либо как-то объединить содержимое по своему усмотрению.

После того как вы разобрались с каждой из таких секций в каждом из конфликтных файлов, выполните gitadd для каждого конфликтного файла. Индексирование будет означать для Git'а, что все конфликты в файле теперь разрешены. После чего можно осуществлять команду gitcommitи слияние завершится.

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

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

$ gitmergetool

Последует вопрос какой программой для слияния вы хотели бы воспользоваться, просто введите meld и нажмите Enter. Вот как окно программы может выглядеть - рисунок.

Рисунок 6

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

После того как вы выйдете из инструмента для выполнения слияния, Git спросит вас, было ли оно успешным. Если вы отвечаете, что да -- файл индексируется (добавляется в область для коммита), чтобы дать вам понять, что конфликт разрешён.

После чего также осуществляет фиксация изменений и слияние считается завершенным.

Примечание: Для более подробного изучения программы Git можно воспользоваться книгой «ProGit», доступную для чтения на официальном сайте Git: Scott Chacon, Ben Straub«ProGit» Second Edition

2 УстановкаGit на сервере

Для установки Git необходимо посылке скачать файл 64-bitGitforWindowsSetup. Скачается самая актуальная версия.

Рисунок 7 Запускаем файл.

Рисунок 8 Выбираем «Next».

Выбираем директорию, куда будет установлен Git. Выбор папки осуществляется нажав «Browse..». Затем переходим далее - «Next».

Рисунок 9

Выбираем AdditionalIcons для создания иконки на рабочем столе и выбираем далее.

Рисунок 10

Далее будет предложено выбрать имя папки, которая создастся в меню пуск для программы. Также можно не создавать папку в меню пуск выбрав «Don'tcreateaStartMenufolder».



Рисунок 11

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

Рисунок 12

Предполагается выбор быстрых клавиш в зависимости от операционной системы. Выбираем первый вариант и переходим далее.



Рисунок 13

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

управление версия файл репозиторий программа git

Рисунок 14

Выбираем первые два варианта и нажимаем Install.



Рисунок 15

Нажимаем Finish. Установка Gitзавершена.

3. Установка программыGit на клиенте

Программа устанавливается одинаково на два компьютера: клиент и сервер. Следовательно, выполняем аналогичные действия, как в пункте 1.2.

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

Настройка программы выполнена. Теперь необходимо выполнить настройку клиентской и серверной части программы. Git предоставлет возможность отслеживать файлы, находящиеся в разных директориях на одном ПК (для организации конроля версий собственных проектов), а также возможность организации intranet (internet) работы и отслеживания файлов, когда один компьютер играет роль сервера - места хранения репозитория для организации общего доступа и параллельной работы большинства пользователей. Так как для организации параллельной работы необходимо общее хранилище, с которым и будут работать пользователи. Данное хранилище будет располагаться на отдельном ПК. Следовательно, необходимо организовать разную настройку клиентских компьютеров и компьютера, предназначенного для сервера.

4. Настройка программыGitна клиенте

В системах семейства Windows Git ищет файл .gitconfig в каталоге $HOME (C:\Users\$USER для большинства пользователей). Кроме того, Git ищет файл /etc/gitconfig, но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git, когда запускали инсталлятор.

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

Чтобы поменять директорию каталога создадим папку HOMEна диске С.

Рисунок 16

Далее заходим в свойства компьютера.

Рисунок 17

И выбираем дополнительные параметры системы. Открываем переменные среды. Также можно просто в поисковой строке ввести «Переменные среды».

Рисунок 18

Создаем переменную HOME. Указываем путь к расположению директории в которой будут храниться настройки git

Рисунок 19

Нажимаем Ок.

Примечание! Устанавливать программу необходимо на диск C. Также переменную создавать обязательно и прописывать прописными буквами (HOME). При установке на другие диски программа работать не будет.

Настройка клиента

Запускаем Gitот имени администратора. В текстовую сроку вводим следующее:



Рисунок 20

Данная команда предназначена для генерации ssh-ключа для получения доступа по локальной сети к компьютеру, являющимся сервером.

На все вопросы утилиты нажимаем "Enter", ничего вводить более не нужно. Все, связка публичного и приватного ключа сгенерирована.

Рисунок 21

Папка со сгенерированным ключем автоматически появится в каталоге C:\HOME. Она сохранена под названием ~/.ssh. Публичный ключ лежит в ~/.ssh/id_rsa.pub. Его содержимое будет в формате:

ssh-rsaAAAAB3NzaC1…….qUMyoofI6HV9B user@DESKTOP-6IA80O6



Рисунок 22

Далее, что следует сделать -- указать имя и адрес электронной почты пользователя. Это важно, потому что каждый коммит в Git'е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена

Рисунок 23

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

Рисунок 24

Настройка Git на клиентской машине закончена. Приступим к настройке сервера.

5. Настройка программыGit на сервере

В системах семейства Windows Git ищет файл .gitconfig в каталоге $HOME (C:\Users\$USER для большинства пользователей). Кроме того, Git ищет файл /etc/gitconfig, но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git, когда запускали инсталлятор.

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

Чтобы поменять директорию каталога создадим папку HOMEна диске С.

Далее заходим в свойства компьютера.

И выбираем дополнительные параметры системы. Открываем переменные среды. Также можно просто в поисковой строке ввести «Переменные среды».



Рисунок 25

Рисунок 26

Рисунок 27

Создаем переменную HOME. Указываем путь к расположению директории в которой будут храниться настройки git

Рисунок 28

Нажимаем Ок.

Примечание! Устанавливать программу необходимо на диск C. Также переменную создавать обязательно и прописывать прописными буквами (HOME). При установке на другие диски программа работать не будет.

Настройка сервера

На серверном компьютере запускаем Git от имени администратора и создаем пользователяgit с помощью которого можно будет пользоваться репозиторем:

Рисунок 29

Командой Cdбыл выполнен переход в папку HOME, расположенную на диске С. Командой mkdirв данной папке была создана папка .ssh, которая предназначается для хранения сгенерированных на клиентских компьютерах ключей доступа. Если открыть папку HOME после выполнения данных команд, папка будет иметь вид:

Рисунок 30

Затем, нужно добавить открытый SSH-ключ клиента в файл authorized_keys этого пользователя. Ранее, был сгенерирован ключ для клиента. Скопировав файл id_rsa.pubна носитель, копируем его в папку .sshсерверного компьютера. Идалее добавляем в файл authorized_keys:

$ cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys

Илитак:

$ echo 'ssh-rsa....ababbASFf1...... oleg@machine' >> ~/.ssh/authorized_keys

Теперь создаем Git-репозиторий на сервере:

$ cd ~

$ mkdirmyproject.git

$ cdmyproject.git

$ git --bareinit

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



Рисунок 31

В данной папке также уже создан пустой репозиторий.

Задания для самостоятельной работы:

1. Создать репозиторий с номером бригады на серверном компьютере

2. Добавить в созданныйрепозиторий файл(ы)

3. Изменять содержимое файлов, проверять состояние (команда gitstatus)

4. Создать веткина клиентских компьютерах (называть ветку фамилией участника бригады) и склонироватьрепозиторий с сервера

5. Изменяйте файлы находясь на созданных ветках. Проверяйте изменение содержимого файлов, отправляйте изменения на сервер. На сервере, осуществляя переходы между ветками (созданные клиентские ветки, основная ветка master)

6. Произвести слияние веток на сервере

7. Удалите созданные ветки с сервера

Размещено на Allbest.ru

...