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

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

20 мин чтения

100%

Источник: Version control — Wikipedia

Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.

Содержание

Введение

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

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

Обзор

Когда команды разрабатывают программное обеспечение, часто бывает, что несколько версий одного и того же ПО развёрнуты на разных площадках, а разработчики одновременно работают над обновлениями. Ошибки или функциональные возможности ПО часто присутствуют только в определённых версиях (из-за исправления одних проблем и появления других в процессе разработки). Поэтому, для обнаружения и исправления ошибок, крайне важно иметь возможность извлекать и запускать различные версии ПО, чтобы определить, в какой (каких) из них возникает проблема. Также может потребоваться параллельная разработка двух версий ПО: например, одна версия содержит исправления ошибок, но не включает новые функции (ветка), а в другой версии ведётся работа над новыми функциями (основная ветка). В простейшем случае разработчики могут просто хранить несколько копий различных версий программы и соответствующим образом их маркировать. Этот простой подход использовался во многих крупных программных проектах. Хотя этот метод может работать, он неэффективен, так как необходимо поддерживать множество почти идентичных копий программы. Это требует от разработчиков высокой самодисциплины и часто приводит к ошибкам. Поскольку кодовая база одна и та же, требуется предоставление прав на чтение, запись и выполнение набору разработчиков, что создаёт дополнительную нагрузку на тех, кто управляет этими правами, чтобы кодовая база не была скомпрометирована, что усложняет процесс. В результате были разработаны системы для автоматизации части или всего процесса контроля версий. Это обеспечивает скрытие большей части управления этапами контроля версий от пользователя. Более того, в разработке программного обеспечения, юридической и деловой практике, а также в других областях, всё чаще встречается ситуация, когда один документ или фрагмент кода редактируется командой, члены которой могут быть географически распределены и преследовать различные, и даже противоречивые, цели. В таких ситуациях сложный контроль версий, отслеживающий и учитывающий авторство изменений в документах и коде, может оказаться чрезвычайно полезным или даже незаменимым. Контроль версий также может отслеживать изменения в файлах конфигурации, например, тех, которые обычно хранятся в /etc или /usr/local/etc в системах Unix. Это даёт системным администраторам дополнительный способ легко отслеживать внесённые изменения и возможность вернуться к более ранним версиям при необходимости. Многие системы контроля версий идентифицируют версию файла числом или буквой, называемым номером версии, версией, номером ревизии, ревизией или уровнем ревизии. Например, первая версия файла может быть версией 1. При изменении файла следующей версией будет 2. Каждая версия связана с временной меткой и пользователем, внесшим изменения. Ревизии можно сравнивать, восстанавливать и, для некоторых типов файлов, объединять.

As teams develop software, it is common for multiple versions of the same software to be deployed in different sites and for the developers to work simultaneously on updates. Bugs or features of the software are often only present in certain versions (because of the fixing of some problems and the introduction of others as the program develops). Therefore, for the purposes of locating and fixing bugs, it is vitally important to be able to retrieve and run different versions of the software to determine in which version(s) the problem occurs. It may also be necessary to develop two versions of the software concurrently: for instance, where one version has bugs fixed, but no new features (branch), while the other version is where new features are worked on (trunk). At the simplest level, developers could simply retain multiple copies of the different versions of the program, and label them appropriately. This simple approach has been used in many large software projects. While this method can work, it is inefficient as many near identical copies of the program have to be maintained. This requires a lot of self discipline on the part of developers and often leads to mistakes. Since the code base is the same, it also requires granting read write execute permission to a set of developers, and this adds the pressure of someone managing permissions so that the code base is not compromised, which adds more complexity. Consequently, systems to automate some or all of the revision control process have been developed. This ensures that the majority of management of version control steps is hidden behind the scenes. Moreover, in software development, legal and business practice, and other environments, it has become increasingly common for a single document or snippet of code to be edited by a team, the members of which may be geographically dispersed and may pursue different and even contrary interests. Sophisticated revision control that tracks and accounts for ownership of changes to documents and code may be extremely helpful or even indispensable in such situations. Revision control may also track changes to configuration files, such as those typically stored in /etc or /usr/local/etc on Unix systems. This gives system administrators another way to easily track changes made and a way to roll back to earlier versions should the need arise. Many version control systems identify the version of a file as a number or letter, called the version number, version, revision number, revision, or revision level. For example, the first version of a file might be version 1. When the file is changed the next version is 2. Each version is associated with a timestamp and the person making the change. Revisions can be compared, restored, and, with some types of files, merged.

История

Инструмент обновления программного обеспечения IBM OS/360 IEBUPDTE датируется 1962 годом и, возможно, является предшественником инструментов систем контроля версий. Два пакета для управления исходным кодом и контроля версий, которые широко использовались в установках IBM 360/370, – The Librarian и Panvalet. В 1972 году была разработана полноценная система контроля исходного кода для той же системы (OS/360), получившая название Source Code Control System. Публикация информации о Source Code Control System 4 декабря 1975 года исторически считается моментом появления первой целенаправленной системы контроля версий. За RCS последовала сетевая версия Concurrent Versions System. Следующее поколение систем контроля версий было представлено Subversion, а затем произошел расцвет распределенных систем контроля версий, таких как Git.

Структура

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

Revision control manages changes to a set of data over time. These changes can be structured in various ways. Often the data is thought of as a collection of many individual items, such as files or documents, and changes to individual files are tracked. This accords with intuitions about separate files but causes problems when identity changes, such as during renaming, splitting or merging of files. Accordingly, some systems such as Git, instead consider changes to the data as a whole, which is less intuitive for simple changes but simplifies more complex changes. When data that is under revision control is modified, after being retrieved by checking out, this is not in general immediately reflected in the revision control system (in the repository), but must instead be checked in or committed. A copy outside revision control is known as a "working copy". As a simple example, when editing a computer file, the data stored in memory by the editing program is the working copy, which is committed by saving. Concretely, one may print out a document, edit it by hand, and only later manually input the changes into a computer and save it. For source code control, the working copy is instead a copy of all files in a particular revision, generally stored locally on the developer's computer; in this case saving the file only changes the working copy, and checking into the repository is a separate step. If multiple people are working on a single data set or document, they are implicitly creating branches of the data (in their working copies), and thus issues of merging arise, as discussed below. For simple collaborative document editing, this can be prevented by using file locking or simply avoiding working on the same document that someone else is working on. Revision control systems are often centralized, with a single authoritative data store, the repository, and check outs and check ins done with reference to this central repository. Alternatively, in distributed revision control, no single repository is authoritative, and data can be checked out and checked into any repository. When checking into a different repository, this is interpreted as a merge or patch.

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

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

In terms of graph theory, revisions are generally thought of as a line of development (the trunk) with branches off of this, forming a directed tree, visualized as one or more parallel lines of development (the "mainlines" of the branches) branching off a trunk. In reality the structure is more complicated, forming a directed acyclic graph, but for many purposes "tree with merges" is an adequate approximation. Revisions occur in sequence over time, and thus can be arranged in order, either by revision number or timestamp. Revisions are based on past revisions, though it is possible to largely or completely replace an earlier revision, such as "delete all existing text, insert new text". In the simplest case, with no branching or undoing, each revision is based on its immediate predecessor alone, and they form a simple line, with a single latest version, the "HEAD" revision or tip. In graph theory terms, drawing each revision as a point and each "derived revision" relationship as an arrow (conventionally pointing from older to newer, in the same direction as time), this is a linear graph. If there is branching, so multiple future revisions are based on a past revision, or undoing, so a revision can depend on a revision older than its immediate predecessor, then the resulting graph is instead a directed tree (each node can have more than one child), and has multiple tips, corresponding to the revisions without children ("latest revision on each branch"). In principle the resulting tree need not have a preferred tip ("main" latest revision) – just various different revisions – but in practice one tip is generally identified as HEAD. When a new revision is based on HEAD, it is either identified as the new HEAD, or considered a new branch. The list of revisions from the start to HEAD (in graph theory terms, the unique path in the tree, which forms a linear graph as before) is the trunk or mainline. Conversely, when a revision can be based on more than one previous revision (when a node can have more than one parent), the resulting process is called a merge, and is one of the most complex aspects of revision control. This most often occurs when changes occur in multiple branches (most often two, but more are possible), which are then merged into a single branch incorporating both changes. If these changes overlap, it may be difficult or impossible to merge, and require manual intervention or rewriting. In the presence of merges, the resulting graph is no longer a tree, as nodes can have multiple parents, but is instead a rooted directed acyclic graph (DAG). The graph is acyclic since parents are always backwards in time, and rooted because there is an oldest version. Assuming there is a trunk, merges from branches can be considered as "external" to the tree – the changes in the branch are packaged up as a patch, which is applied to HEAD (of the trunk), creating a new revision without any explicit reference to the branch, and preserving the tree structure. Thus, while the actual relations between versions form a DAG, this can be considered a tree plus merges, and the trunk itself is a line. In distributed revision control, in the presence of multiple repositories these may be based on a single original version (a root of the tree), but there need not be an original root instead there can be a separate root (oldest revision) for each repository. This can happen, for example, if two people start working on a project separately. Similarly, in the presence of multiple data sets (multiple projects) that exchange data or merge, there is no single root, though for simplicity one may think of one project as primary and the other as secondary, merged into the first with or without its own revision history.

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

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

В бизнесе и в юриспруденции

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

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

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

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

Операция считается атомарной, если система остаётся в согласованном состоянии, даже если операция прервана. Операция коммита обычно является наиболее критичной в этом отношении. Коммиты сообщают системе контроля версий о необходимости сделать группу изменений окончательной и доступной для всех пользователей. Не все системы контроля версий поддерживают атомарные коммиты; Concurrent Versions System (CVS) лишена этой возможности.

Замкнутость файла

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

Слияние версий

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

Базовые значения, этикетки и метки

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

Распределенный контроль за пересмотром

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

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

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

Расходы

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

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

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

Расширение подразделений упрощает развертывание, обслуживание и разработку

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

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

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

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

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

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

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

Интеграция

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

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

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

Исходные данные

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

Вина

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

Отрасль

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

Изменение

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

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

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

Выход

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

Клон

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

Обязательность (глаголь)

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

Сообщение о сдаче

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

Конфликт

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

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

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

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

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

Экспорт

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

Принеси .

Потяните.

Продвигающаяся интеграция

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

Голова

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

Импорт

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

Инициализация

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

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

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

Наклейка

Смотрите этикетку.

Закрытие

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

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

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

Слияние

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

Продвигать

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

Нажимаем, толкаем.

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

Решить

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

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

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

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

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

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

Поток

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

Назначение

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

Обновление

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

Отключение

Освобождаю блокировку.

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

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