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

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

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

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

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

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

Обзор [ править ]

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

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

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

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

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

История [ править ]

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

Структура [ править ]

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

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

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

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

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

Структура графа [ править ]

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

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

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

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

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

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

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

Модели управления исходным кодом [ править ]

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

Атомарные операции [ править ]

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

Блокировка файла [ править ]

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

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

Слияние версий [ править ]

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

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

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

Базовые показатели, ярлыки и теги [ править ]

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

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

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

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

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

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

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

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

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

Интеграция [ править ]

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

Общая терминология [ править ]

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

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

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

Ветка

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

Изменять

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

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

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

Проверить

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

Клонировать

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

Commit (имя существительное)

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

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

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

Конфликт

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

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

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

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

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

Экспорт

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

Принести

Смотрите тянуть .

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

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

Глава

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

Импортировать

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

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

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

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

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

Этикетка

См. Тег .

Блокировка

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

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

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

Объединить

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

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

Продвигать

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

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

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

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

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

Репозиторий

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

Разрешить

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

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

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

Редакция

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

доля

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

Поток

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

Тег

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

Сундук

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

Обновлять

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

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

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

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

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

См. Также [ править ]

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

Заметки [ править ]

Ссылки [ править ]

Внешние ссылки [ править ]

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