Управление версиями (также известное как управление ревизиями , управление исходным кодом и управление исходным кодом ) — это практика разработки программного обеспечения, направленная на контроль, организацию и отслеживание различных версий в истории компьютерных файлов ; в первую очередь текстовых файлов исходного кода , но в целом и файлов любого типа.
Контроль версий является компонентом управления конфигурацией программного обеспечения . [1]
Система контроля версий — это программный инструмент , который автоматизирует контроль версий. Кроме того, контроль версий встроен в качестве функции некоторых систем, таких как текстовые процессоры , электронные таблицы , совместные веб-документы , [2] и системы управления контентом , например, история страниц Википедии .
Контроль версий включает просмотр старых версий и позволяет вернуть файл к предыдущей версии.
Поскольку команды разрабатывают программное обеспечение, часто бывает так, что несколько версий одного и того же программного обеспечения развертываются на разных сайтах, а разработчики одновременно работают над обновлениями. Ошибки или функции программного обеспечения часто присутствуют только в определенных версиях (из-за исправления некоторых проблем и появления других по мере разработки программы). Поэтому для целей поиска и исправления ошибок жизненно важно иметь возможность извлекать и запускать разные версии программного обеспечения, чтобы определить, в какой версии(ях) возникает проблема. Также может потребоваться разрабатывать две версии программного обеспечения одновременно: например, когда в одной версии исправлены ошибки, но нет новых функций ( branch ), а в другой версии разрабатываются новые функции ( trunk ).
На самом простом уровне разработчики могли бы просто сохранить несколько копий разных версий программы и соответствующим образом их пометить. Этот простой подход использовался во многих крупных программных проектах. Хотя этот метод может работать, он неэффективен, поскольку необходимо поддерживать много почти идентичных копий программы. Это требует большой самодисциплины со стороны разработчиков и часто приводит к ошибкам. Поскольку кодовая база одинакова, это также требует предоставления разрешений на чтение-запись-выполнение группе разработчиков, и это добавляет давления со стороны кого-то, управляющего разрешениями, чтобы кодовая база не была скомпрометирована, что добавляет еще больше сложности. Следовательно, были разработаны системы для автоматизации некоторых или всех процессов контроля версий. Это гарантирует, что большинство этапов управления версиями будут скрыты за кулисами.
Более того, в разработке программного обеспечения, юридической и деловой практике и других средах все чаще встречается ситуация, когда один документ или фрагмент кода редактируется командой, члены которой могут быть географически разбросаны и могут преследовать разные и даже противоположные интересы. Сложный контроль версий, который отслеживает и учитывает право собственности на изменения в документах и коде, может быть чрезвычайно полезным или даже незаменимым в таких ситуациях.
Контроль версий может также отслеживать изменения в файлах конфигурации , например, тех, которые обычно хранятся в /etcсистемах Unix/usr/local/etc . Это дает системным администраторам еще один способ легко отслеживать внесенные изменения и способ отката к более ранним версиям, если возникнет такая необходимость.
Многие системы контроля версий идентифицируют версию файла как число или букву, называемую номером версии , версией , номером ревизии , ревизией или уровнем ревизии . Например, первая версия файла может быть версией 1. Когда файл изменяется, следующая версия — 2. Каждая версия связана с меткой времени и лицом, внесшим изменение. Ревизии можно сравнивать, восстанавливать и, для некоторых типов файлов, объединять. [3]
Инструмент обновления программного обеспечения OS/360 IEBUPDTE от IBM появился в 1962 году, возможно, он был предшественником инструментов системы контроля версий. Два пакета управления исходным кодом и контроля версий, которые активно использовались в установках IBM 360/370, были The Librarian и Panvalet . [4] [5]
Полная система, разработанная для управления исходным кодом, была запущена в 1972 году, Source Code Control System для той же системы (OS/360). Введение Source Code Control System, опубликованное 4 декабря 1975 года, исторически подразумевало, что это была первая преднамеренная система управления версиями. [6] RCS последовала сразу после, [7] с ее сетевой версией Concurrent Versions System . Следующее поколение после Concurrent Versions System было во власти Subversion , [8] за которым последовал рост распределенных инструментов управления версиями, таких как Git . [9]
Контроль версий управляет изменениями в наборе данных с течением времени. Эти изменения могут быть структурированы различными способами.
Часто данные рассматриваются как набор многих отдельных элементов, таких как файлы или документы, и изменения в отдельных файлах отслеживаются. Это соответствует интуиции об отдельных файлах, но вызывает проблемы при изменении идентичности, например, при переименовании, разделении или слиянии файлов. Соответственно, некоторые системы, такие как Git , вместо этого рассматривают изменения в данных как единое целое, что менее интуитивно для простых изменений, но упрощает более сложные изменения.
Когда данные, находящиеся под контролем ревизий, изменяются после извлечения путем выписки, это, как правило, не отражается немедленно в системе контроля ревизий (в репозитории ), а должно быть вместо этого зафиксировано или зафиксировано. Копия вне контроля ревизий известна как «рабочая копия». В качестве простого примера, при редактировании компьютерного файла данные, хранящиеся в памяти программой редактирования, являются рабочей копией, которая фиксируется путем сохранения. Конкретно, можно распечатать документ, отредактировать его вручную и только позже вручную ввести изменения в компьютер и сохранить его. Для контроля исходного кода рабочая копия вместо этого является копией всех файлов в определенной ревизии, обычно хранящейся локально на компьютере разработчика; [примечание 1] в этом случае сохранение файла изменяет только рабочую копию, а регистрация в репозитории является отдельным шагом.
Если несколько человек работают над одним набором данных или документом, они неявно создают ветви данных (в своих рабочих копиях), и, таким образом, возникают проблемы слияния, как обсуждается ниже. Для простого совместного редактирования документов это можно предотвратить, используя блокировку файлов или просто избегая работы над тем же документом, над которым работает кто-то другой.
Системы контроля версий часто централизованы, с одним авторитетным хранилищем данных, репозиторием, и проверками и проверками, выполняемыми со ссылкой на этот центральный репозиторий. В качестве альтернативы, в распределенном контроле версий ни один репозиторий не является авторитетным, и данные могут быть проверены и проверены в любом репозитории. При проверке в другом репозитории это интерпретируется как слияние или исправление.
В терминах теории графов , ревизии обычно рассматриваются как линия развития ( ствол ) с ответвлениями от него, образуя направленное дерево, визуализируемое как одна или несколько параллельных линий развития («главные линии» ветвей), ответвляющихся от ствола. В действительности структура более сложная, образуя направленный ациклический граф , но для многих целей «дерево со слияниями» является адекватным приближением.
Ревизии происходят последовательно с течением времени и, таким образом, могут быть упорядочены либо по номеру ревизии, либо по временной метке. [примечание 2] Ревизии основаны на прошлых ревизиях, хотя возможно в значительной степени или полностью заменить более раннюю ревизию, например, «удалить весь существующий текст, вставить новый текст». В простейшем случае, без ветвления или отмены, каждая ревизия основана только на своей непосредственной предшественнице, и они образуют простую линию с единственной последней версией, ревизией «HEAD» или кончиком . В терминах теории графов , рисуя каждую ревизию как точку, а каждую связь «производной ревизии» как стрелку (условно указывающую от старой к новой в том же направлении, что и время), это линейный граф . Если есть ветвление, так что несколько будущих ревизий основаны на прошлой ревизии, или отмена, так что ревизия может зависеть от ревизии, более старой, чем ее непосредственный предшественник, то результирующий граф вместо этого является направленным деревом (каждый узел может иметь более одного потомка), и имеет несколько кончиков, соответствующих ревизиям без потомков («последняя ревизия на каждой ветви»). [примечание 3] В принципе, результирующее дерево не должно иметь предпочтительного кончика («главная» последняя ревизия) — просто различные разные ревизии — но на практике один кончик обычно идентифицируется как HEAD. Когда новая ревизия основана на HEAD, она либо идентифицируется как новый HEAD, либо считается новой ветвью. [примечание 4] Список ревизий от начала до HEAD (в терминах теории графов, уникальный путь в дереве, который образует линейный граф, как и раньше) является стволом или основной линией. [примечание 5] И наоборот, когда ревизия может быть основана более чем на одной предыдущей ревизии (когда узел может иметь более одного родителя ), результирующий процесс называется слиянием и является одним из самых сложных аспектов контроля ревизий. Чаще всего это происходит, когда изменения происходят в нескольких ветвях (чаще всего в двух, но возможно и больше), которые затем объединяются в одну ветвь, включающую оба изменения. Если эти изменения перекрываются, объединение может быть сложным или невозможным и потребует ручного вмешательства или переписывания.
При наличии слияний результирующий граф больше не является деревом, так как узлы могут иметь несколько родителей, а вместо этого является направленным ациклическим графом с корнем (DAG). Граф ацикличен, так как родители всегда находятся в обратном направлении во времени, и имеет корень, так как есть самая старая версия. Предполагая, что есть ствол, слияния из ветвей можно считать «внешними» по отношению к дереву — изменения в ветви упаковываются как патч , который применяется к HEAD (ствола), создавая новую ревизию без какой-либо явной ссылки на ветвь и сохраняя структуру дерева. Таким образом, в то время как фактические отношения между версиями образуют DAG, это можно считать деревом плюс слияния, а сам ствол — линией.
В распределенном контроле версий при наличии нескольких репозиториев они могут быть основаны на одной исходной версии (корень дерева), но исходный корень не обязательно должен быть — вместо этого может быть отдельный корень (самая старая ревизия) для каждого репозитория. Это может произойти, например, если два человека начинают работать над проектом по отдельности. Аналогично, при наличии нескольких наборов данных (нескольких проектов), которые обмениваются данными или объединяются, нет единого корня, хотя для простоты можно считать один проект первичным, а другой — вторичным, объединенным в первый с собственной историей ревизий или без нее.
Контроль инженерных изменений развился из формализованных процессов, основанных на отслеживании изменений ранних чертежей или чертежей [ требуется ссылка ] . Эта система контроля неявно позволяла вернуться к более раннему состоянию проекта в случаях, когда при разработке проекта наступал инженерный тупик. Для отслеживания внесенных изменений использовалась таблица изменений. Кроме того, измененные области чертежа были выделены с помощью облаков изменений.
Контроль версий широко распространен в бизнесе и юриспруденции. Действительно, «контрактная красная линия» и «юридическая черная линия» являются одними из самых ранних форм контроля версий, [10] и все еще используются в бизнесе и юриспруденции с различной степенью сложности. Самые сложные методы начинают использоваться для электронного отслеживания изменений в файлах САПР (см. управление данными о продукте ), вытесняя «ручную» электронную реализацию традиционного контроля версий. [ необходима цитата ]
Традиционные системы контроля версий используют централизованную модель, где все функции контроля версий выполняются на общем сервере . Если два разработчика попытаются изменить один и тот же файл одновременно, без какого-либо метода управления доступом разработчики могут в конечном итоге перезаписать работу друг друга. Централизованные системы контроля версий решают эту проблему с помощью одной из двух различных «моделей управления исходным кодом»: блокировка файлов и слияние версий.
Операция является атомарной , если система остается в согласованном состоянии, даже если операция прерывается. Операция фиксации обычно является наиболее критической в этом смысле. Фиксации сообщают системе контроля версий о необходимости сделать группу изменений окончательной и доступной всем пользователям. Не все системы контроля версий имеют атомарные фиксации; в Concurrent Versions System эта функция отсутствует. [11]
Самый простой метод предотвращения проблем " конкурентного доступа " заключается в блокировке файлов , так что только один разработчик в каждый момент времени имеет право записи в центральные " репозиторные " копии этих файлов. Как только один разработчик "выписывает" файл, другие могут читать этот файл, но никто другой не может изменить этот файл, пока этот разработчик "выписывает" обновленную версию (или не отменяет выписку).
Блокировка файлов имеет как достоинства, так и недостатки. Она может обеспечить некоторую защиту от сложных конфликтов слияния, когда пользователь вносит радикальные изменения во многие разделы большого файла (или группы файлов). Если файлы остаются исключительно заблокированными слишком долго, другие разработчики могут поддаться искушению обойти программное обеспечение контроля версий и изменить файлы локально, вынуждая выполнять сложное ручное слияние, когда другие изменения наконец будут зарегистрированы. В большой организации файлы могут оставаться «извлеченными» и заблокированными и забытыми, когда разработчики перемещаются между проектами — эти инструменты могут или не могут облегчить просмотр того, кто извлек файл.
Большинство систем контроля версий позволяют нескольким разработчикам редактировать один и тот же файл одновременно. Первый разработчик, который "зарегистрирует" изменения в центральном репозитории, всегда добивается успеха. Система может предоставлять возможности для объединения дальнейших изменений в центральном репозитории и сохранения изменений от первого разработчика, когда другие разработчики регистрируют изменения.
Объединение двух файлов может быть очень деликатной операцией и обычно возможно только в том случае, если структура данных проста, как в текстовых файлах . Результат объединения двух файлов изображений может вообще не привести к созданию файла изображения. Второму разработчику, проверяющему код, необходимо будет позаботиться о слиянии, чтобы убедиться, что изменения совместимы и что операция слияния не вносит собственных логических ошибок в файлы. Эти проблемы ограничивают доступность автоматических или полуавтоматических операций слияния в основном для простых текстовых документов, если только для типов файлов не доступен специальный плагин слияния.
Концепция зарезервированного редактирования может предоставить дополнительный способ явно заблокировать файл для исключительного доступа на запись, даже если существует возможность слияния.
Большинство инструментов контроля версий будут использовать только один из этих похожих терминов (базовая линия, метка, тег) для обозначения действия по идентификации снимка («пометить проект») или записи снимка («попробуйте с базовой линией X »). Обычно в документации или обсуждении используется только один из терминов базовая линия , метка или тег [ требуется ссылка ] ; их можно считать синонимами.
В большинстве проектов некоторые моментальные снимки более значимы, чем другие, например те, которые используются для обозначения опубликованных релизов, ветвей или этапов.
Когда термин «базовый уровень» и термин «метка» или «тег» используются вместе в одном контексте, метка и тег обычно относятся к механизму внутри инструмента идентификации или создания записи моментального снимка, а базовый уровень указывает на возросшую значимость любой данной метки или тега.
В большинстве официальных обсуждений управления конфигурацией используется термин «базовый уровень» .
Распределенные системы контроля версий (DRCS) используют подход «равный-равному», в отличие от подхода «клиент-сервер» централизованных систем. Вместо единого центрального репозитория, на котором синхронизируются клиенты, рабочая копия кодовой базы каждого однорангового узла является добросовестным репозиторием. [12] Распределенный контроль версий проводит синхронизацию путем обмена исправлениями (наборами изменений) от однорангового узла к одноранговому узлу. Это приводит к некоторым важным отличиям от централизованной системы:
Скорее, общение необходимо только при передаче или получении изменений от других участников.
Чтобы получить все преимущества от контроля версий, необходимо следовать лучшим практикам. Лучшие практики могут различаться в зависимости от инструмента контроля версий и области, к которой применяется контроль версий. Общепринятые лучшие практики в разработке программного обеспечения включают: внесение постепенных, небольших изменений; внесение коммитов , которые включают только одну задачу или исправление — следствием этого является внесение только кода, который работает и заведомо не нарушает существующую функциональность; использование ветвления для завершения функциональности перед выпуском; написание четких и описательных сообщений о коммитах, четкое указание того, что, почему и как, либо в описании коммита, либо в коде; и использование последовательной стратегии ветвления. [13] Другие лучшие практики разработки программного обеспечения, такие как обзор кода и автоматизированное регрессионное тестирование, могут помочь в следовании лучшим практикам контроля версий.
Затраты и выгоды будут варьироваться в зависимости от выбранного инструмента контроля версий и области, в которой он применяется. В этом разделе речь идет о сфере разработки программного обеспечения, где контроль версий широко применяется.
Помимо расходов на лицензирование программного обеспечения для контроля версий, использование контроля версий требует времени и усилий. Необходимо понимать концепции, лежащие в основе контроля версий, и изучать технические детали, необходимые для работы выбранного программного обеспечения для контроля версий. Необходимо изучать передовые практики контроля версий и интегрировать их в существующие практики разработки программного обеспечения организации. Могут потребоваться усилия руководства для поддержания дисциплины, необходимой для следования передовым практикам с целью получения полезной выгоды.
Основным преимуществом является возможность сохранять историю и отменять изменения, что позволяет разработчику легко отменять изменения. Это дает разработчику больше возможностей для экспериментов, устраняя страх сломать существующий код. [14]
Ветвление помогает развертыванию. Ветвление и слияние, производство, упаковка и маркировка патчей исходного кода и простое применение патчей к кодовым базам упрощают обслуживание и параллельную разработку нескольких кодовых баз, связанных с различными этапами процесса развертывания: разработка, тестирование, подготовка, производство и т. д. [15]
Ведение записей, обеспечиваемое контролем версий, отслеживание того, кто что сделал, когда, почему и как, может способствовать уменьшению ущерба, повышению ответственности, улучшению процессов и дизайна, а также другим преимуществам. [16]
При возникновении ошибок знание того, что было сделано и когда, помогает смягчить ущерб и восстановиться, помогая определить, какие проблемы существуют, как долго они существуют, а также определить масштаб проблемы и ее решения. [17] Можно установить и протестировать предыдущие версии, чтобы проверить выводы, сделанные путем изучения кода и сообщений о коммитах. [18]
Контроль версий может значительно упростить отладку. Применение тестового случая к нескольким версиям может быстро определить изменение, которое привело к ошибке. [19] Разработчику не нужно знать всю кодовую базу, и он может сосредоточиться на коде, который привел к проблеме.
Контроль версий улучшает сотрудничество несколькими способами. Поскольку контроль версий может определять конфликтующие изменения, т. е. несовместимые изменения, внесенные в одни и те же строки кода, потребность в координации между разработчиками снижается. [20]
Упаковка коммитов, ветвей и всех связанных сообщений коммитов и меток версий улучшает коммуникацию между разработчиками как в данный момент, так и с течением времени. [21] Лучшая коммуникация, мгновенная или отложенная, может улучшить процесс проверки кода, процесс тестирования и другие критические аспекты процесса разработки программного обеспечения.
Некоторые из наиболее продвинутых инструментов контроля версий предлагают множество других возможностей, обеспечивающих более глубокую интеграцию с другими инструментами и процессами разработки программного обеспечения.
Плагины часто доступны для таких IDE , как Oracle JDeveloper , IntelliJ IDEA , Eclipse , Visual Studio , Delphi , NetBeans IDE , Xcode и GNU Emacs (через vc.el). Продвинутые исследовательские прототипы генерируют соответствующие сообщения о коммите. [22]
Терминология может различаться в зависимости от системы, но вот некоторые общепринятые термины: [23]
Одобренная редакция документа или исходного файла, в которую могут быть внесены последующие изменения. См. базовые линии, метки и теги.
Поиск автора и редакции, которая в последний раз изменяла конкретную строку.
Набор файлов, находящихся под контролем версий, может быть разветвлен или форкнут в определенный момент времени, так что с этого момента две копии этих файлов могут развиваться с разной скоростью или разными способами независимо друг от друга.
Изменение (или diff , или delta ) представляет собой определенную модификацию документа под контролем версий. Степень детализации модификации, рассматриваемой как изменение, различается в разных системах контроля версий .
Во многих системах контроля версий с атомарными многократными коммитами изменений список изменений (или CL ), набор изменений , обновление или патч идентифицируют набор изменений, внесенных в одном коммите. Это также может представлять собой последовательное представление исходного кода, позволяя изучать исходный код по любому конкретному идентификатору списка изменений.
Извлечь (или co ) означает создать локальную рабочую копию из репозитория. Пользователь может указать конкретную ревизию или получить последнюю. Термин «извлечь» также может использоваться как существительное для описания рабочей копии. Когда файл был извлечен с общего файлового сервера, его не могут редактировать другие пользователи. Представьте себе отель: когда вы выезжаете, у вас больше нет доступа к его удобствам.
Клонирование означает создание репозитория, содержащего ревизии из другого репозитория. Это эквивалентно push или pull в пустой (ново инициализированный) репозиторий. Как существительное, два репозитория можно назвать клонами , если они синхронизированы и содержат одни и те же ревизии.
Коммит ( check in , ci или, реже, install , submit или record ) означает запись или слияние изменений, сделанных в рабочей копии, обратно в репозиторий. Коммит содержит метаданные, как правило, информацию об авторе и сообщение коммита, описывающее изменение .
Короткая заметка, написанная разработчиком, хранящаяся вместе с коммитом, которая описывает коммит. В идеале она записывает, почему была сделана модификация, описывает эффект или цель модификации и неочевидные аспекты того, как работает изменение.
Конфликт возникает, когда разные стороны вносят изменения в один и тот же документ, и система не может согласовать изменения. Пользователь должен разрешить конфликт, объединив изменения или выбрав одно изменение в пользу другого.
Большинство программ контроля версий используют дельта-сжатие , которое сохраняет только различия между последовательными версиями файлов. Это позволяет более эффективно хранить множество различных версий файлов.
Поток, в котором некоторые или все версии файлов являются зеркалами версий родительского потока.
Экспорт — это процесс получения файлов из репозитория. Он похож на извлечение, за исключением того, что он создает чистое дерево каталогов без метаданных контроля версий, используемых в рабочей копии. Это часто используется, например, перед публикацией содержимого.
Смотри тянуть .
Процесс объединения изменений, внесенных в основной ствол , в ветку разработки (функциональную или командную).
Также иногда называется tip , это относится к самому последнему коммиту, либо к стволу, либо к ветке. Ствол и каждая ветка имеют свою собственную голову, хотя HEAD иногда свободно используется для обозначения ствола. [29]
Импорт — это процесс первого копирования локального дерева каталогов (которое в данный момент не является рабочей копией) в репозиторий.
Создать новый пустой репозиторий.
Некоторое программное обеспечение для контроля версий использует метод Interleaved deltas , который позволяет хранить историю текстовых файлов более эффективно, чем при использовании дельта-сжатия .
См . тег .
Когда разработчик блокирует файл, никто другой не может обновить этот файл, пока он не будет разблокирован. Блокировка может поддерживаться системой контроля версий или посредством неформального общения между разработчиками (также известной как социальная блокировка ).
Аналогично trunk , но для каждой ветви может быть своя основная линия.
Слияние или интеграция — это операция, в которой к файлу или набору файлов применяются два набора изменений. Вот некоторые примеры сценариев:
Действие копирования содержимого файла из менее контролируемого места в более контролируемое. Например, из рабочего пространства пользователя в репозиторий или из потока в его родительский объект. [31]
Копирование ревизий из одного репозитория в другой. Pull инициируется принимающим репозиторием, а push инициируется источником. Fetch иногда используется как синоним pull или для обозначения pull с последующим обновлением .
Вклады в репозиторий исходного кода, использующий распределенную систему управления версиями, обычно вносятся посредством запроса на извлечение, также известного как запрос на слияние. [32] Участник запрашивает, чтобы сопровождающий проекта извлек изменение исходного кода, отсюда и название «запрос на извлечение». Сопровождающий должен объединить запрос на извлечение, если вклад должен стать частью исходной базы. [33]
Разработчик создает запрос на извлечение, чтобы уведомить сопровождающих о новом изменении; с каждым запросом на извлечение связана ветка комментариев. Это позволяет проводить целенаправленное обсуждение изменений кода . Отправленные запросы на извлечение видны всем, у кого есть доступ к репозиторию. Запрос на извлечение может быть принят или отклонен сопровождающими. [34]
После проверки и одобрения запроса на включение он объединяется с репозиторием. В зависимости от установленного рабочего процесса код может потребовать тестирования перед включением в официальный релиз. Поэтому некоторые проекты содержат специальную ветку для объединения непротестированных запросов на включение. [33] [35] Другие проекты запускают автоматизированный набор тестов для каждого запроса на включение, используя инструмент непрерывной интеграции , и рецензент проверяет, что любой новый код имеет соответствующее тестовое покрытие.Акт вмешательства пользователя для разрешения конфликта между различными изменениями в одном и том же документе.
Процесс объединения различных ветвей команды в основной ствол системы управления версиями.
Версия — это любое изменение формы. В SVK Ревизия — это состояние на определенный момент времени всего дерева в репозитории.
Действие по обеспечению доступности одного файла или папки в нескольких ветвях одновременно. Когда общий файл изменяется в одной ветви, он изменяется и в других ветвях.
Контейнер для разветвленных файлов, имеющий известную связь с другими такими контейнерами. Потоки образуют иерархию; каждый поток может наследовать различные свойства (например, версии, пространство имен, правила рабочего процесса, подписчики и т. д.) от своего родительского потока.
Тег или метка относится к важному моментальному снимку во времени, согласованному во многих файлах. Эти файлы в этот момент могут быть помечены удобным для пользователя, значимым именем или номером ревизии. См. базовые линии, метки и теги .
Ствол — уникальная линия разработки, которая не является ветвью (иногда ее также называют базовой линией, главной линией или мастером [ 38] [39] )
Обновление (или синхронизация , но синхронизация может также означать объединение push и pull ) объединяет изменения, внесенные в репозиторий (например, другими людьми), в локальную рабочую копию . Обновление — это также термин, используемый некоторыми инструментами CM (CM+, PLS, SMS) для концепции пакета изменений (см. changelist ). Синоним checkout в системах контроля версий, которые требуют, чтобы каждый репозиторий имел ровно одну рабочую копию (обычно в распределенных системах)
Снятие блокировки.
Рабочая копия — это локальная копия файлов из репозитория в определенное время или ревизию. Вся работа, выполняемая с файлами в репозитории, изначально выполняется в рабочей копии, отсюда и название. Концептуально это песочница .
С точки зрения человеко-часов это обойдется вам в 6–48 раз больше, чем стоило бы использование контроля версий, и это за перемотку пары моделей для одного разработчика.
Системы контроля версий позволяют сравнивать файлы, выявлять различия и объединять изменения, если это необходимо, перед фиксацией любого кода. Версионирование также является отличным способом отслеживать сборки приложений, позволяя определять, какая версия в данный момент находится в разработке, QA и производстве.
История документа предоставляет бесценную информацию об авторе и дате редактирования. Она также дает информацию о цели внесенных изменений. Это повлияет на разработчика, который работает над последней версией, поскольку поможет решить проблемы, возникшие в более ранних версиях. Возможность идентифицировать автора документа позволяет текущей команде связывать документы с конкретными участниками. Это, в свою очередь, позволяет текущей команде выявлять закономерности, которые могут помочь в исправлении ошибок. Это поможет улучшить общую функциональность программного обеспечения.
Команды разработчиков программного обеспечения могут понять эволюцию решения, изучая предыдущие версии с помощью обзоров кода.
Если допущена ошибка, разработчики могут вернуться назад во времени и просмотреть предыдущие итерации кода, чтобы исправить ошибку, минимизируя при этом неудобства для всех членов команды.
Инструмент git bisect — невероятно полезный инструмент отладки, используемый для поиска конкретного коммита, который первым привел к ошибке или проблеме, путем выполнения автоматического бинарного поиска.
Версионирование — бесценный процесс, особенно когда над одним приложением работают несколько разработчиков, поскольку оно позволяет им легко обмениваться файлами. Без контроля версий разработчики в конечном итоге будут наступать друг другу на пятки и перезаписывать изменения кода, которые кто-то другой мог выполнить, даже не осознавая этого. Использование этих систем позволяет вам проверять файлы на наличие изменений, а затем, во время регистрации, если файлы были изменены другим пользователем, вы будете предупреждены и сможете объединить их.
Продолжаются дискуссии об использовании rebase, merge и/или squash. Я хочу обратить внимание на суть всех этих выборов — общение.