| blob | 87d0ad3505ea3384cdb04025d756872b53163254 |
1 # Введение #
3 Эта глава о том, как начать работу с Git. Сначала мы объясним основы инструментов управления версиями, затем — как запустить Git на вашей машине и наконец как настроить его, чтобы можно было работать. К концу главы вы будете понимать, для чего Git вообще сделан, почему вам следует пользоваться им, и будете уметь настраивать его.
5 ## Об управлении версиями ##
7 Что такое управление версиями, и какое вам до него дело? Управление версиями — это система, сохраняющая изменения в файле или нескольких файлах, чтобы потом можно было видеть нужные старые версии. Для примеров в этой книге вы будете использовать исходные коды программ, но на самом деле можно управлять версиями практически любых типов файлов.
9 Если вы графический или веб-дизайнер и хотите хранить каждую версию изображения или макета - вот это вам наверняка нужно -- то пользоваться системой управления версиями будет очень мудрым решением. Она позволяет вернуть файлы к прежнему виду, вернуть к прежнему состоянию весь проект, сравнить изменения с какого-то времени, увидеть, кто последним изменял модуль, который дал сбой, кто создал проблему, и так далее. Вообще, если, пользуясь СУВ, вы всё испортили или потеряли файлы, всё можно легко восстановить. Кроме того, издержки на всё это будут очень маленькими.
11 ### Локальные системы контроля версий. ###
13 Многие люди чтобы управлять версиями, просто копируют файлы в другую папку (умные ещё пишут текущую дату в название папки). Такой подход очень распространён, потому что прост, но он ещё и чаще даёт сбои. Очень легко забыть, что ты не в той папке и случайно изменить не тот файл, либо скопировать и перезаписать файлы не туда, куда хотел.
15 Чтобы решить эту проблему, программисты уже давно разработали локальные СУВ, с простой базой данных, в которой хранились все изменения нужных файлов (см. рисунок 1-1).
17 Insert 18333fig0101.png
18 Рисунок 1-1. Схема локальной СУВ
20 Одной из наиболее популярных СУВ данного типа является rcs, которая до сих пор устанавливается на многие компьютеры. Даже в современной операционной системе Mac OS X утилита rcs устанавливается вместе с Developer Tools. Эта утилита основана на работе с наборами патчей между парами изменений (патч - файл, описывающий различие между файлами), которые хранятся в специальном формате на диске. Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи.
22 ### Централизованные системы управления версиями ###
24 Следующей большой проблемой оказалась необходимость сотрудничать с разработчиками за другими компьютерами. Чтобы решить её, были созданы централизованные системы управления версиями (ЦСУВ). В таких системах, например CVS, Subversion и Perforce, есть центральный сервер, на котором хранятся все отслеживаемые файлы, и ряд клиентов, которые получают копии файлов из него. Много лет это был стандарт управления версиями (см. рис. 1-2).
26 Insert 18333fig0102.png
27 Рисунок 1-2. Схема централизованного управления версиями
29 Такой подход имеет множество преимуществ, особенно над локальными СУВ. К примеру, все знают кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать ЦСУВ гораздо легче чем локальные базы на каждом клиенте.
31 Однако есть и несколько серьёзных недостатков при таком подходе. Наиболее очевидный - централизованый сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новые версии. Если же повреждается диск с центральной базой данных, и нет резервной копии, вы теряете абсолютно всё - всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей. Локальные системы управления версиями подвержены той же проблеме - если вся история проекта хранится в одном месте, вы рискуете потерять всё.
33 ### Распределённые системы контроля версий ###
35 В такой ситуации в игру вступают распределенные системы управления версиями (РСУВ). В таких системах как Git, Mercurial, Bazaar или Darcs, клиенты не просто забирают последние версии файлов, а полностью копируют репозиторий. Поэтому в случае, когда "умирает" сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, создаётся полная копия всех данных (см. рисунок 1-3).
37 Insert 18333fig0103.png
38 Рисунок 1-3. Схема распределенной системы управления версиями
40 Кроме того, в большей части этих систем можно работать с несколькими удаленными репозиториями, таким образом, можно одновременно работать по-разному с разными группами людей в рамках одного проекта. Так в одном проекте можно одновременно вести несколько типов рабочих процессов, что невозможно в централизованных системах.
42 ## Краткая история Git ##
44 Как и многие замечательные вещи, в некотором роде, Git начинался с отказа от имеющихся решений и жарких споров. Ядро Linux - действительно очень большой открытый проект. Бо́льшую часть существования ядра Linux (1991-2002) изменения вносились в код путем приёма патчей и архивирования версий. В 2002 году проект перешёл на проприетарную РСУВ BitKeeper.
46 В 2005 отношения между сообществом разработчиков ядра Linux и владельцем BitKeeper испортились, и право бесплатного пользования продуктом было отменено. Это подтолкнуло разработчиков Linux (и в частности Линуса Торвальдса, создателя Linux) разработать собственную систему, основываясь на опыте, полученном за время пользования BitKeeper. Основные требования к новой системе были следующими:
48 * Скорость
49 * Простота дизайна
50 * Поддержка нелинейной разработки (тысячи параллельных веток)
51 * Полная распределенность
52 * Возможность эффективной работы с такими большими проектами как ядро Linux (как по скорости, так и по размеру данных)
54 С момента рождения в 2005 Git разрабатывали так, чтобы он был простым в использовании, сохранив свои первоначальные свойства. Он невероятно быстр, очень эффективен для больших проектов, а также обладает превосходной системой ветвления для нелинейной разработки (см. главу 3).
56 ## Основы Git ##
58 Так что же такое Git в двух словах? Эту часть важно усвоить, поскольку если вы поймете, что такое Git, и каковы принципы его работы, вам будет гораздо проще пользоваться им эффективно. Изучая Git, постарайтесь освободиться от всего, что вы знали о других СУВ, таких как Subversion или Perforce. В Git совсем другие понятия об информации и работа с ней, чем в других системах, хотя пользовательский интерфейс очень похож. Знание этих различий, защитит вас от путаницы при пользовании Git.
60 ### Слепки вместо патчей ###
62 Главное отличие Git от любых других СУВ (например, Subversion и ей подобных) заключается в понятии о данных. В принципе, большинство других систем хранит информацию как список изменений (патчей) файлов. Эти системы (CVS, Subversion, Perforce, Bazaar и другие) относятся к хранимым данным как к набору файлов и изменениям в каждом из них во времени, как показано на рисунке 1-4.
64 Insert 18333fig0104.png
65 Рисунок 1-4. Другие системы хранят данные как изменения к базовой версии для каждого файла.
67 Git хранит данные другим способом. Вместо этого Git считает хранимые данные набором слепков небольшой файловой системы. Каждый раз когда вы фиксируете текущую версию проекта, Git по сути сохраняет слепок того, как выгядят все файлы проекта на текущий момент. Ради эффективности, если файл не менялся, Git не сохраняет файл снова, а делает ссылку на ранее сохранённый файл. Подход Git к хранению данных приблизительно показан на рисунке 1-5.
69 Insert 18333fig0105.png
70 Рисунок 1-5. Git хранит данные как слепки состояний проекта во времени.
72 Это важное отличие Git от практически всех других систем управления версиями. Поэтому Git пересматривает практически все аспекты управления версиями, которые другие системы взяли от своих предшественниц. Git больше похож на небольшую файловую систему с невероятно мощными инструментами работающими поверх неё, чем на просто СУВ. В главе 3, коснувшись работы с ветвями в Git, мы узнаем, какие преимущества даёт такое понимание данных.
74 ### Почти все операции - локальные ###
76 Для совершения большинства операций в Git необходимы только локальные файлы и ресурсы, т.е. обычно информация с других компьютеров в сети не нужна. Если вы пользовались централизованными системами, где практически на каждую операцию накладывается сетевая задержка, возможно, подумаете, что боги наделили Git неземной силой. Поскольку вся история проекта хранится локально у вас на диске, большинство операций выглядят практически мгновенными.
78 К примеру, чтобы показать историю проекта, Git-у не нужно скачивать её с сервера, он просто читает её прямо из вашего локального репозитория. Поэтому историю вы увидите практически мгновенно. Если вам нужно просмотреть изменения между текущей версией файла и версией, сделанной месяц назад, Git может взять файл месячной давности и вычислить разницу на месте, вместо того чтоб запрашивать разницу у сервера СУВ или качать с него старую версию файла и делать локальное сравнение.
80 Также работа локально означает, что мало чего нельзя сделать без доступа к Сети или VPN. Если вы в самолете или в поезде и хотите немного поработать, можно спокойно сохранять новые версии и загрузить их, когда будет доступна сеть. Если вы пришли домой, а VPN клиент не работает, всё равно можно продолжать работать. Во многих других системах это невозможно, или же крайне неудобно. Например, используя Perforce, вы мало чего можете сделать без соединения с сервером. Работая с Subversion и CVS, вы можете редактировать файлы, но сохранить изменения в вашу базу данных нельзя (потому что она отключена от репозитория). Вроде ничего серьёзного, но потом вы удивитесь, насколько это меняет дело.
82 ### Git следит за целостностью данных ###
84 Перед сохранением любого файла Git вычисляет контрольную сумму, и она становится индексом этого файла. Поэтому невозможно изменить содержимое файла или папки, и Git не узнал бы об этом. Эта функциональность внедрена в самом фундаменте Git и является важной составляющей его философии. Если информация потеряется при передаче или повредится на диске, Git всегда это выявит.
86 Механизм, используемый Git для вычисления контрольных сумм, называется хэш SHA-1. Это шестнадцатиричное число (0-9 и a-f) длиной 40 знаков, оно вычисляется на основе содержимого файла или структуры папки, хранимой Git. Хэш SHA-1 выглядит примерно так:
88 24b9da6552252987aa493b52f8696cd6d3b00373
90 Работая с Git, вы будете постоянно встречать эти хэши, поскольку они широко используются. Фактически, в своей базе данных Git сохраняет всё не по именам файлам, а по хэшам их содержимого.
92 ### Чаще всего данные в Git только добавляются ###
94 Практически все действия, которые вы совершаете в Git, только добавляют данные в базу. Очень сложно заставить систему удалить данные или сделать что-то неотменяемое. Можно, как и в любой другой СУВ, потерять данные, которые вы ещё не сохранили, но как только они зафиксированы, их очень сложно потерять, особенно если вы регулярно отправляете изменения в другой репозиторий.
96 Поэтому пользоваться Git - удовольствие, потому что можно экспериментировать, не боясь серьёзно что-то поломать. Чтобы детальнее узнать, как Git хранит данные, и как восстановить то, что кажется уже потерянным, читайте раздел "Под капотом" в главе 9.
98 ### Три состояния ###
100 Теперь внимание. Самое важное, что нужно помнить про Git, если вы хотите, чтобы дальше изучение шло гладко. В Git файлы могут находиться в одном из трёх состояний: зафиксированные, изменённые и подготовленные. "Зафиксированный" значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы – это изменённые файлы, отмеченные для включения в следующий коммит.
102 Таким образом, в проекте с использованием Git есть три части: каталог Git (Git directory), рабочая папка (working directory) и область подготовленных файлов (staging area).
104 Insert 18333fig0106.png
105 Рисунок 1-6. Рабочий каталог, область подготовленных файлов, каталог Git.
107 Папка Git – это место, где Git хранит метаданные и базу данных объектов вашего проекта. Это наиболее важная часть Git, и именно она копируется, когда вы клонируете репозиторий с другого компьютера.
109 Рабочая директория — это извлеченная из базы копия определённой версии проекта. Эти файлы, взятые из сжатой базы данных в папке Git и помещённые на диск, чтобы просматривать и редактировать их.
111 Область подготовленных файлов — это обычный файл, обычно хранящийся в папке Git, который содержит информацию о том, что должно войти в следующий коммит. Иногда его называют индексом (index), но последнее время становится стандартом называть ее областью подготовленных фалов (staging area).
113 Стандартный рабочий процесс с использованием Git выглядит примерно так:
115 1. Вы изменяете файлы в вашей рабочей папке.
116 2. Вы подготавливаете файлы, добавляя их слепки в область подготовленых файлов.
117 3. Вы делаете коммит, при этом слепки из области подготовленных файлов сохраняются в каталог Git.
119 Если рабочая версия файла совпадает с версией в каталоге Git, файл считается зафиксированным. Если файл изменён, но добавлен в область подготовленных данных, он подготовлен. Если же файл изменился после выгрузки из БД, но не был подготовлен, то он считается изменённым. В главе 2 вы узнаете больше об этих трёх состояниях и как можно либо воспользоваться этим, либо пропускать стадию подготовки.
121 ## Установка Git ##
123 Настало время немного ознакомиться с использованием Git. Первое, что вам необходимо сделать – установить его. Есть несколько способов сделать это; два основных ― установка из исходников и установка собранного пакета для вашей платформы.
125 ### Установка из исходников ###
127 При возможности обычнно полезно установить Git из исходных кодов, поскольку вы получаете самую свежую версию. Каждая новая версия Git обычно включает полезные улучшения пользовательского интерфейса, поэтому получение последней версии - часто лучший путь, если конечно вас не затрудняет установка программ из исходников. Это также правильный выбор, поскольку многие дистрибутивы Linux содержат очень старые пакеты, поэтому если вы не используете очень часто обновляемый дистрибутив или пакеты из экспериментальной ветки дистрибутива, установка из исходников может быть лучшим способом.
129 Для установки Git вам понадобятся библиотеки, от которых Git зависит: curl, zlib, openssl, expat, и libiconv. Например, если в вашей системе менеджер пакетов ― yum (Fedora), или apt-get (Debian, Ubuntu), можно воспользоваться следующими командами, чтобы разрешить все зависимости:
131 $ yum install curl-devel expat-devel gettext-devel \
132 openssl-devel zlib-devel
134 $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
135 libz-dev
137 Установив все необходимые библиотеки, можно идти дальше и скачать последнюю версию с сайта Git:
139 http://git-scm.com/download
141 Теперь скомпилируйте и установите:
143 $ tar -zxf git-1.6.0.5.tar.gz
144 $ cd git-1.6.0.5
145 $ make prefix=/usr/local all
146 $ sudo make prefix=/usr/local install
148 После этого можно скачать при помощи Git его же исходный код, чтобы получать обновления:
150 $ git clone git://git.kernel.org/pub/scm/git/git.git
152 ### Установка в Linux ###
154 Если вы хотите установить Git под Linux как бинарный пакет, это можно сделать, используя обычный менеджер пакетов вашего дистрибутива. Если у вас Fedora, можно воспользоваться yum:
156 $ yum install git-core
158 Если же у вас дистрибутив, основанный на Debian, например Ubuntu, попробуйте apt-get:
160 $ apt-get install git-core
162 ### Установка на Mac ###
164 Есть два простых способа установить Git на Mac. Самый простой ― использовать графический инсталлятор Git, который вы можете скачать со страницы Google Code (см. рисунок 1-7):
166 http://code.google.com/p/git-osx-installer
168 Insert 18333fig0107.png
169 Рисунок 1-7. Инсталлятор Git под OS X.
171 Другой распространенный способ установки Git ― через MacPorts (`http://www.macports.org`). Если у вас установлен MacPorts, установите Git так:
173 $ sudo port install git-core +svn +doc +bash_completion +gitweb
175 Вам не нужно устанавливать все дополнения, но, вероятно, вам понадобится +svn, если когда-нибудь захотите использовать Git вместе с репозиториями Subversion (см. главу 8).
177 ### Установка в Windows ###
179 Установка Git в Windows очень проста. У проекта msysGit процедура установки ― одна из самых простых. Просто скачайте файл exe инсталлятора со страницы Google Code и запустите его:
181 http://code.google.com/p/msysgit
183 После установки у вас будет как консольная версия (включающая SSH-клиент, который пригодится позднее), так и стандартная графическая.
185 ## Первоначальная настройка Git ##
187 Теперь, когда Git установлен на вашей системе, вы захотите сделать пару вещей чтобы настроить вашу среду Git. Это нужно сделать только один раз ― при обновлении настройки сохраняются. Но вы можете их поменять в любой момент выполнив команды снова.
188 В состав Git входит утилита git config которая позволяет вам просматривать и устанавливать параметры, котролирующие все аспекты работы и внешнего вида Git. Эти параметры могут быть сохранены в трех местах:
190 * файл `/etc/gitconfig`. Содержит значения общие для всех пользователей вашей системы и всех их репозиториев. Если вы указываете параметр `--system`, запуская `git config`, то параметры читаются и сохраняются в этот файл.
191 * файл `~/.gitconfig`. Хранит настройки конкретного пользователя. Этот файл использутеся при указании параметра `--global`.
192 * конфигурационный файл в каталоге Git (`.git/config`) в том репозитории, где вы находитесь в данный момент. Эти параметры ― только для данного конкретного репозитория. Настройки на каждом уровне перекрывают настройки из предыдущего, то есть значения в `.git/config` перекрывают соответствующие значения в `/etc/gitconfig`.
194 В системах семейства Windows, файл `.gitconfig` хранится в каталоге $HOME (`C:\Documents and Settings\$USER` для большинства пользователей). Кроме того Git ищет файл /etc/gitconfig относительно корневого каталога MSys, который вы указали в инсталляторе Git во время установки.
196 ### Имя пользователя ###
198 Первое, что вам следует сделать после установки Git ― указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:
200 $ git config --global user.name "John Doe"
201 $ git config --global user.email johndoe@example.com
203 Повторюсь, что эти настройки нужно сделать один раз, если вы указываете параметр `--global`, поскольку в этом случае Git будет использовать эти данные для всего, что вы делаете в этой системе. Если вы хотите указать другое имя или электронную почту для конкретных проектов, можно выполнить команду без параметра `--global` в папке с нужным проектом.
205 ### Выбор редактора ###
207 Вы указали своё имя, и теперь можно выбрать редактор, который будет использоваться, когда нужно ввести сообщение в Git. По умолчанию Git использует стандартный редактор вашей системы, обычно это Vi или Vim. Если вы хотите использовать другой текстовый редактор, например Emacs, можно сделать следующее:
209 $ git config --global core.editor emacs
211 ### Утилита сравнения ###
213 Другая полезная настройка, которая может понадобиться ― встроенная утилита сравнения, которая будет использоваться для разрешения конфликтов слияния. Например, если вы хотите использовать vimdiff:
215 $ git config --global merge.tool vimdiff
217 Git умеет делать слияния при помощи kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge и opendiff, но вы можете настроить и другую утилиту. Подробнее об этом написано в главе 7.
219 ### Проверка настроек ###
221 Если вы хотите проверить используемые настройки, можете использовать команду `git config --list`, чтобы показать все, которые Git найдёт:
223 $ git config --list
224 user.name=Scott Chacon
225 user.email=schacon@gmail.com
226 color.status=auto
227 color.branch=auto
228 color.interactive=auto
229 color.diff=auto
230 ...
232 Некоторые ключи (названия) настроек могут появиться несколько раз, потому что Git читает один и тот же ключ их из разных файлов (например из `/etc/gitconfig` и `~/.gitconfig`). В этом случае Git использует последнее значение для каждого ключа.
234 Также вы можете проверить значение конкретного ключа, выполнив `git config {ключ}`:
236 $ git config user.name
237 Scott Chacon
239 ## Как получить помощь? ##
241 Если вам нужна помощь при использовании Git, есть три способа открыть страницу руководства по любой команде Git:
243 $ git help <команда>
244 $ git <команда> --help
245 $ man git-<команда>
247 Например, так можно открыть руководство по команде config:
249 $ git help config
251 Эти команды хороши тем, что ими можно пользоваться всегда, даже без подключения к сети.
252 Если руководства и этой книги недостаточно, и вам нужна персональная помощь, вы можете попытаться поискать её на каналах `#git` и `#github` сервера Freenode IRC (irc.freenode.net). Обычно там сотни людей, отлично знающих Git, которые могут помочь.
254 ## Резюме ##
256 Теперь у вас должно быть общее понимание, что такое Git, и чем он отличается от ЦСУВ, которыми вы могли пользоваться раньше. Также у вас должна быть установлена рабочая версия Git с вашими личными настройками. Настало время перейти к изучению некоторых основ Git.