Предыдущий ролик Следующий ролик  

Видео урок: Архитектура "трех деревьев"

Git: обучение основам

В этой главе мы изучим некоторые ключевые концепции Git, которые помогут вам лучше понять, как он работает, и первой из них является архитектура трех деревьев (three tree architecture), которую он использует. Давайте рассмотрим типичную архитектуру двух деревьев (two-tree architecture). Именно ее используют большинство систем контроля версий. У нас есть репозиторий и рабочая копия, и это наши два дерева. Теперь, мы называем их деревьями, поскольку они представляют файловую структуру. Все верно, наша рабочая копия начинается вверху директории нашего проекта, а внизу может быть четыре или пять различных папок, в которых находятся несколько файлов, может быть и больше папок, в каждой из папок тоже несколько папок, и вы можете представить себе, что если графически изобразить все эти папки, они будут похожи на ветви дерева.

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

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

Итак, еще раз, в дереве репозитория и в дереве рабочей копии не будет содержаться абсолютно одинаковая информация. В общем, это типичная архитектура двух деревьев. Git же использует архитектуру трех деревьев. В нем все еще есть репозиторий и рабочие копии, но есть еще одно дерево, и им является буфер (или же буферная зона). Помните, как мы делали первый коммит в последней главе, сначала ведь мы не сделали коммит (commit), мы сначала написали add. Мы добавили, а затем закоммитили, это был процесс в два этапа. Эта команда add добавила наши файлы в буфер, а уже оттуда мы сделали коммит в репозиторий.

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

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

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