Управление версиями - Version control

эта статья нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью от добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален. Найдите источники: "Управление версиями"  – Новости  · газеты  · книги  · ученый  · JSTOR (Апрель 2011 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

В программная инженерия, управление версиями (также известен как контроль версий, управления источником, или управление исходным кодом) - это класс систем, отвечающих за управление изменениями в компьютерные программы, документы, крупные веб-сайты или другие сборники информации. Контроль версий - это компонент управление конфигурацией программного обеспечения.^[1]

Изменения обычно обозначаются числовым или буквенным кодом, называемым «номером ревизии», «уровнем ревизии» или просто «ревизией». Например, начальный набор файлов - «версия 1». Когда сделано первое изменение, результирующим набором будет «версия 2» и так далее. Каждая ревизия связана с отметка времени и человек, вносящий изменения. Редакции можно сравнивать, восстанавливать и объединять с файлами некоторых типов.

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

Системы контроля версий (VCS) чаще всего запускаются как автономные приложения, но контроль версий также встроен в различные типы программного обеспечения, например текстовые процессоры и электронные таблицы, совместная веб-документы^[2] и в различных системы управления контентом, например, в Википедии история страницы. Контроль версий позволяет вернуть документ к предыдущей редакции, что очень важно для того, чтобы редакторы могли отслеживать правки друг друга, исправлять ошибки и защищаться от вандализма и рассылка спама в вики.

Обзор

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

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

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

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

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

История

IBM OS / 360 IEBUPDTE Инструмент обновления программного обеспечения восходит к 1962 году, возможно, он является предшественником инструментов VCS. Полная система, предназначенная для управления исходным кодом, была запущена в 1972 году. SCCS для той же системы (OS / 360). Введение SCSS, опубликованное 4 декабря 1975 года, исторически подразумевает, что это была первая преднамеренная система.^[3] RCS последовал сразу после,^[4] с сетевой версией CVS. Следующее поколение после CVS было во власти Subversion,^[5] за которым последовал рост распределенный контроль версий (например. мерзавец ).

Структура

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

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

Когда данные, находящиеся под контролем редакции, изменяются после получения их проверка, это, как правило, не сразу отражается в системе контроля версий (в хранилище), но вместо этого должно быть отметился или совершено. Копия вне системы контроля версий называется «рабочей копией». В качестве простого примера, при редактировании компьютерного файла данные, хранящиеся в памяти программой редактирования, являются рабочей копией, которая фиксируется путем сохранения. Конкретно, можно распечатать документ, отредактировать его вручную и только позже вручную ввести изменения в компьютер и сохранить его. Для управления исходным кодом рабочая копия представляет собой копию всех файлов в конкретной ревизии, обычно хранящуюся локально на компьютере разработчика;^{[примечание 1]} в этом случае сохранение файла изменяет только рабочую копию, а регистрация в репозитории - это отдельный шаг.

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

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

Структура графа

Пример графика истории проекта с контролем версий; ствол выделен зеленым, ветви - желтым, а граф не является деревом из-за наличия слияний (красные стрелки).

С точки зрения теория графов, исправления обычно рассматриваются как направление развития ( ствол) с ответвлениями, образующими направленное дерево, визуализируемое как одна или несколько параллельных линий развития («основные линии» ветвей), ответвляющихся от ствола. На самом деле структура более сложная, образуя ориентированный ациклический граф, но для многих целей подходящим приближением является «дерево со слияниями».

Редакции происходят последовательно с течением времени и, таким образом, могут быть упорядочены либо по номеру редакции, либо по отметке времени.^{[заметка 2]} Редакции основаны на прошлых редакциях, хотя можно в значительной степени или полностью заменить более раннюю редакцию, например «удалить весь существующий текст, вставить новый текст». В простейшем случае, без ветвления или отмены, каждая ревизия основана только на своем непосредственном предшественнике, и они образуют простую строку с единственной последней версией, ревизией «HEAD» или Подсказка. В теория графов термины, рисуя каждую ревизию как точку и каждую связь «производная ревизия» как стрелку (обычно указывающую от более старой к новой в том же направлении, что и время), это линейный график. Если есть ветвление, то есть несколько будущих ревизий основаны на прошлой ревизии или отмене, поэтому ревизия может зависеть от ревизии, более ранней, чем ее непосредственный предшественник, тогда результирующий график вместо направленное дерево (каждый узел может иметь более одного потомка) и имеет несколько подсказок, соответствующих ревизиям без потомков («последняя ревизия в каждой ветви»).^{[заметка 3]} В принципе, в результирующем дереве не обязательно должна быть предпочтительная подсказка («основная» последняя ревизия) - просто различные разные ревизии, но на практике одна подсказка обычно обозначается как HEAD. Когда новая ревизия основана на HEAD, она либо идентифицируется как новая HEAD, либо считается новой ветвью.^{[примечание 4]} Список ревизий от начала до HEAD (в терминах теории графов, уникальный путь в дереве, который, как и раньше, образует линейный граф) - это ствол или магистраль.^{[примечание 5]} И наоборот, когда ревизия может быть основана на более чем одной предыдущей ревизии (когда узел может иметь более одной родитель) получившийся процесс называется слияние, и является одним из самых сложных аспектов контроля версий. Чаще всего это происходит, когда изменения происходят в нескольких ветвях (чаще всего в двух, но возможно и больше), которые затем объединяются в одну ветвь, включающую оба изменения. Если эти изменения накладываются друг на друга, объединение может оказаться трудным или невозможным и потребует ручного вмешательства или перезаписи.

При наличии слияний результирующий граф больше не является деревом, поскольку узлы могут иметь несколько родителей, а вместо этого является корневым ориентированный ациклический граф (DAG). График ациклический, так как родители всегда отстают во времени, и укоренен, потому что существует самая старая версия. Однако, предполагая, что существует ствол, слияния из ветвей можно рассматривать как «внешние» по отношению к дереву - изменения в ветке упаковываются как патч который применяется к HEAD (ствола), создавая новую ревизию без какой-либо явной ссылки на ветвь и сохраняя древовидную структуру. Таким образом, хотя фактические отношения между версиями образуют DAG, это можно рассматривать как дерево плюс слияния, а сам ствол - это линия.

В распределенном управлении версиями при наличии нескольких репозиториев они могут быть основаны на одной исходной версии (корне дерева), но не обязательно должен быть исходный корень и, следовательно, только отдельный корень (самая старая ревизия) для каждого репозитория , например, если два человека начинают работать над проектом отдельно. Точно так же при наличии нескольких наборов данных (нескольких проектов), которые обмениваются данными или сливаются, не существует единого корня, хотя для простоты можно думать, что один проект является основным, а другой - второстепенным, объединенным в первый с или без собственная история изменений.

Специализированные стратегии

Контроль инженерных версий, разработанный на основе формализованных процессов, основанных на отслеживании изменений ранних чертежей или синие линии^{[нужна цитата ]}. Эта система контроля неявно позволяла вернуться к более раннему состоянию проекта, когда разработка проекта заходила в инженерный тупик. Для отслеживания внесенных изменений использовалась таблица изменений. Кроме того, измененные области чертежа были выделены с помощью пометочных облаков.

Контроль версий широко распространен в бизнесе и юриспруденции. Действительно, «красная линия контракта» и «черная линия закона» - одни из самых ранних форм контроля версий,^[6] и по-прежнему работают в бизнесе и юриспруденции с разной степенью сложности. Наиболее сложные методы начинают использоваться для электронного отслеживания изменений в Файлы САПР (увидеть управление данными о продукте ), вытеснив «ручную» электронную реализацию традиционного контроля версий.^{[нужна цитата ]}

Модели управления источниками

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

Атомарные операции

Операция атомный если система остается в согласованном состоянии, даже если операция прерывается. В совершить операция обычно наиболее критична в этом смысле. Коммиты указывают системе контроля версий сделать группу изменений окончательной и доступной для всех пользователей. Не все системы контроля версий имеют атомарные коммиты; в частности, CVS отсутствует эта функция.^[7]

Блокировка файлов

Самый простой способ предотвращения "одновременный доступ "проблемы связаны с блокировка файлов так что только один разработчик одновременно имеет доступ на запись в центральном «репозитории» копий этих файлов. Как только один разработчик «проверяет» файл, другие могут читать этот файл, но никто другой не может изменять этот файл до тех пор, пока этот разработчик не «проверит» обновленную версию (или не отменит проверку).

Блокировка файлов имеет как достоинства, так и недостатки. Он может обеспечить некоторую защиту от сложных конфликтов слияния, когда пользователь вносит радикальные изменения во многие разделы большого файла (или группы файлов). Однако, если файлы остаются заблокированными в монопольном режиме слишком долго, у других разработчиков может возникнуть соблазн обойти программное обеспечение для контроля версий и изменить файлы локально, что вызовет сложное ручное слияние, когда, наконец, внесены другие изменения. В большой организации файлы могут быть оставлены «извлеченными», заблокированными и забытыми по мере того, как разработчики перемещаются между проектами - эти инструменты могут упростить, а могут и не упростить просмотр того, у кого был извлечен файл.

Слияние версий

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

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

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

Базовые линии, метки и теги

Большинство инструментов контроля версий будут использовать только один из этих похожих терминов (базовая линия, метка, тег) для обозначения действия по идентификации снимка («пометить проект») или записи снимка («попробовать с базовым планом» Икс"). Обычно только один из терминов исходный уровень, метка, или тег используется в документации или обсуждении^{[нужна цитата ]}; их можно считать синонимами.

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

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

Наиболее формальное обсуждение управление конфигурацией использует термин исходный уровень.

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

Распределенные системы контроля версий (DRCS) используют одноранговый подход, в отличие от клиент-сервер подход централизованных систем. Вместо единого центрального репозитория, в котором синхронизируются клиенты, рабочая копия кодовой базы каждого партнера является добросовестный репозиторий.^[8]Распределенный контроль версий выполняет синхронизацию путем обмена патчи (наборы изменений) от однорангового узла к одноранговому. Это приводит к некоторым важным отличиям от централизованной системы:

• По умолчанию каноническая справочная копия базы кода не существует; только рабочие копии.
• Общие операции (такие как фиксации, просмотр истории и возврат изменений) выполняются быстро, поскольку нет необходимости связываться с центральным сервером.^[1]:7

Скорее, общение необходимо только при отправке или получении изменений другим узлам или от них.

• Каждая рабочая копия эффективно функционирует как удаленная резервная копия кодовой базы и ее истории изменений, обеспечивая внутреннюю защиту от потери данных.^[1]:4

Интеграция

Некоторые из более совершенных инструментов контроля версий предлагают множество других возможностей, позволяющих более глубокую интеграцию с другими инструментами и процессами разработки программного обеспечения. Плагины часто доступны для Иды такие как Oracle JDeveloper, IntelliJ IDEA, Затмение и Visual Studio. Delphi, IDE NetBeans, Xcode, и GNU Emacs (через vc.el). Прототипы передовых исследований генерируют соответствующие сообщения фиксации,^[9] но он работает только с проектами с уже большой историей, потому что сообщения о фиксации очень зависят от соглашений и особенностей проекта.^[10]

Общая терминология

Терминология может варьироваться от системы к системе, но некоторые из наиболее часто используемых терминов включают:^[11]

Исходный уровень

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

Ветвь

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

+ Изменить

А изменение (или разница, или дельта ) представляет собой конкретную модификацию документа под контролем версий. Степень детализации модификации, считающейся изменением, варьируется в зависимости от системы управления версиями.

Список изменений

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

Проверять, выписываться

Чтобы проверять, выписываться (или co) заключается в создании локальной рабочей копии из репозитория. Пользователь может указать конкретную версию или получить самую последнюю. Термин «проверка» также может использоваться как существительное для описания рабочей копии. Когда файл был извлечен с общего файлового сервера, другие пользователи не могут его редактировать. Думайте об этом как об отеле, когда вы выезжаете из отеля, у вас больше нет доступа к его удобствам.

Клонировать

Клонирование означает создание репозитория, содержащего версии из другого репозитория. Это эквивалентно От себяing или Тянутьв пустой (недавно инициализированный) репозиторий. Как существительное, два репозитория можно назвать клонs, если они синхронизированы и содержат одинаковые ревизии.

Зафиксировать (имя существительное)

«Фиксация» или «редакция» (SVN) - это модификация, которая применяется к репозиторию.

Совершить (глагол)

Чтобы совершить (регистрироваться, ci или, реже, установить, Разместить или запись) заключается в том, чтобы записать или объединить изменения, сделанные в рабочей копии, обратно в репозиторий. Фиксация содержит метаданные, обычно информацию об авторе и сообщение фиксации, описывающее изменение.

Конфликт

Конфликт возникает, когда разные стороны вносят изменения в один и тот же документ, и система не может согласовать изменения. Пользователь должен разрешить конфликт путем объединения изменений или выбора одного изменения в пользу другого.

Дельта-сжатие

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

Динамический поток

Поток, в котором некоторые или все версии файлов являются зеркалами версий родительского потока.

Экспорт

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

Получить

Увидеть Тянуть.

Прямая интеграция

Процесс объединения изменений, внесенных в основной ствол в ветку разработки (функциональную или командную).

Голова

Также иногда называют Подсказка, это относится к самой последней фиксации либо в стволе, либо в ветви. Ствол и каждая ветвь имеют свою собственную головку, хотя ГОЛОВА иногда вольно используется для обозначения ствола.^[12]

импорт

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

Инициализировать

чтобы создать новый пустой репозиторий.

Перемежающиеся дельты

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

метка

Увидеть тег.

Блокировка

Когда разработчик замки файл, никто другой не сможет обновить этот файл, пока он не будет разблокирован. Блокировка может поддерживаться системой контроля версий или через неформальное общение между разработчиками (также известное как социальная блокировка).

Основная линия

Похожий на ствол, но для каждой ветви может быть основная ветка.

Объединить

А слияние или интеграция - это операция, при которой к файлу или набору файлов применяются два набора изменений. Вот некоторые примеры сценариев:

• Пользователь, работающий с набором файлов, обновления или синхронизирует их рабочая копия с изменениями, внесенными и зарегистрированными в репозитории другими пользователями.^[13]
• Пользователь пытается регистрироваться файлы, которые были обновлены другими с тех пор, как файлы были проверено, а программное обеспечение для контроля версий автоматически объединяет файлы (обычно после того, как пользователю будет предложено продолжить автоматическое объединение, а в некоторых случаях это делается только в том случае, если объединение может быть четко и разумно разрешено).
• А ветвь создается, код в файлах независимо редактируется, а обновленная ветвь позже включается в единую унифицированную ствол.
• Набор файлов разветвленный, проблема, которая существовала до разветвления, исправляется в одной ветке, а затем исправление объединяется в другую ветку. (Этот тип выборочного слияния иногда называют вишня чтобы отличить его от полного слияния в предыдущем случае.)

Продвигать

Акт копирования содержимого файла из менее контролируемого места в более контролируемое. Например, из рабочей области пользователя в репозиторий или из потока в его родительский элемент.^[14]

Потяните Нажмите

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

Репозиторий

В хранилище (или «репо») - это место, где текущие и исторические данные файлов хранятся, часто на сервере. Иногда также называют депо.

Разрешить

Акт вмешательства пользователя для разрешения конфликта между различными изменениями одного и того же документа.

Обратное интегрирование

Процесс объединения различных ответвлений команды в основной ствол системы управления версиями.

Редакция

Также версия: А версия есть любое изменение формы. В SVK ревизия - это состояние на момент времени всего дерева в репозитории.

доля

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

Ручей

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

Тег

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

Ствол

Уникальная линия разработки, не являющаяся ветвью (иногда также называемая базовой, основной или основной)

Обновить

An Обновить (или синхронизировать, но синхронизировать также может означать комбинированный От себя и Тянуть) объединяет изменения, сделанные в репозитории (например, другими людьми), с локальным рабочая копия. Обновить также термин, используемый некоторыми инструментами CM (CM +, PLS, SMS) для концепции пакета изменений (см. список изменений). Синоним проверять, выписываться в системах контроля версий, которые требуют, чтобы у каждого репозитория была ровно одна рабочая копия (обычно в распределенных системах)

Разблокировка

снятие блокировки.

Рабочая копия

В рабочая копия - это локальная копия файлов из репозитория в определенное время или в определенную версию. Вся работа, выполняемая с файлами в репозитории, изначально выполняется на рабочей копии, отсюда и название. Концептуально это песочница.

Запрос на вытягивание

Разработчик, просящий других объединить свои «продвинутые» изменения.

Смотрите также

• Смени управление
• Журнал изменений
• Сравнение программного обеспечения для контроля версий
• Сравнение возможностей размещения исходного кода
• Распределенный контроль версий
• Список программного обеспечения для контроля версий
• Система нелинейного монтажа
• Управление конфигурацией программного обеспечения
• Версии программного обеспечения
• Управление версиями файловой системы

Заметки

использованная литература

внешние ссылки

• «Визуальное руководство по контролю версий», Лучше объяснил.
• Раковина, Эрик, "Source Control", СКМ (как). Основы контроля версий.