Система управления версиями Git. Система управления версиями git и российский сервис хранения исходного кода gitflic
 Скачать 3.56 Mb.
|
|
система управления версиями. Систему управления версиями можно сравнить с сохранением состо- яния компьютерной игры. Перед прохождением особенно сложного игро- вого эпизода игрок сохраняет текущее состояние, чтобы, в случае неудачи, была возможность вернуться, а не проходить игру заново. Или игрок хочет 11 попробовать несколько вариантов прохождения. Он сохраняет текущее со- стояние и многократно возвращается к нему, пробуя новые стратегии про- хождения. Таким образом, Система управления версиями – это инструмент, позволяющий доку- ментировать ход разработки, выполняемой коллективом программи- стов, и быстро переходить от одной версии кода к другой. 1.2. Краткая история развития систем управления версиями История систем управления версиями (VCS) насчитывает три поколе- ния. На рисунке 1.2 представлена хронология их создания. Рисунок 1.2 – Хронология создания систем управления версиями VCS первого поколения предназначались для отслеживания измене- ний в одном, изолированном файле. Редактировать этот файл в каждый момент времени мог только один человек. VCS первого поколения, в основ- ном, предназначались для использования одним программистом на одном, изолированном компьютере. В очень редких случаях организовывался сете- вой доступ к одному компьютеру, и все участники проекта должны были I поколение 1972 ScSS, разработана Mark Rochkind I поколение 1982 RCS, разработана Walter Tichy II поколение 1986 CVS, разработана Dick Grune II поколение 2000 Bitkeeper от Bitmover Inc, SVN от Colabnet Inc III поколение 2005 Mercurial автор Matt Mackall, Git автор Linus Torvalds 12 заходить на этот компьютер и редактировать отдельные файлы. В каждый момент времени доступ к VCS имел только один участник проекта. Коллективный доступ к файлам появился в VCS второго поколения. Стала доступна коллективная работа. Несколько человек одновременно могли редактировать файлы и сохранять изменения в одном централизован- ном хранилище (репозитории). В репозитории в каждый момент времени хранилась «официальная» версия проекта. При работе с репозиторием к нему требовался постоянный сетевой доступ. Фактически репозиторий представлял собой сетевую папку, с которой одновременно работали не- сколько человек. VSC третьего поколения реализованы как распределённые храни- лища. Централизованного репозитория нет. Все VCS на компьютерах всех разработчиков считаются равноправными. Каждый из разработчиков рабо- тает автономно. По согласованию между разработчиками одно из хранилищ считается местом хранения текущей «официальной» версии проекта. Разра- ботчики синхронизируют свои VSC с «официальной» версией по мере накопления готовых частей кода. 1.3. Системы управления версиями первого поколения Первой системой управления версиями, получившей широкое распро- странение, была SCCS (Source Code Control System) (J. Schilling, 2020). SCCS была разработана сотрудником Bell Labs Марком Рочкиндом в 1972 году и предназначалась для отслеживания версий одного, изолированного файла. Базовые идеи, заложенные в SCCS, сохраняются и в современных системах управления версиями (Oracle Corporation, 2010). В момент добавления в SCCS нового файла, за версиями которого необходимо следить, в системе создаётся контейнер, называемый файлом истории. Имя этого контейнера состоит из имени исходного файла, к кото- рому добавлен префикс s. Например, для файла с именем file1.txt имя контейнера будет s.file1.txt. Контейнер хранится в директории с именем SCCS, являющейся поддиректорией директории, в которой хранится исход- ный файл. В момент создания файл истории содержит копию исходного 13 файла и служебную информацию, предназначенную для отслеживания вер- сий. Одной из составляющих служебной информации является контрольная сумма, предназначенная для проверки целостности файла истории. Файл ис- тории не кодируется и не сжимается, он хранится «как есть», и существенно увеличивается в размере по мере сохранения истории изменений. При попытке сохранить новую версию исходного файла в файл исто- рии добавляется только фрагмент, содержащий различия между версиями. Такой фрагмент называется дельтой. Идея хранения дельт останется осно- вополагающей для всех последующих поколений систем управления верси- ями. Такой способ хранения позволяет существенно уменьшить размер файла истории, даже не прибегая к сжатию. Каждая дельта хранится в спе- циальной структуре, называемой дельта-таблицей. В дельта-таблице сохра- няется текст, который добавляется или удаляется из исходного файла. К этому тексту добавляются управляющие последовательности, маркирую- щие начало и конец очередной дельты. Добавление каждой новой дельты (описывающей добавление или уда- ление фрагмента текста) приводит к увеличению номера версии файла ис- тории. Любую из версий можно извлечь в рабочую директорию для про- смотра, редактирования или компиляции. В SCCS используется метод хра- нения под названием «чередующиеся дельты», который гарантирует, что время извлечения более ранних версий не будет отличаться от времени из- влечения более поздних версий. SCCS позволяет хранить историю версий для одного файла, в то время как программный проект состоит из нескольких файлов. При стандартном использовании SCCS версии файлов, входящих в один проект, будут отли- чаться. Чтобы синхронизировать номера версий в рамках одного проекта, используют следующее ухищрение. В те файлы, которые не редактирова- лись, добавляют пустое изменение, вызывающее изменение номера версии и добавление пустой дельты. Надо заметить, если проект содержит много файлов, подобная синхронизация номеров их версий является очень трудо- ёмкой. Когда один из программистов извлекает из файла истории версию для редактирования, сам файл истории блокируется и становится недоступным для других программистов. Это позволяет избежать перезаписи чужих пра- вок, но существенно замедляет коллективную работу над проектом, так как 14 с одним файлом в один момент времени может работать только один про- граммист. В SCCS была реализована идея веток, ставшая в дальнейшем класси- ческой. Под ветками подразумеваются отдельные файлы истории, хранящие различные части решения одной задачи. После завершения работы над всеми частями файлы историй соединяются, образуя общий файл истории решения всей задачи. Для понимания того, какие действия позволяет выполнить SCCS, рас- смотрим некоторые команды этой системы управления версиями. − sccs create – добавляет новый файл в рабочий каталог и создаёт для него файл истории в каталоге /SCCS; − sccs get – извлекает последнюю версию рабочего файла из файла истории и помещает её в рабочий каталог для чтения (редактирование за- прещено); − sccs edit – извлекает последнюю версию рабочего файла из файла истории и помещает её в рабочий каталог для редактирования. Файл исто- рии будет заблокирован и недоступен для других пользователей; − sccs delta – изменения, сделанные в рабочем файле, будут добав- лены в файл истории, который будет разблокирован; − sccs prt – показать цепочку изменений, хранящуюся в файле истории; − sccs diffs – показать различия между текущим рабочим файлом и соответствующим ему заблокированным файлом истории. Перечисленные команды демонстрируют основные этапы работы с файлом истории: создание, просмотр последней версии, редактирование, сравнение с предыдущей версией, просмотр истории изменений, сохране- ние сделанных изменений. Система управления версиями SCCS была коммерческой (платной), и из-за этого её доступность была ограничена. Как обычно случается в таких ситуациях, появилась система управления версиями с открытым кодом. Её создал Уолтер Тихи в 1982 году и назвал Revision Control System (RCS) (Nguyen, 2022). SCCS и RCS во многом похожи, их общие свойства: − сохранение истории только для одного файла; 15 − версии различных файлов, составляющих один проект, могут отли- чаться; − отсутствует многопользовательский режим; − отсутствует поддержка сети. Отличие RCS от SCCS является, скорее, её недостатком, чем усовер- шенствованием, вероятно, выполненным для того, чтобы избежать патент- ных споров с SCCS. Тем не менее, о нём необходимо рассказать, поскольку на RCS базируются системы управления версиями второго поколения. Для сохранения изменений в RCS используется система обратных дельт. При создании первоначального файла истории в него помещается со- держимое исходного файла. Процесс сохранения изменений заключается в следующем. Вычисляется дельта между новой версией и версией, храня- щейся в файле истории. Версия, хранящаяся в файле истории, из него уда- ляется, и вместо неё записывается новая версия и вычисленная дельта. Для получения последней версии файла никаких действий не требуется, так как она всегда хранится в файле истории. Для получения предыдущей версии необходимо из текущей версии вычесть дельту. Чем более раннюю версию требуется получить, тем больше дельт необходимо вычесть. В отличие от SCCS, в RCS доступ к последней версии осуществляется очень быстро, и чем старше версия, к которой необходимо получить доступ, тем больше времени требуется затратить. В SCCS время доступа ко всем версиям одинаковое. Список и содержимое команд RCS похожи на список и содержимое команд SCCS: − si – добавляет новый файл в рабочий каталог и создаёт для него файл истории в каталоге /RCS. Если файл уже имеется в каталоге /RCS, то вычисляет дельту, удаляет старую версию и добавляет новую и соответству- ющую ей дельту; − co – извлекает последнюю версию рабочего файла из файла истории и помещает её в рабочий каталог для чтения (редактирование запрещено); − co-l – извлекает последнюю версию рабочего файла из файла исто- рии и помещает её в рабочий каталог для редактирования. Файл истории будет заблокирован и недоступен для других пользователей; − merge – производит слияние двух отредактированных копий одного исходного файла; 16 − rcsdiff – показывает различия между текущим рабочим файлом и соответствующим ему заблокированным файлом истории. 1.4. Системы управления версиями второго поколения Эффективному использованию систем управления версиями первого поколения мешало отсутствие поддержки многопользовательской удалён- ной работы. В 1986 году Дик Грун разработал систему управления версиями под названием Concurrent Version System (CVS) (GNU, 2015). CVS откры- вает эру систем управления версиями второго поколения, главным отли- чием которых от систем управления версиями первого поколения является поддержка многопользовательского режима работы (поддержка сети). С по- явлением этой системы географически распределённые команды разработ- чиков получили эффективный инструмент коллективной работы. Програм- мисты, находящиеся в разных точках земного шара, теперь могли взаимо- действовать так же эффективно, как при нахождении в одной комнате. CVS представляет собой сетевой интерфейс для системы управления версиями первого поколения RCS. С точки зрения правил формирования файлов истории, в CVS нет никаких отличий от RCS. Отличия заключаются в процедуре доступа к файлам истории, которая реализует модель центра- лизованного репозитория. Под централизованным репозиторием понима- ется сетевое хранилище файлов, доступ к которому осуществляется через локальную или глобальную сеть. Первый шаг по организации работы с CVS заключается в создании на удалённом сервере централизованного репозитория. Для выполнения этой работы используются специальные команды CVS. После того, как репози- торий создан, в него импортируется заготовка проекта, содержащая мини- мальный набор файлов. Вместо заготовки может быть импортирован проект, подлежащий доработке. Работу по созданию репозитория и импорту проекта обычно выполняет руководитель или инициатор проекта. В результате им- порта в репозитории создаются файлы истории для всех файлов проекта. После создания репозитория каждый из участников проекта имеет 17 возможность скачать на свой локальный компьютер файлы истории. В от- личие от RCS, файлы истории в репозитории не блокируются после их ска- чивания, что позволяет работать с проектом неограниченному количеству программистов. Программисты редактируют файлы на своих локальных компьютерах и, по мере необходимости, фиксируют изменения в файлах ис- тории центрального репозитория. Если один из программистов обновил файл истории в репозитории, его коллеги должны обновить соответствую- щий рабочий файл на своих локальных компьютерах. Сделать это необхо- димо перед фиксацией изменений, внесённых в тот же файл, или для того, чтобы использовать (посмотреть) результаты работы коллеги. Процедура обновления рабочих копий, как правило, автоматизирована и не требует ручной работы. Правда, иногда возникают коллизии, которые необходимо устранить в ручном режиме перед фиксацией изменений. История не сохранила сведений о том, когда появился термин «ком- мит», но при описании приёмов работы с системами управления версиями второго поколения он широко используется. Значит, необходимо дать опре- деление этого термина. Коммит – это синоним выражения «зафиксировать изменения в файле ис- тории». Система команд CVS объединяет в себе команды системы RCS и спе- цифические команды, обеспечивающие коллективную работу с централь- ным репозиторием. Вот список этих команд: − export CVSOOT – задаёт корневой каталог репозитория CVS для того, чтобы его не нужно было в дальнейшем указывать в каждой команде; − cvs import – импортировать директории проекта в репозиторий CVS. Перед выполнением команды происходит автоматический переход в корневой каталог проекта; − cvs checkout – копировать файлы проекта на локальный компьютер; − cvs commit – коммит изменённого файла; − cvs add – добавляет новый файл в репозиторий для отслеживания изменений; − cvs update – обновить рабочую версию из репозитория для учёта 18 коммитов, сделанных другими программистами; − cvs ststus – показать общую информацию об извлечённой рабочей версии; − cvs tag – добавить информационный заголовок (тег) в файл или группу файлов; − cvs tag –b – создать новую ветвь в репозитории; − cvs checkout –r – извлечь ветвь из репозитория; − cvs update –j – объединить ветвь из репозитория с локальной рабо- чей копией. Дальнейшим развитием систем управления версиями второго поколе- ния стала система Subversion (C. Michael Pilato, 2008). Как и CVS, она осно- вана на технологии центрального репозитория. В CVS возможна ситуация, когда коммит будет сохранён не полно- стью, например, из-за проблем с сетевым подключением. Частично сохра- нённый коммит будет рассматриваться как полный и при загрузке в рабочие версии создаст массу проблем. Для исключения таких ситуаций в Subversion предусмотрено журналирование. Перед началом записи очередного ком- мита в специальном файле, называемом журналом, делается запись о по- пытке выполнить коммит с подробной информацией о нём. Если операция была выполнена успешно, к этой записи добавляется отметка о завершении сохранения коммита. В случае сбоя отметка о завершении коммита не будет размещена в журнале. После восстановления работоспособности системы проверяется журнал на предмет наличия записей без отметок о завершении. При наличии таких записей повторяются указанные в них коммиты. Важной особенностью Subversion является то, что коммиты могут включать в себя не один файл, а группу файлов или каталогов. Это позво- ляет рассматривать набор связанных изменений как один коммит, что уве- личивает информативность сохранённых изменений. В настоящее время Subversion поддерживается Apache Software Foun- dation и использует файловую систему FSFS (File System atop th File System). В FSFS директории являются полноправными объектами, которые воз- можно включать в коммит. Каждый коммит хранится в отдельном файле. Этим файлам присваиваются имена в виде последовательных числовых 19 идентификаторов. При первом коммите в файле сохраняется полный текст файла, при последующих – только дельты. Кроме того, коммиты сжимаются с помощью алгоритмов lz4 или zlib. Поскольку Subversion является наслед- ницей RCS, в ней используется система обратных дельт. При большом ко- личестве коммитов, относящихся к одному файлу, время восстановления ранних версий значительно увеличивается. Для борьбы с этим неудобством с Subversion используется соглашение о том, что после сохранения 1023 дельт снова сохраняется полная версия исходного файла. Subversion использует не обычную систему ветвления. Шаблон репо- зитория содержит три директории: − trunk; − branches; − tags. Директория используется в следующих целях: − trunk для хранения окончательных версий проекта, готовых для пе- редачи пользователю; − branches для хранения вложенных папок, соответствующих различ- ным ветвям; − tags для хранения обособленных частей проекта. Ниже перечислены основные команды системы Subversion: − svn create – создаёт новый пустой шаблон репозитория; − svn import – импортировать проект в репозиторий (создать файлы истории для всех файлов проекта); − svn checkout – загрузить рабочие версии из репозитория на локаль- ный компьютер; − svn commit –m – создать коммит для набора файлов и директорий; − svn add – добавить в репозиторий новый файл для отслеживания; − svn update – обновить рабочую версию проекта; будут скачаны и добавлены изменения, внесённые другими программистами; − svn status – отобразить список файлов, которые изменились (по- лезна в связке с предыдущей командой); − svn info – общие сведения об извлечённой рабочей копии проекта; − svn copy – создать новую ветку путём копирования существующей; 20 − svn switch – сделать ветку рабочей директорией; − svn merge – объединить ветвь из репозитория с текущей ветвью на ра- бочем компьютере (объединение произойдёт только на рабочем компьютере, для сохранения изменений в файле истории нужно будет сделать коммит); − svn log – показать историю коммитов. 1.5. Системы управления версиями третьего поколения Системы управления версиями второго поколения обеспечили воз- можность коллективной удалённой работы. Географически распределённые команды разработчиков смогли выполнять совместные проекты. Однако, некоторые недостатки, связанные с удалённой работой, всё же остались. Эти недостатки связаны с необходимостью использовать центральный репози- торий, через который происходит обмен коммитами. Если по какой-то при- чине центральный репозиторий недоступен, то коллективная работа над проектом становится невозможной. Проблемы, связанные с недоступностью центрального хранилища, ре- шаются путём его исключения из архитектуры сети. Архитектура, в которой все компьютеры могут общаться друг с другом напрямую, называется рас- пределённой сетью. Было логично ожидать, что появится система управле- ния версиями, основанная на распределённой сети. И она появилась. В 2005 году Линус Торвальдс создал систему управления версиями Git (Scott Chacon, 2014). Будучи создателем операционной системы Linux, Торвальдс разрабатывал Git, прежде всего, для координации работы программистов, принимающих участие в разработке ядра Linux. Со временем Git стали ис- пользовать и программисты, не связанные с работой над Linux. Сфера при- менения Git расширилась, и в настоящее время это наиболее популярная си- стема управления версиями. Как было сказано, Git является распределённой системой, централь- ного репозитория нет, и программисты могут обмениваться версиями раз- рабатываемых программ напрямую. По правде говоря, централизованное хранилище в Git обычно присутствует, но его функция отличается от функ- 21 ции центрального репозитория в системах управления версиями второго по- коления. В Git централизованное хранилище используется, в основном, для хранения окончательных версий продукта в целом или его подсистем. Даже если централизованное хранилище используется для обмена версиями в процессе работы, оно рассматривается как участник рабочей группы. Ключевой особенностью систем управления версиями третьего поко- ления и Git в частности является то, что на локальном компьютере хранятся не только рабочие файлы, но и файлы истории. В результате коммиты можно выполнять локально, даже без доступа к сети. Работая с Git, програм- мист выполняет коммиты на локальном компьютере до тех пор, пока не бу- дет готов поделиться результатами своей работы со всеми членами группы разработчиков или с некоторыми её участниками, работающими над одной и той же подсистемой. Как будет производиться обмен, через центральный репозиторий или непосредственно между компьютерами членов группы, ре- шают сами программисты, участвующие в обмене. Дельты в Git используются только для пересылки файлов в удалённые репозитории. Для создания коммитов дельты не используются, и это делает Git очень быстрым, так как в коммитах хранятся полные версии файлов, и нет необходимости тратить время на восстановление версии, применяя одну дельту за другой. Когда файл добавляется для отслеживания в Git, он сжи- мается с использованием алгоритма zlib, и результат хэшируется с помощью хэш-функции SHA-1. Полученный уникальный хэш однозначно соответ- ствует содержимому файла. Все файлы хранятся в папке git/objects. Сово- купность хранимых файлов называется базой объектов. Именами файлов в базе объектов являются полученные хэши. Сами сжатые файлы называются блобами. Блобы создаются каждый раз, когда новый файл добавляется в Git для отслеживания или когда сохраняется изменённая версия существую- щего файла. При подготовке коммита Git создаёт промежуточный индексный файл (staging index). По мере добавления изменений в коммит ссылки на блобы, соответствующие этим изменениям, добавляются в индексный файл. Содер- жимое индексного файла представляет собой структуру, описывающую де- рево. Дерево является ещё одним объектом Git наряду с блобами. В узлах дерева хранится информация о реальном имени файла, правах доступа к 22 файлу, имени его автора и ссылки на предыдущие и следующие версии файла. Также узел дерева может хранить ссылку на другое дерево, реализуя инструмент ветвей. Когда все данные с историей изменений подготовлены, да- ётся команда на создание коммита. Коммит является третьим объектом Git (пер- вые два – блоб и дерево). Коммит хранится в базе коммитов и содержит дату создания, комментарий, имя автора, адрес его электронной почты и ссылку на объект дерево. Каждый коммит, кроме того, содержит ссылку на родительский коммит, в результате чего создаётся история изменений проекта. В целях экономии места все объекты Git (блобы, деревья и коммиты) сжимаются, дельты не используются. Они называются свободными объек- тами (loose objects). Однако есть исключение. Передача коммитов в удалён- ный репозиторий, хранение очень больших наборов объектов или выполне- ние команды сборки мусора вызывают переупаковку объектов и создание пакетных файлов. Пакетные файлы сжимаются и имеют расширение pack. Для каждого пакетного файла создаётся индексный файл с расширением idx. Индексный файл содержит ссылки на упакованные объекты и их располо- жение в пакетном файле. При выполнении обмена коммитами по сети передаются пакетные файлы. После получения пакетного файла адресатом он распаковывается, и в дальнейшем для работы используются свободные объекты. Набор команд Git более обширный и разнообразный, чем у систем первого и второго поколений. Ниже приведены некоторые из них: − git init – текущая папка на локальном компьютере инициализиру- ется как репозиторий Git, в ней создаётся скрытый каталог git; − git clone – на локальный компьютер загружается репозиторий, нахо- дящийся по адресу, указанному в команде. Существенное отличие от систем управления версиями предыдущих поколений заключается в том, что загру- жаются файлы истории, без преобразования в рабочие файлы; − git add – создаёт для нового файла блоб и добавляет информацию о нём в дерево готовящегося коммита; − git commit – создать коммит и поместить его в базу коммитов; − git status – показать статус файлов в рабочем каталоге (добавленные в коммит, изменённые, не отслеживаемые и т.п.); − git branch – создаёт новую ветвь; 23 − git checkout – извлечь ветвь в рабочий каталог; − git merge – объединить ветвь с ранее извлечённой в рабочий каталог; − git pull – получить из удалённого репозитория обновления, отсут- ствующие в рабочем каталоге; − git push – объединить файлы коммитов для текущей ветви в пакет- ный файл и передать пакетный файл в удалённый репозиторий; − git log – показать историю коммитов для активной ветви; − git stash – сохранить все незафиксированные изменения в кэш, чтобы извлечь их позже. В 2005 году появилась ещё одна система управления версиями треть- его поколения под названием Mercurial. Она была создана Мэттом Маккол- лом и, как и Git, предназначалась для управления версиями ядра Linux. В конкурентной борьбе между Mercurial и Git победил Git. В настоящее время Mercurial является второй по распространённости системой управления вер- сиями, хотя и используется гораздо реже по сравнению с Git. Mercurial, как и Git, является распределённой системой управления вер- сиями. Она позволяет большому количеству программистов работать с ло- кальной версией репозитория, сохраняя изменения по мере необходимости. В Mercurial тоже используются сжатие и хэширование, но архитектура си- стемы коренным образом отличается от Git. Идеологически Mercurial ближе к CVS и Subversion. Когда новый файл добавляется для отслеживания, в специальном скрытом каталоге hg/store/data создаётся соответствующий ему файл revlog (журнал изменений). Этот файл можно рассматривать как модификацию файла истории системы CVS. Если Git создаёт блоб для каждой модифика- ции файла, Mercurial создаёт новую запись в журнале истории. Для эконо- мии места каждая новая запись содержит только дельту. Когда число дельт до- стигает порогового значения, новая версия файла сохраняется целиком. Это позволяет уменьшить время извлечения рабочего файла для ранних версий. Пока всё очень похоже на то, как устроены более ранние системы управления версиями. Но есть и отличия. Имя каждого revlog совпадает с именем файла, история изменений которого в нём отслеживается. Для боль- шинства файлов создаются два файла revlog с одинаковыми именами, но с 24 разными расширениями. У одного из них расширение i, у другого d. Расши- рение d имеет revlog, содержащий дельты, а расширение i имеет индексный файл, используемый для быстрого отслеживания версий внутри файла с ин- дексом d. Для небольших файлов, содержащих малое количество дельт, дельты хранятся внутри файла с индексом i, файл с индексом d при этом не создаётся. Записи revlog сжимаются и хэшируются. Хэши являются иденти- фикаторами дельт и называются nodeid. При каждом коммите Mercurial создаёт файл манифеста, который тоже носит название revlog, но это revlog другого типа. Манифест содержит список файлов, включённых в коммит, и список nodeid, указывающих на изменения, фиксирующиеся в данном коммите. Все записи манифеста сжимаются и хэши- руются. Хэши, идентифицирующие записи манифеста, тоже называются nodeid. Третий тип revlog, который использует Mercurial, называется changelog (журнал изменений). В журнале изменений для каждого коммита содержатся следующие данные: − nodeid манифеста, который содержит информацию обо всех вер- сиях файлов, доступных на момент включения записи в журнал изменений; − один или два nodeid родительских коммитов. Если коммит не явля- ется коммитом слияния двух ветвей, то сохраняется один nodeid родителя. В противном случае у коммита два родителя, и поэтому сохраняются два no- deid. Такая структура позволяет отслеживать изменение проекта во времени; − имя автора коммита; − дата коммита; − комментарий к коммиту. Каждая запись журнала изменений тоже хэшируется, и хэш называ- ется nodeid журнала изменений. По смыслу команды Mercurial, приведённые ниже, во многом похожи на команды Git: − hg init – инициализировать текущую папку как репозиторий Mercu- rial (создать скрытый каталог hg и его структуру); − hg clone – загрузить копию сетевого репозитория Mercurial на ло- кальный компьютер; − hg add – добавить новый файл для отслеживания изменений (созда- ются соответствующие revlog с индексами i и d); 25 − hg commit – зафиксировать изменения, создать манифест и запись в журнале истории; − hg status – показать информацию о состоянии файлов текущего ка- талога (изменённые файлы, не отслеживаемые файлы и т.д.); − hg update – извлечь указанную ветвь в рабочий каталог; − hg merge – объединить указанную ветвь с ветвью, находящейся в рабочем каталоге; − hg pull – скачать новые версии из удалённого репозитория, но не распаковывать их в рабочую директорию; − hg push – перенести новые версии из локального каталога в удалён- ный репозиторий; − hg log – показать историю коммитов и соответствующих им ком- ментариев для текущей ветви. |