Контроль версий

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

«Система контроля версий» перенаправляется сюда. Программный инструмент см. в разделе Система контроля версий .

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

Контроль версий — это компонент управления конфигурацией программного обеспечения .

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

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

Обзор

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

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

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

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

Многие системы контроля версий идентифицируют версию файла как число или букву, называемую номером версии , версией , номером редакции , ревизией или уровнем редакции . Например, первой версией файла может быть версия 1 . При изменении файла следующая версия — 2 . Каждая версия связана с отметкой времени и лицом, внесшим изменения. Версии можно сравнивать, восстанавливать и, для некоторых типов файлов, объединять.

История

См. Также: Сравнение программного обеспечения для контроля версий § История и принятие.

Инструмент обновления программного обеспечения IBM OS/360 IEBUPDTE появился в 1962 году и, возможно, был предшественником инструментов системы контроля версий. Два пакета управления исходным кодом и контроля версий, которые активно использовались при установке IBM 360/370, — это The Librarian и Panvalet .

Полная система контроля исходного кода была запущена в 1972 году — Система контроля исходного кода для той же системы (OS/360). Введение в систему контроля исходного кода, опубликованное 4 декабря 1975 года, исторически подразумевало, что это была первая преднамеренная система контроля версий. RCS последовал сразу за этим, с его сетевой версией Concurrent Versions System . В следующем поколении после системы параллельных версий доминировала Subversion . за которым последовало появление распределенных инструментов контроля версий, таких как Git .

Структура

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

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

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

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

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

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

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

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

Редакции происходят последовательно с течением времени и, таким образом, могут быть упорядочены по номеру ревизии или метке времени. Редакции основаны на прошлых редакциях, хотя можно в значительной степени или полностью заменить более раннюю редакцию, например, «удалить весь существующий текст, вставить новый текст». В простейшем случае, без ветвления или отмены, каждая ревизия основана только на ее непосредственном предшественнике, и они образуют простую строку с одной последней версией, ревизией или наконечником «HEAD» . С точки зрения теории графов , рисование каждой ревизии в виде точки и каждой связи «производной ревизии» в виде стрелки (обычно указывающей от старой к новой, в том же направлении, что и время), это линейный график . Если существует ветвление, поэтому несколько будущих ревизий основаны на прошлой ревизии, или отмена, так что ревизия может зависеть от ревизии, более старой, чем ее непосредственный предшественник, тогда результирующий граф вместо этого представляет собой ориентированное дерево (каждый узел может иметь более одного дочерний элемент) и имеет несколько подсказок, соответствующих версиям без дочерних элементов («последняя версия в каждой ветке»). В принципе, результирующее дерево не обязательно должно иметь предпочтительную вершину («основную» последнюю ревизию) – просто различные разные версии – но на практике одна вершина обычно обозначается как HEAD. Когда новая ревизия основана на HEAD, она либо идентифицируется как новая HEAD, либо считается новой ветвью. Список ревизий от начала до HEAD (в терминах теории графов — уникальный путь в дереве, который, как и раньше, образует линейный граф) — это ствол или основная линия. И наоборот, когда ревизия может быть основана на более чем одной предыдущей ревизии (когда узел может иметь более одного родительского узла ), результирующий процесс называется слиянием и является одним из наиболее сложных аспектов контроля версий. Чаще всего это происходит, когда изменения происходят в нескольких ветвях (чаще всего в двух, но возможно и больше), которые затем объединяются в одну ветвь, включающую оба изменения. Если эти изменения перекрываются, объединить их может быть сложно или невозможно, и потребуется ручное вмешательство или переписывание.

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

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

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

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

В бизнесе и праве

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

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

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

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

Основная статья: Атомная фиксация

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

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

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

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

Объединение версий

Основная статья: Слияние (контроль версий)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лучшие практики

Следование лучшим практикам необходимо для получения всех преимуществ контроля версий. Рекомендации могут различаться в зависимости от инструмента контроля версий и области, к которой применяется контроль версий. Общепринятые передовые методы разработки программного обеспечения включают: внесение дополнительных, небольших изменений; выполнение коммитов , которые включают только одну задачу или исправление — следствием этого является фиксация только кода, который работает и сознательно не нарушает существующую функциональность; использование ветвления для завершения функциональности перед выпуском; написание четких и описательных сообщений о коммитах, пояснение того, почему и насколько ясно в описании коммита или в коде; и использование последовательной стратегии ветвления. Другие лучшие практики разработки программного обеспечения, такие как проверка кода и автоматическое регрессионное тестирование, могут помочь в следовании лучшим практикам контроля версий.

Затраты и выгоды

Затраты и выгоды будут различаться в зависимости от выбранного инструмента контроля версий и области, в которой он применяется. Этот раздел посвящен области разработки программного обеспечения, где широко применяется контроль версий.

Затраты

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

Преимущества

Позволяет отменить изменения

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

Ветвление упрощает развертывание, обслуживание и разработку.

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

Уменьшение ущерба, подотчетность и улучшение процессов и дизайна

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

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

Упрощает отладку

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

Улучшает сотрудничество и общение

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

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

Интеграция

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

Интегрированная среда разработки

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

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

Терминология может варьироваться от системы к системе, но некоторые общепринятые термины включают:

Базовый уровень

Основная статья: Базовый уровень (управление конфигурацией)

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

Обвинять

Поиск автора и ревизии, последней изменившей конкретную строку.

Ветвь

Основная статья: Ветвление (контроль версий)

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

Изменять

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

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

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

Проверить

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

Клонировать

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

Совершить (существительное)

Этот раздел представляет собой отрывок из набора изменений . [ редактировать ]

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

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

Основная статья: Commit (контроль версий)

Коммит ) означает запись или слияние изменений, внесенных в рабочую копию , ( check in , ci или, реже, install , submit или Record обратно в репозиторий. Коммит содержит метаданные, обычно информацию об авторе и сообщение о коммите, описывающее изменение.

Зафиксировать сообщение

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

Конфликт

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

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

Основная статья: Дельта-сжатие

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

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

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

Экспорт

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

Принести

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

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

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

Голова

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

Импорт

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

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

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

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

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

Этикетка

Смотрите тег .

Блокировка

Основная статья: Блокировка файлов

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

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

Аналогично «транку» , но для каждой ветки может быть магистральная линия.

Объединить

Основная статья: Слияние (контроль версий)

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

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

Продвигать

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

Тяни, толкай

Копирование ревизий из одного репозитория в другой. Pull инициируется принимающим репозиторием, а push инициируется источником. Fetch иногда используется как синоним слова pull или для обозначения извлечения, за которым следует обновление .

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

Этот раздел представляет собой отрывок из раздела Распределенный контроль версий § Запросы на включение . [ редактировать ]

Вклад в репозиторий исходного кода, использующий распределенную систему контроля версий, обычно вносится с помощью запроса на включение, также известного как запрос на слияние. Участник запрашивает, чтобы сопровождающий проекта внес изменения в исходный код, отсюда и название «запрос на включение». Мейнтейнер должен объединить запрос на включение, если вклад должен стать частью исходной базы.

Разработчик создает запрос на включение, чтобы уведомить сопровождающих о новом изменении; поток комментариев связан с каждым запросом на включение. Это позволяет целенаправленно обсуждать изменения кода . Отправленные запросы на включение видны всем, у кого есть доступ к репозиторию. Запрос на включение может быть принят или отклонен сопровождающими.

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

Репозиторий

Этот раздел представляет собой отрывок из Репозитория (контроль версий) . [ редактировать ]

В системах контроля версий репозиторий — это структура данных, в которой хранятся метаданные для набора файлов или структуры каталогов . В зависимости от того, является ли используемая система контроля версий распределенной, например Git или Mercurial , или централизованной, например Subversion , CVS или Perforce , весь набор информации в репозитории может дублироваться в системе каждого пользователя или может храниться в одной системе. сервер . Некоторые из метаданных, содержащихся в репозитории, включают, среди прочего, историческую запись изменений в репозитории, набор объектов фиксации и набор ссылок на объекты фиксации, называемые заголовками .

Решать

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

Обратная интеграция

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

Ревизия и версия

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

Делиться

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

Транслировать

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

Ярлык

Основная статья: Тег редакции

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

Ствол

Основная статья: Багажник (программное обеспечение)

— Магистральная линия это уникальная линия разработки, не являющаяся ветвью (иногда называемая базовой линией, основной линией или основной линией). )

Обновлять

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

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

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

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

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

См. также

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

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

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