В разработке программного обеспечения контроль версий (также известный как контроль версий , контроль версий или управление исходным кодом ) — это класс систем, отвечающих за управление изменениями в компьютерных программах , документах, крупных веб-сайтах или других коллекциях информации. Контроль версий — это компонент управления конфигурацией программного обеспечения . [1]
Изменения обычно обозначаются цифровым или буквенным кодом, называемым «номер версии», «уровень версии» или просто «версия». Например, исходный набор файлов — «версия 1». При первом изменении результирующим набором будет «версия 2» и так далее. Каждая редакция связана с отметкой времени и лицом, внесшим изменения. Версии можно сравнивать, восстанавливать и, для некоторых типов файлов, объединять. [2]
Потребность в логическом способе организации и контроля версий существовала почти с тех пор, как существовала письменность , но контроль версий стал гораздо более важным и сложным, когда началась эра вычислений. Нумерация книжных изданий и изменений спецификаций являются примерами, относящимися к эпохе только печатных изданий. Сегодня наиболее функциональными (и сложными) системами контроля версий являются те, которые используются при разработке программного обеспечения , где группа людей может одновременно вносить изменения в одни и те же файлы.
Системы контроля версий чаще всего запускаются как автономные приложения, но контроль версий также встроен в различные типы программного обеспечения, такие как текстовые процессоры и электронные таблицы , совместные веб-документы [3] и системы управления контентом , например, история страниц Википедии . Контроль версий позволяет вернуть документ к предыдущей версии, что имеет решающее значение для того, чтобы редакторы могли отслеживать изменения друг друга, исправлять ошибки и защищаться от вандализма и спама в вики .
В разработке компьютерного программного обеспечения контроль версий — это любая практика, которая отслеживает и обеспечивает контроль над изменениями в исходном коде . Разработчики программного обеспечения иногда используют программное обеспечение для контроля версий для поддержки документации и файлов конфигурации , а также исходного кода.
Когда команды проектируют, разрабатывают и развертывают программное обеспечение, часто бывает, что несколько версий одного и того же программного обеспечения развертываются на разных сайтах, а разработчики программного обеспечения одновременно работают над обновлениями. Ошибки или особенности программного обеспечения часто присутствуют только в определенных версиях (из-за исправления одних проблем и появления других по мере развития программы). Поэтому для поиска и исправления ошибок жизненно важно иметь возможность извлекать и запускать различные версии программного обеспечения, чтобы определить, в какой версии (версиях) возникает проблема. Также может оказаться необходимым разработать две версии программного обеспечения одновременно: например, если в одной версии исправлены ошибки, но нет новых функций ( ветвь ), а в другой версии работают над новыми функциями ( магистраль ).
На самом простом уровне разработчики могли бы просто сохранить несколько копий разных версий программы и соответствующим образом пометить их. Этот простой подход использовался во многих крупных проектах по разработке программного обеспечения. Хотя этот метод может работать, он неэффективен, поскольку необходимо поддерживать множество почти идентичных копий программы. Это требует большой самодисциплины со стороны разработчиков и часто приводит к ошибкам. Поскольку база кода одинакова, она также требует предоставления разрешений на чтение, запись и выполнение ряду разработчиков, и это увеличивает нагрузку на кого-то, управляющего разрешениями, чтобы база кода не была скомпрометирована, что увеличивает сложность. Следовательно, были разработаны системы для автоматизации некоторых или всех процессов контроля версий. Это гарантирует, что большая часть управления этапами контроля версий скрыта за кулисами.
Более того, в разработке программного обеспечения, юридической и деловой практике, а также в других средах становится все более распространенным явление, когда один документ или фрагмент кода редактируется командой, члены которой могут быть географически разбросаны и могут преследовать разные и даже противоположные цели. интересы. Сложный контроль версий, который отслеживает и учитывает право собственности на изменения в документах и коде, может быть чрезвычайно полезным или даже незаменимым в таких ситуациях.
Контроль версий может также отслеживать изменения в файлах конфигурации , например тех, которые обычно хранятся в /etcсистемах Unix . Это дает системным администраторам еще один способ легко отслеживать внесенные изменения и возможность вернуться к более ранним версиям в случае необходимости./usr/local/etc
Инструмент обновления программного обеспечения IBM OS/360 IEBUPDTE появился в 1962 году и, возможно, был предшественником инструментов системы контроля версий. Два пакета управления исходным кодом и контроля версий, которые активно использовались при установке IBM 360/370, — это The Librarian и Panvalet . [4] [5]
Полная система контроля исходного кода была запущена в 1972 году — Система контроля исходного кода для той же системы (OS/360). Введение в систему контроля исходного кода, опубликованное 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] и до сих пор используются в бизнесе и праве с разной степенью сложности. Для электронного отслеживания изменений в файлах САПР (см. Управление данными о продукции ) начинают использоваться самые сложные методы , вытесняя «ручное» электронное осуществление традиционного контроля версий. [ нужна цитата ]
Традиционные системы контроля версий используют централизованную модель, в которой все функции контроля версий выполняются на общем сервере . Если два разработчика попытаются изменить один и тот же файл одновременно, без какого-либо метода управления доступом разработчики могут в конечном итоге перезаписать работу друг друга. Централизованные системы контроля версий решают эту проблему с помощью одной из двух различных «моделей управления исходным кодом»: блокировки файлов и слияния версий.
Операция является атомарной , если система остается в согласованном состоянии, даже если операция прерывается. Операция фиксации обычно является наиболее важной в этом смысле . Коммиты сообщают системе контроля версий сделать группу изменений окончательной и доступной для всех пользователей. Не все системы контроля версий имеют атомарные фиксации; В системе параллельных версий эта функция отсутствует. [11]
Самый простой метод предотвращения проблем « параллельного доступа » включает в себя блокировку файлов , чтобы только один разработчик одновременно имел доступ на запись к центральному « хранилищу » копий этих файлов. Как только один разработчик «извлечет» файл, другие смогут прочитать этот файл, но никто другой не сможет изменить этот файл до тех пор, пока этот разработчик не «зарегистрирует» обновленную версию (или не отменит извлечение).
Блокировка файлов имеет как преимущества, так и недостатки. Это может обеспечить некоторую защиту от сложных конфликтов слияния, когда пользователь вносит радикальные изменения во многие разделы большого файла (или группы файлов). Если файлы остаются заблокированными слишком долго, у других разработчиков может возникнуть соблазн обойти программное обеспечение контроля версий и изменить файлы локально, что приведет к сложному ручному слиянию, когда другие изменения наконец будут проверены. В большой организации файлы могут быть заблокированы. оставленный «извлеченным», заблокированным и забытым по мере того, как разработчики перемещаются между проектами — эти инструменты могут или не могут облегчить просмотр того, кто извлек файл.
Большинство систем контроля версий позволяют нескольким разработчикам одновременно редактировать один и тот же файл. Первый разработчик, который «зарегистрирует» изменения в центральном репозитории, всегда добивается успеха. Система может предоставлять возможности для объединения дальнейших изменений в центральный репозиторий и сохранения изменений первого разработчика при регистрации других разработчиков.
Объединение двух файлов может быть очень деликатной операцией и обычно возможно только в том случае, если структура данных проста, как в текстовых файлах . Результат объединения двух файлов изображений может вообще не привести к созданию файла изображения. Второй разработчик, проверяющий код, должен будет позаботиться о слиянии, чтобы убедиться, что изменения совместимы и что операция слияния не приводит к появлению собственных логических ошибок в файлах. Эти проблемы ограничивают доступность автоматических или полуавтоматических операций слияния в основном для простых текстовых документов, если только для этих типов файлов не доступен специальный плагин слияния.
Концепция зарезервированного редактирования может предоставить дополнительные средства явной блокировки файла для эксклюзивного доступа на запись, даже если существует возможность слияния.
Большинство инструментов контроля версий будут использовать только один из этих похожих терминов (базовый вариант, метка, тег) для обозначения действия по идентификации моментального снимка («пометить проект») или записи моментального снимка («попробуйте с базовым состоянием X » ). . Обычно в документации или обсуждении используется только один из терминов «базовый уровень» , «метка » или «тег» [ нужна ссылка ] ; их можно считать синонимами.
В большинстве проектов некоторые снимки более важны, чем другие, например те, которые используются для обозначения опубликованных выпусков, ветвей или вех.
Когда термин «базовый уровень » и «метка» или «тег» используются вместе в одном и том же контексте, « метка » и «тег» обычно относятся к механизму внутри инструмента идентификации или создания записи моментального снимка, а « базовый уровень» указывает на повышенную значимость любой данной метки. или тег.
В наиболее формальном обсуждении управления конфигурацией используется термин «базовый уровень» .
Распределенные системы контроля версий (DRCS) используют одноранговый подход, в отличие от клиент-серверного подхода централизованных систем. Вместо единого центрального репозитория, в котором синхронизируются клиенты, рабочая копия кодовой базы каждого узла является настоящим репозиторием. [12] Распределенный контроль версий осуществляет синхронизацию путем обмена исправлениями (наборами изменений) от однорангового узла к одноранговому. Это приводит к некоторым важным отличиям от централизованной системы:
Скорее, связь необходима только при отправке или получении изменений от других узлов.
Следование лучшим практикам необходимо для получения всех преимуществ контроля версий. Рекомендации могут различаться в зависимости от инструмента контроля версий и области, к которой применяется контроль версий. Общепринятые передовые методы разработки программного обеспечения включают: внесение дополнительных, небольших изменений; выполнение коммитов , которые включают только одну задачу или исправление — следствием этого является фиксация только кода, который работает и сознательно не нарушает существующую функциональность; использование ветвления для завершения функциональности перед выпуском; написание четких и описательных сообщений о коммитах, пояснение того, почему и насколько ясно в описании коммита или в коде; и использование последовательной стратегии ветвления. [13] Другие передовые методы разработки программного обеспечения, такие как проверка кода и автоматическое регрессионное тестирование, могут помочь в следовании лучшим практикам контроля версий.
Затраты и выгоды будут различаться в зависимости от выбранного инструмента контроля версий и области, в которой он применяется. Этот раздел посвящен области разработки программного обеспечения, где широко применяется контроль версий.
Помимо затрат на лицензирование программного обеспечения для контроля версий, использование контроля версий требует времени и усилий. Необходимо понять концепции, лежащие в основе контроля версий, и изучить технические детали, необходимые для работы выбранного программного обеспечения для контроля версий. Передовые методы контроля версий необходимо изучить и интегрировать в существующие в организации методы разработки программного обеспечения. Управленческим усилиям могут потребоваться усилия для поддержания дисциплины, необходимой для следования передовому опыту с целью получения полезной выгоды.
Основным преимуществом является возможность сохранять историю и откатывать изменения, что позволяет разработчику легко отменить изменения. Это дает разработчику больше возможностей для экспериментов, устраняя страх сломать существующий код. [14]
Ветвление помогает при развертывании. Разветвление и слияние, создание, упаковка и маркировка исправлений исходного кода , а также простое применение исправлений к базам кода упрощают обслуживание и параллельную разработку нескольких баз кода, связанных с различными этапами процесса развертывания; разработка, тестирование, постановка, производство и т.д. [15]
Могут быть смягчение ущерба, подотчетность, улучшение процессов и дизайна, а также другие преимущества, связанные с ведением учета, обеспечиваемым контролем версий, отслеживанием того, кто, что сделал, когда, почему и как. [16] Это может позволить лучше оценить, почему были внесены изменения, чтобы решить проблемы и найти решения в будущем. [17]
При возникновении ошибок знание того, что было сделано, помогает уменьшить ущерб и устранить его, помогая определить, какие проблемы существуют, как долго они существуют, а также определить масштаб проблемы и решения. [18] Предыдущие версии можно установить и протестировать для проверки выводов, сделанных в результате изучения кода и сообщений о фиксации. [19]
Контроль версий может значительно упростить отладку. Применение тестового примера к нескольким версиям позволяет быстро выявить изменение, вызвавшее ошибку. [20] Разработчику не обязательно знать всю кодовую базу, вместо этого он может сосредоточиться на коде, создавшем проблему.
Контроль версий улучшает совместную работу несколькими способами. Поскольку контроль версий может выявить конфликтующие изменения, то есть несовместимые изменения, внесенные в одни и те же строки кода, необходимость в координации между разработчиками снижается. [21]
Упаковка коммитов, ветвей и всех связанных с ними сообщений о коммитах и меток версий улучшает взаимодействие между разработчиками как в данный момент, так и с течением времени. [22] Улучшение коммуникации, мгновенной или отложенной, может улучшить процесс проверки кода, процесс тестирования и другие важные аспекты процесса разработки программного обеспечения.
Некоторые из более продвинутых инструментов контроля версий предлагают множество других возможностей, обеспечивающих более глубокую интеграцию с другими инструментами и процессами разработки программного обеспечения.
Плагины часто доступны для таких IDE , как Oracle JDeveloper , IntelliJ IDEA , Eclipse , Visual Studio , Delphi , NetBeans IDE , Xcode и GNU Emacs (через vc.el). Прототипы расширенных исследований генерируют соответствующие сообщения о фиксации. [23]
Терминология может варьироваться от системы к системе, но некоторые общепринятые термины включают: [24]
Утвержденная редакция документа или исходного файла, в которую могут быть внесены последующие изменения. См. базовые показатели, метки и теги.
Поиск автора и ревизии, последней изменившей конкретную строку.
Набор файлов, находящихся под контролем версий, может быть разветвлен или разветвлен в определенный момент времени, так что с этого момента две копии этих файлов могут развиваться с разной скоростью или разными способами независимо друг от друга.
Изменение (или diff , или delta ) представляет собой конкретную модификацию документа, находящегося под контролем версий. Степень детализации модификации, рассматриваемой как изменение, варьируется в зависимости от системы контроля версий.
Во многих системах контроля версий с атомарными фиксациями нескольких изменений список изменений (или CL ), набор изменений , обновление или патч идентифицируют набор изменений, внесенных в одну фиксацию. Это также может представлять собой последовательное представление исходного кода, позволяющее проверять источник по любому конкретному идентификатору списка изменений.
Выписать (или сотрудничать ) — значит создать локальную рабочую копию из репозитория. Пользователь может указать конкретную версию или получить последнюю версию. Термин «оформление заказа» также может использоваться как существительное для описания рабочей копии. Если файл извлечен с общего файлового сервера, другие пользователи не смогут его редактировать. Думайте об этом как об отеле: когда вы выезжаете из него, у вас больше нет доступа к его удобствам.
Клонирование означает создание репозитория, содержащего версии из другого репозитория. Это эквивалентно отправке или извлечению данных в пустой (только что инициализированный) репозиторий. Как существительное, два репозитория можно назвать клонами , если они синхронизированы и содержат одни и те же версии.
Коммит ( check in , ci или, реже, install , submit или Record ) означает запись или слияние изменений, внесенных в рабочую копию, обратно в репозиторий . Коммит содержит метаданные, обычно информацию об авторе и сообщение о коммите, описывающее изменение.
Короткая заметка, написанная разработчиком и хранящаяся вместе с коммитом, описывающая коммит. В идеале в нем фиксируется причина внесения изменения, описание эффекта или цели изменения, а также неочевидные аспекты того, как это изменение работает.
Конфликт возникает, когда разные стороны вносят изменения в один и тот же документ, и система не может согласовать эти изменения. Пользователь должен разрешить конфликт, объединив изменения или выбрав одно изменение в пользу другого.
Большинство программ контроля версий использует дельта-сжатие , при котором сохраняются только различия между последовательными версиями файлов. Это позволяет более эффективно хранить множество различных версий файлов.
Поток, в котором некоторые или все версии файлов являются зеркалами версий родительского потока.
Экспорт — это получение файлов из репозитория. Это похоже на извлечение, за исключением того, что оно создает чистое дерево каталогов без метаданных контроля версий, используемых в рабочей копии. Это часто используется, например, перед публикацией содержимого.
Смотрите тянуть .
Процесс объединения изменений, внесенных в основную ветку , в ветку разработки (функцию или команду).
Также иногда называется подсказкой . Это относится к самому последнему коммиту, либо в ствол, либо в ветку. Ствол и каждая ветвь имеют свою собственную голову, хотя HEAD иногда широко используется для обозначения ствола. [30]
Импорт — это первое копирование дерева локальных каталогов (которое в настоящее время не является рабочей копией) в репозиторий.
Чтобы создать новый пустой репозиторий.
Некоторые программы контроля версий используют чередующиеся дельты — метод, который позволяет хранить историю текстовых файлов более эффективным способом, чем использование дельта-сжатия .
Смотрите тег .
Когда разработчик блокирует файл, никто другой не сможет обновить этот файл, пока он не будет разблокирован. Блокировка может поддерживаться системой контроля версий или посредством неформального общения между разработчиками (так называемая социальная блокировка ).
Аналогично «транку» , но для каждой ветки может быть магистральная линия.
Слияние или интеграция — это операция , при которой к файлу или набору файлов применяются два набора изменений. Вот некоторые примеры сценариев:
Копирование содержимого файла из менее контролируемого места в более контролируемое. Например, из рабочей области пользователя в репозиторий или из потока в его родительский элемент. [32]
Копирование ревизий из одного репозитория в другой. Pull инициируется принимающим репозиторием, а push инициируется источником. Fetch иногда используется как синоним слова pull или для обозначения извлечения , за которым следует обновление .
Вклад в репозиторий исходного кода, использующий распределенную систему контроля версий, обычно осуществляется с помощью запроса на включение, также известного как запрос на слияние. [33] Участник просит сопровождающего проекта внести изменения в исходный код, отсюда и название «запрос на включение». Мейнтейнер должен объединить запрос на включение, если вклад должен стать частью исходной базы. [34]
Разработчик создает запрос на включение, чтобы уведомить сопровождающих о новом изменении; поток комментариев связан с каждым запросом на включение. Это позволяет целенаправленно обсуждать изменения кода . Отправленные запросы на включение видны всем, у кого есть доступ к репозиторию. Запрос на включение может быть принят или отклонен сопровождающими. [35]
После того как запрос на извлечение проверен и одобрен, он добавляется в репозиторий. В зависимости от установленного рабочего процесса, возможно, потребуется протестировать код перед включением в официальный выпуск. Поэтому некоторые проекты содержат специальную ветку для объединения непроверенных пул-реквестов. [34] [36] Другие проекты запускают автоматизированный набор тестов при каждом запросе на включение с использованием инструмента непрерывной интеграции , и рецензент проверяет, имеет ли любой новый код соответствующее тестовое покрытие.Вмешательство пользователя для устранения конфликта между различными изменениями в одном и том же документе.
Процесс объединения различных ветвей команды в основную магистраль системы управления версиями.
Версия — это любое изменение формы. В SVK ревизия — это состояние всего дерева в репозитории на определенный момент времени.
Действие по обеспечению доступа к одному файлу или папке в нескольких ветках одновременно. Когда общий файл изменяется в одной ветке, он изменяется и в других ветках.
Контейнер для разветвленных файлов, имеющий известное отношение к другим таким контейнерам. Потоки образуют иерархию; каждый поток может наследовать различные свойства (например, версии, пространство имен, правила рабочего процесса, подписчиков и т. д.) от своего родительского потока.
Тег или метка относится к важному снимку во времени, единообразному для многих файлов . На этом этапе все эти файлы могут быть помечены понятным для пользователя понятным именем или номером версии. См. базовые показатели, метки и теги.
Магистральная линия — это уникальная линия разработки, которая не является ветвью (иногда ее также называют базовой, основной или главной [39] [40] ).
Обновление (или синхронизация , но синхронизация также может означать комбинированное извлечение и извлечение ) объединяет изменения, сделанные в репозитории (например, другими людьми), в локальную рабочую копию . Обновление — это также термин, используемый некоторыми инструментами CM (CM+, PLS, SMS) для концепции пакета изменений (см. список изменений ). Синоним извлечения в системах контроля версий, которые требуют, чтобы в каждом репозитории была ровно одна рабочая копия (обычно в распределенных системах).
Снятие блокировки.
Рабочая копия — это локальная копия файлов из репозитория, созданная в определенное время или в определенной редакции. Вся работа с файлами в репозитории изначально выполняется в рабочей копии, отсюда и название. Концептуально это песочница .
С точки зрения человеко-часов это будет стоить вам в 6–48 раз больше, чем если бы вы использовали контроль версий, и это за перемотку пары моделей для одного разработчика.
Системы контроля версий позволяют сравнивать файлы, выявлять различия и при необходимости объединять изменения перед фиксацией какого-либо кода. Управление версиями также является отличным способом отслеживать сборки приложений, позволяя определить, какая версия в настоящее время находится в разработке, тестировании и производстве.
История документа предоставляет бесценную информацию об авторе и дате редактирования. Также указывается цель внесенных изменений. Это окажет влияние на разработчика, работающего над последней версией, поскольку поможет решить проблемы, возникшие в более ранних версиях. Возможность идентифицировать автора документа позволяет текущей команде связать документы с конкретными участниками. Это, в свою очередь, позволяет нынешней команде выявлять закономерности, которые могут помочь в исправлении ошибок. Это поможет улучшить общую функциональность программного обеспечения.
Более того, если с течением времени добавление определенной функции вызывает трудности с расширением или расширением проекта, использование контроля версий позволяет разработчикам отслеживать эту конкретную функцию и изменять ее или удалять, не влияя на функциональность проекта.
Команды разработчиков программного обеспечения могут понять эволюцию решения, исследуя предыдущие версии посредством проверок кода.
Если допущена ошибка, разработчики могут вернуться в прошлое и просмотреть предыдущие итерации кода, чтобы исправить ошибку, сводя к минимуму беспокойство для всех членов команды.
Инструмент git bisect — невероятно полезный инструмент отладки, используемый для определения того, какой конкретный коммит был первым, в котором возникла ошибка или проблема, путем автоматического двоичного поиска.
Управление версиями — бесценный процесс, особенно если над одним приложением работают несколько разработчиков, поскольку он позволяет им легко обмениваться файлами. Без контроля версий разработчики в конечном итоге будут наступать друг другу на ногу и перезаписывать изменения кода, которые кто-то другой мог выполнить, даже не осознавая этого. Использование этих систем позволяет вам проверять файлы на наличие изменений, а затем, во время регистрации, если файлы были изменены другим пользователем, вы получите предупреждение и сможете объединить их.
Продолжаются дискуссии об использовании перебазирования, слияния и/или сжатия. Я хочу сосредоточить внимание на всем этом выборе — общении.