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 по каким-то причинам не может этого сделать -- он не позволит вам переключиться.