Контроль версий
 | Эта статья нуждается в дополнительных ссылок для проверки . ( апрель 2011 г. ) |
Контроль версий (также известный как контроль версий , контроль версий и управление исходным кодом ) — это практика разработки программного обеспечения для управления компьютерными файлами и версиями файлов; в первую очередь исходного кода текстовые файлы , но обычно файлы любого типа.
Контроль версий — это компонент управления конфигурацией программного обеспечения . [1]
Система контроля версий — это программный инструмент , который автоматизирует контроль версий. Альтернативно, контроль версий встроен как функция некоторых систем, таких как текстовые процессоры , электронные таблицы , совместные веб-документы и т. д . [2] и системы управления контентом , например, история страниц Википедии .
Контроль версий включает просмотр старых версий и позволяет вернуть файл к предыдущей версии.
Обзор [ править ]
Когда команды разрабатывают программное обеспечение, часто на разных сайтах развертывается несколько версий одного и того же программного обеспечения, и разработчики одновременно работают над обновлениями. Ошибки или особенности программного обеспечения часто присутствуют только в определенных версиях (из-за исправления одних проблем и появления других по мере развития программы). Поэтому для поиска и исправления ошибок жизненно важно иметь возможность извлекать и запускать различные версии программного обеспечения, чтобы определить, в какой версии (версиях) возникает проблема. Также может потребоваться разработка двух версий программного обеспечения одновременно: например, если в одной версии исправлены ошибки, но нет новых функций ( ветвь ), а в другой версии работают над новыми функциями ( магистраль ).
На самом простом уровне разработчики могли бы просто сохранить несколько копий разных версий программы и соответствующим образом пометить их. Этот простой подход использовался во многих крупных проектах по разработке программного обеспечения. Хотя этот метод может работать, он неэффективен, поскольку необходимо поддерживать множество почти идентичных копий программы. Это требует большой самодисциплины со стороны разработчиков и часто приводит к ошибкам. Поскольку база кода одинакова, она также требует предоставления разрешений на чтение, запись и выполнение ряду разработчиков, и это увеличивает нагрузку на кого-то, управляющего разрешениями, чтобы база кода не была скомпрометирована, что увеличивает сложность. Следовательно, были разработаны системы для автоматизации некоторых или всех процессов контроля версий. Это гарантирует, что большая часть управления этапами контроля версий скрыта за кулисами.
Более того, в разработке программного обеспечения, юридической и деловой практике, а также в других средах становится все более распространенным явление, когда один документ или фрагмент кода редактируется командой, члены которой могут быть географически разбросаны и могут преследовать разные и даже противоположные цели. интересы. Сложный контроль версий, который отслеживает и учитывает право собственности на изменения в документах и коде, может быть чрезвычайно полезным или даже незаменимым в таких ситуациях.
Контроль версий может также отслеживать изменения в файлах конфигурации , например тех, которые обычно хранятся в /etc или /usr/local/etcв системах Unix . Это дает системным администраторам еще один способ легко отслеживать внесенные изменения и возможность вернуться к более ранним версиям в случае необходимости.
Многие системы контроля версий идентифицируют версию файла как число или букву, называемую номером версии , версией , номером редакции , ревизией или уровнем редакции . Например, первой версией файла может быть версия 1 . При изменении файла следующая версия — 2 . Каждая версия связана с отметкой времени и лицом, внесшим изменения. Версии можно сравнивать, восстанавливать и, для некоторых типов файлов, объединять. [3]
История [ править ]
Инструмент обновления программного обеспечения IBM OS/360 IEBUPDTE появился в 1962 году и, возможно, был предшественником инструментов системы контроля версий. Два пакета управления исходным кодом и контроля версий, которые активно использовались при установке IBM 360/370, — это The Librarian и Panvalet . [4] [5]
Полная система контроля исходного кода была запущена в 1972 году — Система контроля исходного кода для той же системы (OS/360). Введение в систему контроля исходного кода, опубликованное 4 декабря 1975 года, исторически подразумевало, что это была первая преднамеренная система контроля версий. [6] RCS последовал сразу за этим, [7] с его сетевой версией Concurrent Versions System . В следующем поколении после системы параллельных версий доминировала Subversion , [8] за которым последовало появление распределенных инструментов контроля версий, таких как Git . [9]
Структура [ править ]
Контроль версий управляет изменениями набора данных с течением времени. Эти изменения могут быть структурированы по-разному.
Часто данные представляют собой совокупность множества отдельных элементов, таких как файлы или документы, и отслеживаются изменения в отдельных файлах. Это согласуется с интуицией об отдельных файлах, но вызывает проблемы при изменении идентичности, например, при переименовании, разделении или объединении файлов. Соответственно, некоторые системы, такие как Git , вместо этого рассматривают изменения данных в целом, что менее интуитивно понятно для простых изменений, но упрощает более сложные изменения.
Когда данные, находящиеся под контролем версий, изменяются после получения путем извлечения, это, как правило, не сразу отражается в системе контроля версий (в репозитории ), а вместо этого должно быть возвращено или зафиксировано. Копия вне системы контроля версий называется «рабочей копией». В качестве простого примера: при редактировании компьютерного файла данные, хранящиеся в памяти программой редактирования, представляют собой рабочую копию, которая фиксируется путем сохранения. Конкретно, можно распечатать документ, отредактировать его вручную и только потом вручную внести изменения в компьютер и сохранить. Для контроля исходного кода рабочая копия вместо этого представляет собой копию всех файлов в определенной версии, обычно хранящуюся локально на компьютере разработчика; [примечание 1] в этом случае сохранение файла меняет только рабочую копию, а проверка в репозитории — это отдельный шаг.
Если несколько человек работают над одним набором данных или документом, они неявно создают ветви данных (в своих рабочих копиях), и, таким образом, возникают проблемы слияния, как описано ниже. При простом совместном редактировании документов этого можно избежать, используя блокировку файлов или просто избегая работы над тем же документом, над которым работает кто-то другой.
Системы контроля версий часто централизованы, имеют единое авторитетное хранилище данных — репозиторий, а выписки и возвраты выполняются со ссылкой на этот центральный репозиторий. Альтернативно, в распределенном контроле версий ни один репозиторий не является авторитетным, и данные можно извлекать и возвращать в любой репозиторий. При проверке в другом репозитории это интерпретируется как слияние или исправление.
Структура графа [ править ]
С точки зрения теории графов , изменения обычно рассматриваются как линия развития ( ствол ) с ответвлениями от нее, образующими направленное дерево, визуализируемое как одна или несколько параллельных линий развития («основные линии» ветвей). с багажника. На самом деле структура более сложная, образующая ориентированный ациклический граф , но для многих целей «дерево со слияниями» является адекватным приближением.
Редакции происходят последовательно с течением времени и, таким образом, могут быть упорядочены по номеру ревизии или метке времени. [заметка 2] Редакции основаны на прошлых редакциях, хотя можно в значительной степени или полностью заменить более раннюю редакцию, например «удалить весь существующий текст, вставить новый текст». В простейшем случае, без ветвления или отмены, каждая ревизия основана только на ее непосредственном предшественнике, и они образуют простую строку с одной последней версией, ревизией или наконечником «HEAD» . В терминах теории графов , рисуя каждую ревизию в виде точки и каждую связь «производной ревизии» в виде стрелки (обычно указывающей от старой к новой, в том же направлении, что и время), это линейный график . Если существует ветвление, то есть несколько будущих ревизий основаны на прошлой ревизии, или отмена, так что редакция может зависеть от ревизии, более старой, чем ее непосредственный предшественник, тогда результирующий граф вместо этого представляет собой ориентированное дерево (каждый узел может иметь более одного дочерний элемент) и имеет несколько подсказок, соответствующих версиям без дочерних элементов («последняя версия в каждой ветке»). [заметка 3] В принципе, результирующее дерево не обязательно должно иметь предпочтительную вершину («основную» последнюю ревизию) — просто различные разные версии, — но на практике одна вершина обычно обозначается как HEAD. Когда новая ревизия основана на HEAD, она либо идентифицируется как новая HEAD, либо считается новой ветвью. [примечание 4] Список ревизий от начала до HEAD (в терминах теории графов — уникальный путь в дереве, который, как и раньше, образует линейный граф) — это ствол или основная линия. [примечание 5] И наоборот, когда ревизия может быть основана на более чем одной предыдущей ревизии (когда узел может иметь более одного родительского узла ), результирующий процесс называется слиянием и является одним из наиболее сложных аспектов контроля версий. Чаще всего это происходит, когда изменения происходят в нескольких ветвях (чаще всего в двух, но возможно и больше), которые затем объединяются в одну ветвь, включающую оба изменения. Если эти изменения перекрываются, объединить их может быть сложно или невозможно, и потребуется ручное вмешательство или переписывание.
При наличии слияний результирующий граф больше не является деревом, поскольку узлы могут иметь несколько родителей, а представляет собой корневой направленный ациклический граф (DAG). Граф является ациклическим, поскольку родительские элементы всегда расположены в обратном направлении во времени, а корневым является наличие самой старой версии. Предполагая, что ствол существует, слияния ветвей можно рассматривать как «внешние» по отношению к дереву – изменения в ветке упаковываются в виде патча, который применяется к HEAD (ствола), создавая новую ревизию без каких-либо явных изменений. ссылка на ветку и сохранение древовидной структуры. Таким образом, хотя фактические отношения между версиями образуют DAG, это можно считать деревом плюс слияния, а сам ствол — линией.
При распределенном контроле версий при наличии нескольких репозиториев они могут основываться на одной исходной версии (корне дерева), но исходный корень не обязательно должен быть — вместо этого для каждого может быть отдельный корень (самая старая ревизия). хранилище. Это может произойти, например, если два человека начнут работать над проектом по отдельности. Аналогичным образом, при наличии нескольких наборов данных (несколько проектов), которые обмениваются данными или сливаются, не существует единого корня, хотя для простоты можно считать один проект первичным, а другой — вторичным, слитым с первым с его или без него. собственная история изменений.
Специализированные стратегии [ править ]
Контроль инженерных версий, разработанный на основе формализованных процессов, основанных на отслеживании изменений ранних чертежей или чертежей. [ нужна цитата ] . Эта система контроля неявно позволяла вернуться к более раннему состоянию проекта в случаях, когда в разработке проекта был заведён инженерный тупик. Для отслеживания внесенных изменений использовалась таблица редакций. Дополнительно измененные области чертежа выделялись с помощью ревизионных облаков.
В бизнесе и праве [ править ]
Контроль версий широко распространен в бизнесе и юриспруденции. Действительно, «красная линия контракта» и «юридическая черная линия» являются одними из самых ранних форм контроля версий. [10] и до сих пор работают в бизнесе и юриспруденции с разной степенью сложности. ) начинают использоваться самые сложные методы Для электронного отслеживания изменений в файлах САПР (см. « Управление данными о продукции» , вытесняя «ручное» электронное осуществление традиционного контроля версий. [ нужна цитата ]
управления кодом исходным Модели
Традиционные системы контроля версий используют централизованную модель, в которой все функции контроля версий выполняются на общем сервере . Если два разработчика попытаются изменить один и тот же файл одновременно, без какого-либо метода управления доступом разработчики могут в конечном итоге перезаписать работу друг друга. Централизованные системы контроля версий решают эту проблему с помощью одной из двух различных «моделей управления исходным кодом»: блокировки файлов и слияния версий.
Атомарные операции [ править ]
Операция является атомарной , если система остается в согласованном состоянии, даже если операция прерывается. Операция фиксации обычно является наиболее важной в этом смысле. Коммиты сообщают системе контроля версий сделать группу изменений окончательной и доступной для всех пользователей. Не все системы контроля версий имеют атомарные фиксации; В системе параллельных версий эта функция отсутствует. [11]
Блокировка файлов [ править ]
Самый простой метод предотвращения « параллельного доступа проблем » включает в себя блокировку файлов , чтобы только один разработчик одновременно имел доступ на запись к центральному « хранилищу » копий этих файлов. Как только один разработчик «извлечет» файл, другие смогут прочитать этот файл, но никто другой не сможет изменить этот файл до тех пор, пока этот разработчик не «зарегистрирует» обновленную версию (или не отменит извлечение).
Блокировка файлов имеет как преимущества, так и недостатки. Это может обеспечить некоторую защиту от сложных конфликтов слияния, когда пользователь вносит радикальные изменения во многие разделы большого файла (или группы файлов). Если файлы остаются заблокированными слишком долго, у других разработчиков может возникнуть соблазн обойти программное обеспечение контроля версий и изменить файлы локально, что приведет к сложному ручному слиянию, когда другие изменения наконец будут проверены. В большой организации файлы могут быть заблокированы. оставленный «извлеченным», заблокированным и забытым по мере того, как разработчики перемещаются между проектами — эти инструменты могут или не могут облегчить просмотр того, кто извлек файл.
Объединение версий [ править ]
Большинство систем контроля версий позволяют нескольким разработчикам одновременно редактировать один и тот же файл. Первый разработчик, который «зарегистрирует» изменения в центральном репозитории, всегда добивается успеха. Система может предоставлять возможности для объединения дальнейших изменений в центральный репозиторий и сохранения изменений первого разработчика при регистрации других разработчиков.
Объединение двух файлов может быть очень деликатной операцией и обычно возможно только в том случае, если структура данных проста, как в текстовых файлах . Результат объединения двух файлов изображений может вообще не привести к созданию файла изображения. Второй разработчик, проверяющий код, должен будет позаботиться о слиянии, чтобы убедиться, что изменения совместимы и что операция слияния не вносит свои собственные логические в файлы ошибки. Эти проблемы ограничивают доступность автоматических или полуавтоматических операций слияния в основном для простых текстовых документов, если только специальный плагин для этих типов файлов не доступен слияния.
Концепция зарезервированного редактирования может предоставить дополнительные средства явной блокировки файла для эксклюзивного доступа на запись, даже если существует возможность слияния.
Базовые показатели, метки и теги [ править ]
Большинство инструментов контроля версий будут использовать только один из этих похожих терминов (базовый вариант, метка, тег) для обозначения действия по идентификации моментального снимка («пометить проект») или записи моментального снимка («попробуйте с базовым состоянием X »). . только один из терминов «базовый уровень» , «метка» или «тег» . Обычно в документации или обсуждении используется [ нужна цитата ] ; их можно считать синонимами.
В большинстве проектов некоторые снимки более важны, чем другие, например те, которые используются для обозначения опубликованных выпусков, ветвей или вех.
Когда термин «базовый уровень» и «метка» или «тег» используются вместе в одном и том же контексте, «метка» и «тег» обычно относятся к механизму внутри инструмента идентификации или создания записи моментального снимка, а « базовый уровень» указывает на повышенную значимость любой данной метки. или тег.
В наиболее формальном обсуждении управления конфигурацией используется термин «базовый уровень» .
Распределенный контроль версий [ править ]
Распределенные системы контроля версий (DRCS) используют одноранговый подход, в отличие от клиент-серверного подхода централизованных систем. Вместо единого центрального репозитория, в котором синхронизируются клиенты, рабочая копия кодовой базы каждого узла является настоящим репозиторием. [12] Распределенный контроль версий осуществляет синхронизацию путем обмена исправлениями (наборами изменений) от однорангового узла к одноранговому. Это приводит к некоторым важным отличиям от централизованной системы:
- По умолчанию канонической эталонной копии кодовой базы не существует; только рабочие экземпляры.
- Обычные операции (такие как фиксации, просмотр истории и откат изменений) выполняются быстро, поскольку нет необходимости связываться с центральным сервером. [1] : 7
Скорее, связь необходима только при отправке или получении изменений от других узлов.
- Каждая рабочая копия эффективно функционирует как удаленная резервная копия кодовой базы и ее истории изменений, обеспечивая внутреннюю защиту от потери данных. [1] : 4
Лучшие практики [ править ]
Следование лучшим практикам необходимо для получения всех преимуществ контроля версий. Рекомендации могут различаться в зависимости от инструмента контроля версий и области, к которой применяется контроль версий. Общепринятые передовые методы разработки программного обеспечения включают: внесение дополнительных, небольших изменений; выполнение коммитов , которые включают только одну задачу или исправление — следствием этого является фиксация только кода, который работает и сознательно не нарушает существующие функциональные возможности; использование ветвления для завершения функциональности перед выпуском; написание четких и описательных сообщений о коммитах, пояснение того, почему и насколько ясно в описании коммита или в коде; и использование последовательной стратегии ветвления. [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 ), набор изменений , обновление или патч идентифицируют набор изменений , внесенных в одну фиксацию. Это также может представлять собой последовательное представление исходного кода, позволяющее проверять источник по любому конкретному идентификатору списка изменений.
Оформить заказ [ править ]
Выписать сотрудничать (или ) — значит создать локальную рабочую копию из репозитория. Пользователь может указать конкретную версию или получить последнюю версию. Термин «оформление заказа» также может использоваться как существительное для описания рабочей копии. Если файл извлечен с общего файлового сервера, другие пользователи не смогут его редактировать. Думайте об этом как об отеле: когда вы выезжаете из него, у вас больше нет доступа к его удобствам.
Клонировать [ править ]
Клонирование означает создание репозитория, содержащего версии из другого репозитория. Это эквивалентно отправке или извлечению данных в пустой (только что инициализированный) репозиторий. Как существительное, два репозитория можно назвать клонами , если они синхронизированы и содержат одни и те же версии.
Совершить (существительное) [ править ]
Совершить (глагол) [ править ]
Коммит ) означает запись или слияние изменений, внесенных в рабочую копию , ( check in , ci или, реже, install , submit или Record обратно в репозиторий. Коммит содержит метаданные, обычно информацию об авторе и сообщение о коммите, описывающее изменение.
Сообщение о фиксации [ править ]
Короткая заметка, написанная разработчиком и хранящаяся вместе с коммитом, описывающая коммит. В идеале в нем фиксируется причина внесения изменения, описание эффекта или цели изменения, а также неочевидные аспекты того, как это изменение работает.
Конфликт [ править ]
Конфликт возникает, когда разные стороны вносят изменения в один и тот же документ, и система не может согласовать эти изменения. Пользователь должен разрешить конфликт, объединив изменения или выбрав одно изменение в пользу другого.
Дельта-сжатие [ править ]
Большинство программ контроля версий использует дельта-сжатие , при котором сохраняются только различия между последовательными версиями файлов. Это позволяет более эффективно хранить множество различных версий файлов.
Динамический поток [ править ]
Поток, в котором некоторые или все версии файлов являются зеркалами версий родительского потока.
Экспортировать [ править ]
Экспорт — это получение файлов из репозитория. Это похоже на извлечение, за исключением того, что оно создает чистое дерево каталогов без метаданных контроля версий, используемых в рабочей копии. Это часто используется, например, перед публикацией содержимого.
Получить [ править ]
Смотрите тянуть .
Прямая интеграция [ править ]
Процесс объединения изменений, внесенных в основную ветку , в ветку разработки (функцию или команду).
Глава [ править ]
Также иногда называется подсказкой . Это относится к самому последнему коммиту, либо в ствол, либо в ветку. Ствол и каждая ветвь имеют свою собственную голову, хотя HEAD иногда широко используется для обозначения ствола. [29]
Импортировать [ править ]
Импорт — это первое копирование дерева локальных каталогов (которое в настоящее время не является рабочей копией) в репозиторий.
Инициализировать [ править ]
Чтобы создать новый пустой репозиторий.
Перемежающиеся дельты [ править ]
Некоторые программы контроля версий используют чередующиеся дельты — метод, который позволяет хранить историю текстовых файлов более эффективным способом, чем использование дельта-сжатия .
Ярлык [ править ]
Смотрите тег .
Блокировка [ править ]
Когда разработчик блокирует файл, никто другой не сможет обновить этот файл, пока он не будет разблокирован. Блокировка может поддерживаться системой контроля версий или посредством неформального общения между разработчиками (так называемая социальная блокировка ).
Основная линия [ править ]
Аналогично «транку» , но для каждой ветки может быть магистральная линия.
Иди [ править ]
Слияние — это операция , или интеграция при которой к файлу или набору файлов применяются два набора изменений. Вот некоторые примеры сценариев:
- Пользователь, работая с набором файлов, обновляет или синхронизирует свою рабочую копию с изменениями, внесенными и проверенными в репозитории другими пользователями. [30]
- Пользователь пытается вернуть файлы, которые были обновлены другими с момента извлечения файлов , и программа контроля версий автоматически объединяет файлы (обычно после запроса пользователя, следует ли ему продолжить автоматическое объединение, а в некоторых случаях только это следует делать, если слияние может быть четко и разумно разрешено).
- Создается ветка , код в файлах самостоятельно редактируется, а обновленная ветка в дальнейшем объединяется в единый унифицированный ствол .
- Набор файлов разветвлен . Проблема, существовавшая до разветвления, устраняется в одной ветке, а затем исправление объединяется с другой веткой. (Этот тип выборочного слияния иногда называют « выбором вишни» , чтобы отличить его от полного слияния в предыдущем случае.)
Продвигать [ править ]
Копирование содержимого файла из менее контролируемого места в более контролируемое. Например, из рабочей области пользователя в репозиторий или из потока в его родительский элемент. [31]
Тяни, толкай [ править ]
Копирование ревизий из одного репозитория в другой. Pull инициируется принимающим репозиторием, а push инициируется источником. Fetch иногда используется как синоним слова pull или для обозначения извлечения , за которым следует обновление .
Запрос на вытягивание [ править ]
Вклад в репозиторий исходного кода, использующий распределенную систему контроля версий, обычно вносится с помощью запроса на включение, также известного как запрос на слияние. [32] Участник запрашивает, чтобы сопровождающий проекта внес изменения в исходный код, отсюда и название «запрос на включение». Мейнтейнер должен объединить запрос на включение, если вклад должен стать частью исходной базы. [33]
Разработчик создает запрос на включение, чтобы уведомить сопровождающих о новом изменении; поток комментариев связан с каждым запросом на включение. Это позволяет целенаправленно обсуждать изменения кода . Отправленные запросы на включение видны всем, у кого есть доступ к репозиторию. Запрос на включение может быть принят или отклонен сопровождающими. [34]
После того как запрос на извлечение проверен и одобрен, он добавляется в репозиторий. В зависимости от установленного рабочего процесса, возможно, потребуется протестировать код перед включением в официальный выпуск. Поэтому некоторые проекты содержат специальную ветку для объединения непроверенных пул-реквестов. [33] [35] Другие проекты запускают набор автоматизированных тестов при каждом запросе на включение, используя инструмент непрерывной интеграции , и рецензент проверяет, имеет ли новый код соответствующее тестовое покрытие.Репозиторий [ править ]
Решить [ править ]
Вмешательство пользователя для устранения конфликта между различными изменениями в одном и том же документе.
Обратная интеграция [ править ]
Процесс объединения различных ветвей команды в основную магистраль системы управления версиями.
Редакция и версия [ править ]
Версия — это любое изменение формы. В SVK ревизия — это состояние всего дерева в репозитории на определенный момент времени.
[ править ]
Действие по обеспечению доступа к одному файлу или папке в нескольких ветках одновременно. Когда общий файл изменяется в одной ветке, он изменяется и в других ветках.
Поток [ править ]
Контейнер для разветвленных файлов, имеющий известное отношение к другим таким контейнерам. Потоки образуют иерархию; каждый поток может наследовать различные свойства (например, версии, пространство имен, правила рабочего процесса, подписчиков и т. д.) от своего родительского потока.
Тег [ изменить ]
Тег . или метка относится к важному моментальному снимку во времени, единообразному для многих файлов На этом этапе все эти файлы могут быть помечены понятным для пользователя понятным именем или номером версии. См. базовые показатели, метки и теги .
Багажник [ править ]
Магистральная линия — это уникальная линия разработки, не являющаяся ветвью (иногда называемая базовой линией, основной линией или основной линией). [38] [39] )
Обновление [ править ]
Обновление рабочую (или синхронизация , но синхронизация также может означать комбинированное извлечение и извлечение ) объединяет изменения, сделанные в репозитории (например, другими людьми), в локальную копию . Обновление — это также термин, используемый некоторыми инструментами CM (CM+, PLS, SMS) для концепции пакета изменений (см. список изменений ). Синоним извлечения в системах контроля версий, которые требуют, чтобы в каждом репозитории была ровно одна рабочая копия (обычно в распределенных системах).
Разблокировка [ править ]
Снятие блокировки.
Рабочая копия [ править ]
Рабочая копия — это локальная копия файлов из репозитория, созданная в определенное время или в определенной редакции. Вся работа с файлами в репозитории изначально выполняется в рабочей копии, отсюда и название. Концептуально это песочница .
См. также [ править ]
- Изменить управление
- Журнал изменений
- Блокчейн
- Сравнение программного обеспечения для контроля версий
- Сравнение средств размещения исходного кода
- Контроль версий данных
- Распределенный контроль версий
- Список программного обеспечения для контроля версий
- Нелинейное редактирование
- Управление конфигурацией программного обеспечения
- Управление версиями программного обеспечения
- Управление версиями файловой системы
Примечания [ править ]
- ^ В этом случае буферы редактирования являются вторичной формой рабочей копии и не называются таковыми.
- ^ В принципе, две версии могут иметь одинаковую временную метку, и поэтому их нельзя упорядочить в одной строке. Обычно это справедливо для отдельных репозиториев, но возможно и для одновременных изменений в нескольких ветках одного репозитория. В этих случаях ревизии можно рассматривать как набор отдельных строк, по одной на каждый репозиторий или ветку (или ветку внутри репозитория).
- ^ «Дерево» ревизии или репозитория не следует путать с деревом каталогов файлов в рабочей копии.
- ^ Если новая ветвь основана на HEAD, то топологически HEAD больше не является вершиной, поскольку у нее есть дочерний элемент.
- ^ «Основная линия» также может относиться к основному пути в отдельной ветке.
Ссылки [ править ]
- ^ Перейти обратно: а б с О'Салливан, Брайан (2009). Mercurial: Полное руководство . O'Reilly Media, Inc. Севастополь: ISBN 978-0-596-55547-4 . Проверено 4 сентября 2015 г.
- ^ « Документы Google ». Посмотрите, что изменилось в файле , Google Inc.
- ^ Скотт, Чакон; Штрауб, Бен (2014). Второе издание Pro Git . США: Апресс . п. 14.
- ^ Гетц, Мартин (3 мая 2002 г.). «Интервью с Мартином Гетцем» (Интервью). Беседовал Джеффри Р. Йост. Вашингтон, округ Колумбия: Институт Чарльза Бэббиджа, Университет Миннесоты. стр. 5–7.
- ^ Пишипо, Джозеф (3 мая 2002 г.). «Интервью с Джозефом Пископо» (Интервью). Беседовал Томас Хей. Вашингтон, округ Колумбия: Институт Чарльза Бэббиджа, Университет Миннесоты. стр. 3, 5, 12–13.
- ^ Рочкинд, Марк Дж. (1975). «Система контроля исходного кода» (PDF) . Транзакции IEEE по разработке программного обеспечения . СЭ-1 (4): 364–370. дои : 10.1109/TSE.1975.6312866 . S2CID 10006076 .
- ^ Тичи, Уолтер Ф. (1985). «Rcs — система контроля версий» . Программное обеспечение: практика и опыт . 15 (7): 637–654. дои : 10.1002/спе.4380150703 . ISSN 0038-0644 . S2CID 2605086 .
- ^ Коллинз-Сассман, Бен; Фитцпатрик, BW; Пилато, CM (2004), Контроль версий с помощью Subversion , О'Рейли, ISBN 0-596-00448-6
- ^ Лелигер, Джон; Маккалоу, Мэтью (2012). Контроль версий с помощью Git: мощные инструменты и методы для совместной разработки программного обеспечения . О'Рейли Медиа. стр. 2–5. ISBN 978-1-4493-4504-4 .
- ^ Технические чертежи см. в Whiteprint#Document control , где описаны некоторые ручные системы, действовавшие в двадцатом веке, например, Инженерные процедуры Hughes Aircraft , каждая редакция которых требовала одобрения Лоуренса А. Хайланда ; см. также процедуры одобрения, установленные правительством США.
- ^ Смарт, Джон Фергюсон (2008). Электроинструменты Java . «О'Рейли Медиа, Инк.». п. 301. ИСБН 978-1-4919-5454-6 . Проверено 20 июля 2019 г.
- ^ Уилер, Дэвид. «Комментарии к программному обеспечению с открытым исходным кодом/свободному программному обеспечению (OSS/FS) системам управления конфигурацией программного обеспечения (SCM)» . Архивировано из оригинала 9 ноября 2020 года . Проверено 8 мая 2007 г.
- ^ ГитЛаб. «Каковы лучшие практики управления версиями Git?» . gitlab.com . Проверено 11 ноября 2022 г.
- ^ Алессандро Пикарелли (17 ноября 2020 г.). «Цена отсутствия контроля версий» . Проверено 18 ноября 2022 г.
С точки зрения человеко-часов это будет стоить вам в 6–48 раз больше, чем если бы вы использовали контроль версий, и это за перемотку пары моделей для одного разработчика.
- ^ Ирма Азарян (14 июня 2023 г.). «Обзор контроля версий программного обеспечения: системы, преимущества и почему это важно» . Проверено 18 ноября 2022 г.
Системы контроля версий позволяют сравнивать файлы, выявлять различия и при необходимости объединять изменения перед фиксацией какого-либо кода. Управление версиями также является отличным способом отслеживать сборки приложений, позволяя определить, какая версия в настоящее время находится в разработке, тестировании и производстве.
- ^ РеКтест (26 октября 2020 г.). «Каковы преимущества контроля версий?» . Проверено 21 ноября 2022 г.
История документа предоставляет бесценную информацию об авторе и дате редактирования. Также указывается цель внесенных изменений. Это окажет влияние на разработчика, работающего над последней версией, поскольку поможет решить проблемы, возникшие в более ранних версиях. Возможность идентифицировать автора документа позволяет текущей команде связать документы с конкретными участниками. Это, в свою очередь, позволяет нынешней команде выявлять закономерности, которые могут помочь в исправлении ошибок. Это поможет улучшить общую функциональность программного обеспечения.
- ^ Чирадип БасуМаллик (06 октября 2022 г.). «Что такое контроль версий? Значение, инструменты и преимущества» . Проверено 18 ноября 2022 г.
Команды разработчиков программного обеспечения могут понять эволюцию решения, исследуя предыдущие версии посредством проверок кода.
- ^ Чирадип БасуМаллик (06 октября 2022 г.). «Что такое контроль версий? Значение, инструменты и преимущества» . Проверено 18 ноября 2022 г.
Если допущена ошибка, разработчики могут вернуться в прошлое и просмотреть предыдущие итерации кода, чтобы исправить ошибку, сводя к минимуму беспокойство для всех членов команды.
- ^ Чакон, Скотт; Штрауб, Бен (3 октября 2022 г.). «Pro Git» (версия 2.1.395-2-g27002dd, изд.). Апресс . Проверено 18 ноября 2022 г.
Инструмент git bisect — невероятно полезный инструмент отладки, используемый для определения того, какой конкретный коммит был первым, в котором возникла ошибка или проблема, путем автоматического двоичного поиска.
- ^ Ирма Азарян (14 июня 2023 г.). «Обзор контроля версий программного обеспечения: системы, преимущества и почему это важно» . Проверено 18 ноября 2022 г.
Управление версиями — бесценный процесс, особенно если над одним приложением работают несколько разработчиков, поскольку он позволяет им легко обмениваться файлами. Без контроля версий разработчики в конечном итоге будут наступать друг другу на ногу и перезаписывать изменения кода, которые кто-то другой мог выполнить, даже не осознавая этого. Использование этих систем позволяет вам проверять файлы на наличие изменений, а затем, во время регистрации, если файлы были изменены другим пользователем, вы получите предупреждение и сможете объединить их.
- ^ Джесси Филлипс (21 января 2019 г.) [12 декабря 2018 г.]. «Git — это инструмент коммуникации» . Проверено 18 ноября 2022 г.
Продолжаются дискуссии об использовании перебазирования, слияния и/или сжатия. Я хочу сосредоточить внимание на всем этом выборе — общении.
- ^ Кортес-Кой, Луис Фернандо; Линарес-Васкес, Марио; Апонте, Хайро; Пошиваник, Денис (2014). «Об автоматической генерации сообщений о фиксации посредством обобщения изменений исходного кода». 2014 IEEE 14-я Международная рабочая конференция по анализу и манипулированию исходным кодом . IEEE. стр. 275–284. дои : 10.1109/scam.2014.14 . ISBN 978-1-4799-6148-1 . S2CID 360545 .
- ^ Вингерд, Лаура (2005). Практическая Перфорс . О'Рейли. ISBN 0-596-10185-6 . Архивировано из оригинала 21 декабря 2007 г. Проверено 27 августа 2006 г.
- ^ набор изменений в gitglossary
- ^ редакция в gitglossary
- ^ Понимание Mercurial - Mercurial
- ↑ Mercurial: ChangeSet. Архивировано 15 января 2010 г., в Wayback Machine.
- ^ «Сравнение систем контроля версий» . Улучшенная инициатива SCM. Архивировано из оригинала 21 марта 2009 г.
- ^ Грегори, Гэри (3 февраля 2011 г.). «Trunk vs. HEAD в системах контроля версий» . Java, Eclipse и другие технологические новинки . Проверено 16 декабря 2012 г.
- ^ Collins-Sussman, Fitzpatrick & Pilato 2004 , 1.5: Разрешение цикла обхода SVN : «G означает merGed, что означает, что файл изначально имел локальные изменения, но изменения, поступающие из репозитория, не перекрывались с локальными изменения.'
- ^ Руководство по концепциям (изд. версии 4.7). Аккурев. Июль 2008 года.
- ^ Сийбрандий, Сице (29 сентября 2014 г.). «Поток GitLab» . ГитЛаб . Проверено 4 августа 2018 г.
- ^ Перейти обратно: а б Джонсон, Марк (8 ноября 2013 г.). «Что такое запрос на включение?» . Оаааач . Проверено 27 марта 2016 г.
- ^ «Использование запросов на включение» . Гитхаб . Проверено 27 марта 2016 г.
- ^ «Оформление запроса на извлечение» . Атласиан . Проверено 27 марта 2016 г.
- ^ «СВНБук» . Проверено 20 апреля 2012 г.
- ^ «Концепции и лучшие практики контроля версий» . 03.03.2018. Архивировано из оригинала 27 апреля 2020 г. Проверено 10 июля 2020 г.
- ^ Уоллен, Джек (22 сентября 2020 г.). «GitHub заменит master на main начиная с октября: что разработчикам нужно делать сейчас» . Техреспублика . Проверено 24 апреля 2022 г.
- ^ Хайнце, Кэролайн (24 ноября 2020 г.). «Почему GitHub переименовал свою главную ветку в главную» . Серверная сторона . Проверено 24 апреля 2022 г.
Внешние ссылки [ править ]
- «Визуальное руководство по контролю версий», Лучшее объяснение .
- Синк, Эрик, «Контроль версий», SCM (инструкции) . Основы контроля версий.
Годы, если они доступны, указывают дату первого стабильного выпуска. Системы с именами, выделенными курсивом, больше не поддерживаются или имеют запланированные даты окончания срока службы. | ||||||
| Только местное |
| | ||||
| Клиент-сервер |
| |||||
| Распределенный |
| |||||
| Концепции | ||||||
| Базы данных органов управления : Национальные |
|---|
