Pro Git - professional version control

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

Если вы сделаете некоторые изменения и зафиксируете их, следующий коммит сохранит указатель на коммит, который шёл непосредственно перед ним. После еще двух коммитов ваша история может выглядеть, как показано на Рисунке 3-2.

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

Что происходит, когда вы создаёте новую ветку? Итак, этим вы создаёте новый указатель, который вы можете перемещать. Скажем, вы создаёте новую ветку под названием testing. Это делается командой git branch:

$ git branch testing

Эта команда создает новый указатель на тот самый коммит, на котором вы сейчас находитесь (см. Рисунок 3-4).

Откуда Git узнает, на какой ветке вы находитесь в данный момент? Он хранит специальный указатель, который называется HEAD (верхушка). Учтите, что это сильно отличается от концепции HEAD в других СУВ, таких как Subversion или CVS, к которым вы, возможно, привыкли. В Git это указатель на локальную ветку, на которой вы находитесь. В данном случае вы всё ещё на ветке master. Команда git branch только создала новую ветку, она не переключила вас на неё (см. Рисунок 3-5).

Чтобы перейти на существующую ветку, вам надо выполнить команду git checkout. Давайте перейдем на новую ветку testing:

$ git checkout testing

Это действие перемещает HEAD так, чтобы тот указывал на ветку testing (см. Рисунок 3-6).

В чём важность этого действия? Давайте сделаем ещё один коммит:

$ vim test.rb $ git commit -a -m 'made a change'

На Рисунке 3-7 показан результат.

Это интересно, потому что теперь ваша ветка testing передвинулась вперёд, но ваша ветка master всё ещё указывает на коммит, на котором вы были, когда выполняли git checkout, чтобы переключить ветки. Давайте перейдём обратно на ветку master:

$ git checkout master

На Рисунке 3-8 можно увидеть результат.

Эта команда выполнила два действия. Она передвинула указатель HEAD назад на ветку master и вернула файлы в вашем рабочем каталоге назад, в соответствие со снимком состояния, на который указывает master. Это также означает, что изменения, которые вы делаете, начиная с этого момента, будут ответвляться от старой версии проекта. Это полностью откатывает изменения, которые вы временно делали на ветке testing. Таким образом, дальше вы можете двигаться в другом направлении.

Давайте снова сделаем немного изменений и зафиксируем их:

$ vim test.rb $ git commit -a -m 'made other changes'

Теперь история вашего проекта разветвилась (см. Рисунок 3-9). Вы создали новую ветку, перешли на неё, поработали на ней немного, переключились обратно на основную ветку и выполнили другую работу. Оба эти изменения изолированы на отдельных ветках: вы можете переключаться туда и обратно между ветками и слить их, когда будете готовы. И вы сделали всё это простыми командами branch и checkout.

Из-за того, что ветка в Git на самом деле является простым файлом, который содержит 40 символов контрольной суммы SHA-1 коммита, на который он указывает, создание и удаление веток практически беззатратно. Создание новой ветки настолько же быстро и просто, как запись 41 байта в файл (40 символов + символ перехода на новую строку).

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

Давайте поймём, почему вам стоит так делать.

Основы ветвления и слияния

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

Работать над веб-сайтом.

Создадите ветку для новой задачи, над которой вы работаете.

Выполните некоторую работу на этой ветке.

На этом этапе вы получите звонок о том, что сейчас критична другая проблема, и её надо срочно решить. Вы сделаете следующее:

Вернётесь на производственную ветку.

Создадите ветку для исправления ошибки.

После тестирования ветки с исправлением сольёте её обратно и отправите в продакшн.

Вернётесь к своей исходной задаче и продолжите работать над ней.