stringtranslate.com

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

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

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

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

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

Обзор

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

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

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

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

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

История

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

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

Структура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Операция является атомарной , если система остается в согласованном состоянии, даже если операция прерывается. Операция фиксации обычно является наиболее критической в ​​этом смысле. Фиксации сообщают системе контроля версий о необходимости сделать группу изменений окончательной и доступной всем пользователям. Не все системы контроля версий имеют атомарные фиксации; в Concurrent Versions System эта функция отсутствует. [11]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расходы

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

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

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

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

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

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

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

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

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

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

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

Улучшает сотрудничество и коммуникацию

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

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

Интеграция

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

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

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

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

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

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

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

Обвинять

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

Ветвь

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

Изменять

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

Изменить список

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

Проверить

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

Клон

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

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

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

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

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

Сообщение фиксации

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

Конфликт

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

Дельта-компрессия

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

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

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

Экспорт

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

Принести

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

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

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

Голова

Также иногда называется tip , это относится к самому последнему коммиту, либо к стволу, либо к ветке. Ствол и каждая ветка имеют свою собственную голову, хотя HEAD иногда свободно используется для обозначения ствола. [29]

Импорт

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

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

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

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

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

Этикетка

См . тег .

Блокировка

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

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

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

Слияние

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

Продвигать

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

Тянуть, толкать

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

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

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

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

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

Репозиторий

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

Решать

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

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

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

Пересмотр и версия

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

Делиться

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

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

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

Ярлык

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

Ствол

Ствол — уникальная линия разработки, которая не является ветвью (иногда ее также называют базовой линией, главной линией или мастером [ 38] [39] )

Обновлять

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

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

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

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

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

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

Примечания

  1. ^ В этом случае буферы редактирования являются вторичной формой рабочей копии и не называются таковыми.
  2. ^ В принципе, две ревизии могут иметь одинаковую временную метку, и поэтому не могут быть упорядочены на одной строке. Это обычно касается отдельных репозиториев, хотя также возможно для одновременных изменений в нескольких ветвях в одном репозитории. В этих случаях ревизии можно рассматривать как набор отдельных строк, по одной на репозиторий или ветвь (или ветвь в пределах репозитория).
  3. ^ «Дерево» ревизий или репозитория не следует путать с деревом каталогов файлов в рабочей копии.
  4. ^ Если новая ветвь основана на HEAD, то топологически HEAD больше не является вершиной, поскольку у него есть дочерняя ветвь.
  5. ^ «Основная линия» может также относиться к основному пути в отдельной ветви.

Ссылки

  1. ^ abc О'Салливан, Брайан (2009). Mercurial: The Definitive Guide. Севастополь: O'Reilly Media, Inc. ISBN 978-0-596-55547-4. Архивировано из оригинала 8 декабря 2019 . Получено 4 сентября 2015 .
  2. ^ " Google Docs ", Посмотрите, что изменилось в файле, Google Inc., заархивировано из оригинала 2022-10-06 , извлечено 2021-04-21.
  3. ^ Скотт, Чакон; Страуб, Бен (2014). Pro Git Второе издание. США: Apress . стр. 14. Архивировано из оригинала 25.12.2015 . Получено 19.02.2022 .
  4. Goetz, Martin (3 мая 2002 г.). «Интервью с Мартином Гетцем» (Интервью). Интервью взято Джеффри Р. Йостом. Вашингтон, округ Колумбия: Институт Чарльза Бэббиджа, Университет Миннесоты. стр. 5–7. Архивировано из оригинала 26 сентября 2024 г. . Получено 17 августа 2023 г. .
  5. Пискипо, Джозеф (3 мая 2002 г.). «Интервью с Джозефом Пископо» (Интервью). Интервью взял Томас Хейг. Вашингтон, округ Колумбия: Институт Чарльза Бэббиджа, Университет Миннесоты. стр. 3, 5, 12–13. Архивировано из оригинала 26 сентября 2024 г. Получено 17 августа 2023 г.
  6. ^ Rochkind, Marc J. (1975). «Система управления исходным кодом» (PDF) . IEEE Transactions on Software Engineering . SE-1 (4): 364–370. doi :10.1109/TSE.1975.6312866. S2CID  10006076.
  7. ^ Tichy, Walter F. (1985). "Rcs — система управления версиями". Software: Practice and Experience . 15 (7): 637–654. doi :10.1002/spe.4380150703. ISSN  0038-0644. S2CID  2605086. Архивировано из оригинала 26.09.2024 . Получено 28.12.2023 .
  8. ^ Коллинз-Сассман, Бен; Фицпатрик, Б.В.; Пилато, CM (2004), Управление версиями с помощью Subversion , O'Reilly, ISBN 0-596-00448-6
  9. ^ Loeliger, Jon; McCullough, Matthew (2012). Контроль версий с Git: мощные инструменты и методы для совместной разработки программного обеспечения. O'Reilly Media. стр. 2–5. ISBN 978-1-4493-4504-4. Архивировано из оригинала 2024-09-26 . Получено 2023-03-22 .
  10. ^ Для инженерных чертежей см. Whiteprint#Document control , для некоторых ручных систем, существовавших в двадцатом веке, например, Engineering Procedures of Hughes Aircraft , каждая редакция которых требовала одобрения Лоуренса А. Хайленда ; см. также процедуры одобрения, установленные правительством США.
  11. ^ Смарт, Джон Фергюсон (2008). Java Power Tools. "O'Reilly Media, Inc.". стр. 301. ISBN 978-1-4919-5454-6. Архивировано из оригинала 26 сентября 2024 . Получено 20 июля 2019 .
  12. ^ Уилер, Дэвид. «Комментарии по системам управления конфигурацией программного обеспечения (SCM) с открытым исходным кодом / бесплатным программным обеспечением (OSS/FS)». Архивировано из оригинала 9 ноября 2020 г. Получено 8 мая 2007 г.
  13. ^ GitLab. «Каковы лучшие практики управления версиями Git?». gitlab.com . Получено 11 ноября 2022 г.
  14. ^ Алессандро Пикарелли (2020-11-17). «Стоимость неиспользования контроля версий». Архивировано из оригинала 2022-11-19 . Получено 2022-11-18 . С точки зрения человеко-часов это обойдется вам в 6–48 раз больше, чем стоило бы использование контроля версий, и это за перемотку пары моделей для одного разработчика.
  15. ^ Ирма Азарян (2023-06-14). "Обзор контроля версий программного обеспечения: системы, преимущества и почему это важно". Архивировано из оригинала 2024-09-26 . Получено 2022-11-18 . Системы контроля версий позволяют сравнивать файлы, выявлять различия и объединять изменения, если это необходимо, перед фиксацией любого кода. Версионирование также является отличным способом отслеживать сборки приложений, позволяя определять, какая версия в данный момент находится в разработке, QA и производстве.
  16. ^ ReQtest (2020-10-26). "Каковы преимущества контроля версий?". Архивировано из оригинала 2022-11-22 . Получено 2022-11-21 . История документа предоставляет бесценную информацию об авторе и дате редактирования. Она также дает информацию о цели внесенных изменений. Это повлияет на разработчика, который работает над последней версией, поскольку поможет решить проблемы, возникшие в более ранних версиях. Возможность идентифицировать автора документа позволяет текущей команде связывать документы с конкретными участниками. Это, в свою очередь, позволяет текущей команде выявлять закономерности, которые могут помочь в исправлении ошибок. Это поможет улучшить общую функциональность программного обеспечения.
  17. ^ Чирадип БасуМаллик (2022-10-06). «Что такое контроль версий? Значение, инструменты и преимущества». Архивировано из оригинала 2022-11-19 . Получено 2022-11-18 . Команды разработчиков программного обеспечения могут понять эволюцию решения, изучая предыдущие версии с помощью обзоров кода.
  18. ^ Чирадип БасуМаллик (2022-10-06). «Что такое контроль версий? Значение, инструменты и преимущества». Архивировано из оригинала 2022-11-19 . Получено 2022-11-18 . Если допущена ошибка, разработчики могут вернуться назад во времени и просмотреть предыдущие итерации кода, чтобы исправить ошибку, минимизируя при этом неудобства для всех членов команды.
  19. ^ Чакон, Скотт; Штрауб, Бен (2022-10-03). "Pro Git" (Версия 2.1.395-2-g27002dd ed.). Apress. Архивировано из оригинала 2024-09-26 . Получено 2022-11-18 . Инструмент git bisect — невероятно полезный инструмент отладки, используемый для поиска конкретного коммита, который первым привел к ошибке или проблеме, путем выполнения автоматического бинарного поиска.
  20. ^ Ирма Азарян (2023-06-14). "Обзор контроля версий программного обеспечения: системы, преимущества и почему это важно". Архивировано из оригинала 2024-09-26 . Получено 2022-11-18 . Версионирование — бесценный процесс, особенно когда над одним приложением работают несколько разработчиков, поскольку оно позволяет им легко обмениваться файлами. Без контроля версий разработчики в конечном итоге будут наступать друг другу на пятки и перезаписывать изменения кода, которые кто-то другой мог выполнить, даже не осознавая этого. Использование этих систем позволяет вам проверять файлы на наличие изменений, а затем, во время регистрации, если файлы были изменены другим пользователем, вы будете предупреждены и сможете объединить их.
  21. ^ Джесси Филлипс (2019-01-21) [2018-12-12]. "Git is a Communication tool". Архивировано из оригинала 2022-11-19 . Получено 2022-11-18 . Продолжаются дискуссии об использовании rebase, merge и/или squash. Я хочу обратить внимание на суть всех этих выборов — общение.
  22. ^ Кортес-Кой, Луис Фернандо; Линарес-Васкес, Марио; Апонте, Хайро; Пошиваник, Денис (2014). «Об автоматическом создании сообщений о фиксации изменений посредством суммирования изменений исходного кода». 14-я международная рабочая конференция IEEE 2014 года по анализу и обработке исходного кода . IEEE. стр. 275–284. doi :10.1109/scam.2014.14. ISBN 978-1-4799-6148-1. S2CID  360545.
  23. ^ Вингерд, Лора (2005). Practical Perforce. O'Reilly. ISBN 0-596-10185-6. Архивировано из оригинала 2007-12-21 . Получено 2006-08-27 .
  24. ^ набор изменений в git-глоссарии
  25. ^ пересмотр в gitglossary
  26. ^ Понимание Mercurial - Mercurial
  27. Mercurial: ChangeSet Архивировано 15 января 2010 г. на Wayback Machine
  28. ^ "Сравнение систем контроля версий". Better SCM Initiative. Архивировано из оригинала 21.03.2009.
  29. Грегори, Гэри (3 февраля 2011 г.). «Trunk против HEAD в системах контроля версий». Java, Eclipse и другие технические подробности . Архивировано из оригинала 2020-09-20 . Получено 16-12-2012 .
  30. ^ Коллинз-Сасман, Фицпатрик и Пилато 2004, 1.5: Решение цикла тура SVN: «Буква G обозначает merGed, что означает, что файл изначально имел локальные изменения, но изменения, поступающие из репозитория, не перекрывались локальными изменениями».
  31. ^ Руководство по концепциям (версия 4.7 ред.). Accurev. Июль 2008 г.
  32. Сийбрандий, Сице (29 сентября 2014 г.). «Поток GitLab». ГитЛаб . Проверено 4 августа 2018 г.
  33. ^ ab Johnson, Mark (8 ноября 2013 г.). «Что такое запрос на извлечение?». Oaawatch . Получено 27 марта 2016 г.
  34. ^ "Использование запросов на извлечение". GitHub . Получено 27 марта 2016 г.
  35. ^ "Создание запроса на извлечение". Atlassian . Получено 27 марта 2016 г.
  36. ^ "SVNBook" . Получено 2012-04-20 .
  37. ^ "Концепции и лучшие практики управления версиями". 2018-03-03. Архивировано из оригинала 2020-04-27 . Получено 2020-07-10 .
  38. ^ Уоллен, Джек (22.09.2020). «GitHub заменит master на main, начиная с октября: что разработчикам нужно сделать сейчас». TechRepublic . Архивировано из оригинала 08.02.2021 . Получено 24.04.2022 .
  39. ^ Хайнце, Кэролин (2020-11-24). «Почему GitHub переименовал свою главную ветку в основную». TheServerSide . Архивировано из оригинала 2022-05-26 . Получено 2022-04-24 .

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