Что означают «ветвь», «тег» и «ствол» в репозиториях Subversion?

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

Что они имеют в виду?

Ответов (16)

Решение

Хм, не уверен, что согласен с тем, что тег Ника похож на ветку. Тег - это просто маркер

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

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

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

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

Поддеревья веток и тегов отличаются от ствола следующими способами:

Subversion позволяет системным администраторам создавать сценарии ловушек, которые запускаются для выполнения при возникновении определенных событий; например, фиксация изменения в репозитории. Типичная реализация репозитория Subversion очень часто обрабатывает любой путь, содержащий "/ tag /", как защищенный от записи после создания; Конечный результат состоит в том, что однажды созданные теги неизменяемы (по крайней мере, для «обычных» пользователей). Это делается с помощью сценариев ловушек, которые обеспечивают неизменность, предотвращая дальнейшие изменения, если тег является родительским узлом измененного объекта.

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

Багажник : после завершения каждого спринта в Agile мы выпускаем частично готовый к отправке продукт. Эти релизы хранятся в багажнике.

Ветви : все коды параллельных разработок для каждого текущего спринта хранятся в ветвях.

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

В дополнение к тому, что сказал Ник, вы можете узнать больше в Streamed Lines: Branching Patterns for Parallel Software Development

введите описание изображения здесь

На этом рисунке main - ствол, rel1-maint ветвь и 1.0 бирка.

Для людей, знакомых с GIT, master в GIT эквивалентен транку в SVN.

Ветвь и тег имеют одинаковую терминологию как в GIT, так и в SVN.

Я думаю, что некоторая путаница возникает из-за разницы между концепцией тега и реализацией в SVN. Для SVN тег - это ветвь, которая является копией. Изменение тегов считается неправильным, и на самом деле такие инструменты, как TortoiseSVN, предупредят вас, если вы попытаетесь изменить что-либо с ../tags/ .. в пути.

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

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

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

Вот ссылка на очень хорошее руководство по репозиториям:

Также стоит прочитать статьи в Википедии.

В SVN тег и ветка действительно похожи.

Тег = определенный отрезок времени, обычно используемый для релизов

Ветвь = также определенный отрезок времени, на котором может продолжаться разработка, обычно используется для основных версий, таких как 1.0, 1.5, 2.0 и т. Д., А затем, когда вы выпускаете, вы помечаете ветку. Это позволяет вам продолжать поддерживать производственный выпуск, продвигаясь вперед с критическими изменениями в основной ветке.

Магистраль = рабочее пространство разработки, здесь должна происходить вся разработка, а затем изменения, объединенные обратно из выпусков ветки.

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

  • Ствол - это то место, где вы держите свое основное направление развития. Папка веток - это то место, где вы можете создавать ветки, которые трудно объяснить в коротком посте.

  • Ветвь - это копия подмножества вашего проекта, над которым вы работаете отдельно от ствола. Может быть, это для экспериментов, которые никуда не денутся, или, может быть, для следующего выпуска, который вы позже объедините обратно в магистраль, когда он станет стабильным.

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

Но, как я уже сказал, для SVN папка - это папка. branch, trunk и тег - это просто соглашение.

Я широко использую слово «копировать». SVN на самом деле не делает полные копии вещей в репозитории.

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

Каталог веток предназначен для хранения ваших веток, какими бы они ни были.

Каталог тегов в основном предназначен для тегирования определенного набора файлов. Вы делаете это для таких вещей, как выпуски, где вы хотите, чтобы «1.0» был этими файлами в этих ревизиях, а «1.1» - этими файлами в этих ревизиях. Обычно вы не изменяете теги после их создания. Дополнительную информацию о тегах см. В главе 4. Ветвление и слияние (в разделе Управление версиями с Subversion» ).

Я не совсем уверен, что такое «тег», но ветвь - довольно распространенная концепция управления версиями.

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

Сначала вы создадите ветку. По сути, это копия ствола на момент создания ветки. Затем вы будете выполнять всю свою работу в ветке. Любые изменения, внесенные в ветку, не влияют на магистраль, поэтому магистраль по-прежнему может использоваться, позволяя другим продолжать работать там (например, исправлять ошибки или небольшие улучшения). Как только ваша функция будет готова, вы должны интегрировать ветку обратно в магистраль. Это переместит все ваши изменения из ветки в ствол.

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

Вот запись в Википедии о ветках , поскольку они, вероятно, объясняют вещи лучше, чем я. :)

Тег = определенный отрезок времени, обычно используемый для релизов

Я думаю, это то, что обычно подразумевают под «тегом». Но в Subversion:

На самом деле они не имеют никакого формального значения. Папка - это папка для SVN.

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

Или, возможно, я просто слишком долго пользуюсь CVS .

Прежде всего, как указывают @AndrewFinnell и @KenLiu, в SVN сами имена каталогов ничего не значат - «ствол, ветки и теги» - это просто общее соглашение, которое используется в большинстве репозиториев. Не все проекты используют все каталоги (разумно вообще не использовать «теги»), и на самом деле ничто не мешает вам называть их как угодно, хотя нарушение соглашения часто сбивает с толку.

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

  • Багажник : Основное направление развития. Здесь обитает ваш следующий крупный выпуск кода, и, как правило, он содержит все новейшие функции.

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

  • Теги : каждый раз, когда вы выпускаете версию (финальный выпуск, кандидаты на выпуск (RC) и бета-версии), вы делаете для нее тег. Это дает вам копию кода на определенный момент времени в том виде, в котором он был в этом состоянии, что позволяет вам вернуться и воспроизвести любые ошибки, если это необходимо в прошлой версии, или повторно выпустить предыдущую версию в точности так, как это было. Ветви и теги в SVN легковесны - на сервере он не делает полную копию файлов, а только маркер, говорящий «эти файлы были скопированы в этой ревизии», который занимает всего несколько байтов. Имея это в виду, вы никогда не должны беспокоиться о создании тега для любого выпущенного кода. Как я сказал ранее, теги часто опускаются, и вместо этого в журнале изменений или другом документе уточняется номер редакции при выпуске релиза.


Например, предположим, вы начинаете новый проект. Вы начинаете работать в «стволе», над которым в конечном итоге выйдет версия 1.0.

  • trunk / - разрабатываемая версия, скоро будет 1.0
  • ветки / - пусто

Как только 1.0.0 будет завершена, вы разветвляете ствол в новую ветку «1.0» и создаете тег «1.0.0». Теперь работа над тем, что в конечном итоге будет 1.1, продолжается в багажнике.

  • trunk / - разрабатываемая версия, скоро будет 1.1
  • ветки / 1.0 - версия выпуска 1.0.0
  • tags / 1.0.0 - релизная версия 1.0.0

Вы сталкиваетесь с некоторыми ошибками в коде и исправляете их в основной ветке, а затем объединяете исправления в ветку 1.0. Вы также можете сделать обратное и исправить ошибки в ветке 1.0, а затем объединить их обратно в основную ветку, но обычно проекты придерживаются одностороннего слияния только для того, чтобы уменьшить вероятность чего-то пропустить. Иногда ошибку можно исправить только в версии 1.0, потому что она устарела в версии 1.1. На самом деле это не имеет значения: вам нужно только убедиться, что вы не выпускаете 1.1 с теми же ошибками, которые были исправлены в 1.0.

  • trunk / - разрабатываемая версия, скоро будет 1.1
  • ветки / 1.0 - предстоящий выпуск 1.0.1
  • tags / 1.0.0 - релизная версия 1.0.0

Как только вы обнаружите достаточно ошибок (или, возможно, одну критическую), вы решите выпустить выпуск 1.0.1. Итак, вы делаете тег «1.0.1» из ветки 1.0 и выпускаете код. На этом этапе магистраль будет содержать то, что будет 1.1, а ветка «1.0» будет содержать код 1.0.1. В следующий раз, когда вы выпустите обновление до 1.0, это будет 1.0.2.

  • trunk / - разрабатываемая версия, скоро будет 1.1
  • ветки / 1.0 - предстоящий выпуск 1.0.2
  • tags / 1.0.0 - релизная версия 1.0.0
  • tags / 1.0.1 - релизная версия 1.0.1

В конце концов, вы почти готовы к выпуску 1.1, но сначала вы хотите сделать бета-версию. В этом случае вы, вероятно, сделаете ветку «1.1» и тег «1.1beta1». Теперь работа над тем, что будет 1.2 (или, возможно, 2.0), продолжается в магистрали, но работа над 1.1 продолжается в ветви "1.1".

  • trunk / - разрабатываемая версия, скоро будет 1.2
  • ветки / 1.0 - предстоящий выпуск 1.0.2
  • ветки / 1.1 - предстоящий выпуск 1.1.0
  • tags / 1.0.0 - релизная версия 1.0.0
  • tags / 1.0.1 - релизная версия 1.0.1
  • tags / 1.1beta1 - версия 1.1 beta 1

После того, как вы выпустите финальную версию 1.1, вы сделаете тег «1.1» из ветки «1.1».

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


Другое использование веток - для функций. Здесь вы разветвляете магистраль (или одну из веток выпуска) и работаете над новой функцией изолированно. Как только функция будет завершена, вы снова объедините ее и удалите ветку.

  • trunk / - разрабатываемая версия, скоро будет 1.2
  • ветки / 1.1 - предстоящий выпуск 1.1.0
  • branch / ui-rewrite - ветка экспериментальной функции

Идея заключается в том, что вы работаете над чем-то разрушительным (что может задерживать или мешать другим людям выполнять свою работу), над чем-то экспериментальным (что может даже не получиться) или, возможно, просто над чем-то, что занимает много времени. (и вы боитесь, что если он будет поддерживать выпуск 1.2, когда вы будете готовы к ветвлению 1.2 из магистрали), вы можете сделать это изолированно в ветке. Обычно вы поддерживаете его в актуальном состоянии с помощью ствола, постоянно добавляя в него изменения, что упрощает повторную интеграцию (слияние обратно в ствол), когда вы закончите.


Также обратите внимание, что схема управления версиями, которую я использовал здесь, - лишь одна из многих. Некоторые команды будут выпускать исправления ошибок / выпуски обслуживания, такие как 1.1, 1.2 и т. Д., И серьезные изменения как 1.x, 2.x и т. Д. Использование здесь такое же, но вы можете назвать ветку «1» или «1». .x вместо «1.0» или «1.0.x». (Кроме того, семантическое управление версиями - хорошее руководство по нумерации версий).

В общем (взгляд, независимый от инструментов), ветвление - это механизм, используемый для параллельной разработки. SCM может иметь от 0 до n ветвей. Subversion имеет 0.

  • Trunk - это основная ветка, рекомендованная Subversion , но вас никоим образом не заставляют ее создавать. Вы можете называть это «основными» или «релизами» или не иметь их вообще!

  • Branch представляет собой усилие разработки. Он никогда не должен называться в честь ресурса (например, vonc_branch), но после:

    • цель myProject_dev или myProject_Merge
    • периметр выпуска myProjetc1.0_dev или myProject2.3_Merge или myProject6..2_Patch1 ...
  • Тег - это снимок файлов, позволяющий легко вернуться в это состояние. Проблема в том, что тег и ветка в Subversion одинаковые . И я бы определенно рекомендовал параноидальный подход:

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

Тег окончательный. Его содержание никогда не должно меняться. НИКОГДА. Всегда. Вы забыли строчку в примечании к выпуску? Создайте новый тег. Устаревший или удалите старый.

Я много читал о «обратном слиянии такого-то и такого-то в таких-то и таких-то ветвях, а затем, наконец, в основной ветке». Это называется рабочим процессом слияния, и здесь нет ничего обязательного . Это не потому, что у вас есть магистральная ветвь, поэтому вам нужно что-то объединять .

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

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

Потому что с одним (или всеми) из этих сценариев вы получаете четыре «ствола», четыре «текущих развития», и не все, что вы делаете в этих параллельных разработках, обязательно нужно будет снова объединить в «ствол».

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

Вот мой простой простой способ,

ствол - Каталог ствола содержит самые последние, утвержденные и объединенные работы. Вопреки тому, что многие признались, мой багажник предназначен только для чистой, аккуратной, одобренной работы, а не для области разработки, а скорее для области выпуска.

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

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

Например: у меня может быть ветвь итерации-5 для пятого раунда разработки продукта, возможно, ветвь прототипа-9 для девятого раунда экспериментов и так далее.

теги - каталог тегов содержит снимки утвержденных веток и выпусков ствола. Каждый раз, когда ветвь утверждается для слияния с основной ветвью, или когда из ствола производится выпуск, с тегами создается моментальный снимок утвержденной ветви или выпуск основной ветви.

Я полагаю, что с помощью тегов я могу довольно легко прыгать вперед и назад во времени к интересующим точкам.

Одна из причин , почему каждый человек имеет немного другое определение, потому что Subversion реализует обнулить поддержку ветвей и тегов. Subversion в основном говорит: мы посмотрели на полнофункциональные ветки и теги в других системах и не нашли их полезными, поэтому мы ничего не реализовали. Вместо этого просто сделайте копию в новый каталог с условным обозначением имени . Тогда, конечно, каждый волен иметь немного разные условности. Чтобы понять разницу между реальным тегом и простым соглашением о копировании + именовании, см. Статью в Википедии Теги и ветки Subversion» .

Я нашел большой учебник о SVN , когда я смотрела на веб - сайте автора в OpenCV 2 компьютерного зрения прикладного программирования Cookbook , и я думал , что я должен поделиться.

У него есть руководство о том, как использовать SVN и что означают фразы «ствол», «тег» и «ветвь».

Цитируется непосредственно из его учебника:

Текущая версия вашего программного проекта, над которым в настоящее время работает ваша команда, обычно находится в каталоге под названием trunk . По мере развития проекта разработчик обновляет эту версию, исправляет ошибки, добавляет новые функции и отправляет свои изменения в этот каталог.

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

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