Профессиональная работа с GIT

# Приступая к работе #

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

## О версионном контроле ##

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

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

### Локальная система управления версиями ###

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

Для преодоления этих проблем программисты довольно давно разработали локальные VCS, которые являлись простыми базами данных и сохраняли изменения в файлах с управлением версиями (смотрите рисунок 1-1).

Рисунок 1-1. Диаграмма локального контроля версий.

Одной из наиболее популярных средств VCS является система rcs, которая и сегодня распространяется со многими компьютерами. Даже популярная операционная система MAC OS X содержит команду rcs после установки вами Developer Tools. Эта утилита в основном используется для поддержания множеств исправлений (то есть различий между файлами) от одного изменения к другому в специальном формате на диске; затем можно воссоздать любой файл для любого момента времени суммированием всех исправлений.

### Централизованные системы контроля версий ###

Следующий важный момент, с которым сталкиваются люди, является необходимость сотрудничать с разработчиками, работающими на других системах. Для решения этой проблемы были разработаны централизованные системы контроля версий (CVCS). Эти системы, такие как CVS, Subversion и Perforce, имеют один сервер, содержащий все версии файлов, и несколько клиентов, извлекающих файлы из центрального места. На протяжении многих лет это был стандарт для контроля версий (смотрите рисунок 1-2).

Рисунок 1-2. Диаграмма централизованного контроля версий.

Такая установка имеет много преимуществ, особенно над локальными VCS. Например, каждый в определенной степени знает что делает в проекте любой другой. Администраторы имеют полный контроль над тем, кто и что может делать, и гораздо легче администрировать CVCS чем локальными базами данных для каждого клиента.

Однако эта установка также имеет ряд серьезных недостатков. Наиболее очевидной является единая точка отказа, которой является централизованный сервер. Если сервер недоступен в течении часа, то в течении этого часа невозможно сотрудничать друг с другом или сохранить никаких изменений версий, для чего они работает. Если жесткий диск центральной базы данных будет поврежден и надлежащей резервной копии не было сделано, то вы теряете абсолютно все - вся история проекта, кроме одиночных снимков, оставшихся по счастливой случайности оказались на локальных машинах. Локальные VCS страдают от той-же проблемы когда у вас вся история проекта в одном месте, вы рискуете потерять все.

### Распределенные системы контроля версий ###

Пора перейти к распределенным системам контроля версий. В DVCS (таких как Git, Mercurial, Bazzar или Darcs) клиенты не просто переписывают последний снимок файлов: у них полное зеркало репозитория. Таким образом, если сервер умирает и эти системы сотрудничают через него, любой из клиентских репозиториев может быть скопирован на сервер для его восстановления. Любое извлечение (checkout) в действительности является полной резервной копией всех данных (смотрите рисунок 1-3).

Рисунок 1-3. Диаграмма распределенного контроля версий.

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

### Краткая история Git ###

Как и многие великие вещи в жизни, Git начался с небольшого творческого разрушения и горячих споров. Ядро Linux - это открытый проект достаточно большого объема. На протяжении большей части жизни ядра Linux (1991-2002) изменения передавались как изменения и архивированные файлы. Начиная с 1002 года проект ядра Linux начал использовать проприетарную систему DVCS BitKeeper.

В 2005 году взаимоотношения между сообществом разработчиков ядра Linux коммерческой компанией-разработчиком BitKeeper разорвались и статус утилиты свободная для использования (free-of-charge) был удален. Это побудило сообщество разработчиков Linux (и в частности Торвальда Линукса, создателя Linux) разработать свою собственную утилиту, основываясь на некоторых уроках, полученных при использовании BitKeeper. Некоторые из целей новой системы были следующими:

* Скорость

* Простота архитектуры (design)

* Мощная поддержка нелинейной разработки (тысячи параллельных ветвей)

* Полностью распределенная

* Способная обрабатывать большие проекты, такие как ядро Linux (скорость и размер данных)

С момента своего рождения в 2005 году, Git развилась и созрела для легкого использования и одновременно сохранила эти первоначальные качества. Она необычайно быстрая, очень эффективная для больших проектов, имеет невероятно разветвленную систему для нелинейной разработки (смотрите главу 4).

### Основы Git ###

Итак, что такое Git в двух словах? Это секция важна для дальнейшего восприятия, потому что если вы понимаете что такое Git и основы его работы, то эффективное использование Git, вероятно, буден намного проще для вас. При изучении Git попытайтесь очистить свой разум от вещей, которые вы знаете о других VCS, таких как Subversion и Perforce, это поможет вам избежать тонкой путаницы при использовании инструмента. Git сохраняет и представляет информацию сильно иначе, чем другие системы, хотя пользовательский интерфейс сильно похож и понимание этих различий поможет уберечь вас от путаницы при ее использовании.

### Снимки, а не различия ###

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

Рисунок 1-4. Другие системы, как правило, сохраняют данные как изменения в базовой версии каждого файла.

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

Рисунок 1-5. Git сохраняет данные как снимки проекта во времени.

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

### Почти всякая операция является локальной ###

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

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

Это также означает, что существует очень мало того, что вы не можете сделать, если вы в автономном режиме или с выключенным VPN. Если вы на самолете или поезде и хотите сделать небольшую работу, вы можете счастливо фиксировать (commit), пока не получите соединение для выгрузки в сеть. Если вы идете домой и не может добиться работы клиента VPN, вы можете работать. Во многих других систем, делать подобное либо невозможно, либо болезненные. В Perforce, например, вы не сделаете много, когда вы не подключены к серверу, а в Subversion и CVS, вы можете редактировать файлы, но вы не можете фиксировать изменения в базу данных (так как база данных в автономном режиме). Это может показаться небольшим преимуществом, но вы можете быть удивлены какую большую разницы это может дать.

### Целостность Git ###

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

Механизм, который использует Git для контрольных сумм называется хэш SHA-1. Это 40-символьная строка, которая состоит из шестнадцатеричных символов (0-9 и a-f) и рассчитывается на основе содержимого файла или структуры каталога в Git. Хэш SHA-1 выглядит примерно так:

24b9da6552252987aa493b52f8696cd6d3b00373

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

### Git всегда только добавляет данные ###

Когда вы делаете действия в Git, почти все из них только добавляют данные в базу данных Git. Очень трудно заставить систему что-то невыполнимое или стереть данные любым путем. Как и в любой VCS, вы можете потерять или испортить изменения, которые вы еще не фиксировали (commit), но после фиксирования снимка в Git, его очень трудно потерять, особенно если вы регулярно передаете (push) вашу базу данных в другой репозиторий.

Это делает использование Git радостным, потому что мы знаем, мы можем экспериментировать без опасности серьезно повредить вещь. Для более глубокого взгляда на то, как Git хранит свои данные и как вы можете восстановить данные, которые кажется потерянным, см. "Под одеялом" в главе 9.

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

Теперь внимание. Это главное, что нужно помнить о Git, если вы хотите, чтобы остальные части процесса обучения шли гладко. Git имеет три основных состояния, в которых ваши файлы могут находиться: committed (фиксированные), modified (измененные) и staged (запланированные). Committed (фиксированные) означает, что данные надежно хранятся в локальной базе данных. Modified (измененные) означает, что вы изменили файл, но не фиксировали (commit) его в вашу базу данных. Запланированный (staged) означает, что вы отметили измененный файл в его текущей версии для фиксирования (commit) со следующим снимком.

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

Рисунок 1-6. Рабочий каталог, промежуточная области и Git каталог

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

Рабочий каталог содержит один checkout одной из версий проекта. Эти файлы были вытащены из сжатой базы данных каталога Git и помещены на диске для вашего использования или изменения.

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

Основной рабочий поток Git идет как-то вроде этого:

1.Вы изменяете файлы в вашем рабочем каталоге.

2. Вы планируете к фиксации (stage) файлы, добавляя их снимки к вашей планируемой области.

3. Вы выполняете фиксацию, которая принимает файлы из планируемой области сохраняет и постоянный снимок в каталог Git.

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

## Установка Git ##

### Установка из исходных кодов ###