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

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

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

19.08.2008 13:22:03
Вот хорошая статья, которую я наткнулся на объяснение того, как / когда использовать ствол, ветвь и теги. Раньше я не использовал управление исходным кодом, но в этой статье довольно легко было понять нубу, как я. Изо дня в день с Subversion
badmoon 19.08.2008 14:53:19
16 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

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

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

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

910
4.04.2019 01:12:16
Путаница с тегами и ветвями заключается в том, что в svn между ними нет никакого различия, кроме названия каталога. В SVN вы можете вносить изменения в тег, и на самом деле это трудно предотвратить. Большинство других VCS рассматривают теги как неизменяемые снимки (моменты времени).
Ken Liu 9.10.2009 18:36:34
TagsКаталог также часто используется для тестирования основных этапов и проверки обычным пользователем. Это было бы хорошим местом для размещения прототипа тоже (только некоторые идеи на моей голове).
Jeff Noel 26.10.2012 07:09:05
@KenLiu Есть хуки, которые могут сделать теги неизменяемыми. То есть вы можете создать и оформить тег, но не вносить никаких изменений. Конечно, тег, являющийся лишь частью хранилища, означает, что доступна полная история. Если кто-то изменяет тег, вы можете отслеживать это и почему. Во многих VCS, если вы изменяете тег, может не быть никакого способа узнать об этом.
David W. 1.03.2015 19:33:37
Возможно, следует упомянуть стабильные ветви : сделанные там изменения обычно не объединяются в магистраль .
Wolf 6.05.2015 12:59:20
Насколько я понимаю, в «идеальном мире» никакая разработка никогда не должна происходить в транке, транк всегда должен быть либо точным кодом, который находится в реальном времени, либо кодом, который вот-вот должен быть выпущен в реальном времени. как таковой, что сделало бы ветви основной частью развития.
MikeT 3.08.2015 09:20:35

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

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

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

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

38
19.08.2008 13:25:17

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

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

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

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

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

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

30
3.01.2016 20:01:46

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

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

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

9
9.04.2012 18:08:45

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

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

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

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

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

5
9.04.2012 18:26:25

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

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

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

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

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

13
19.08.2008 13:37:32

В дополнение к тому, что сказал Ник, вы можете узнать больше на Streamed Lines: паттерны ветвления для параллельной разработки программного обеспечения

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

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

97
3.05.2012 00:46:06
@ Волк, он может быть - эта диаграмма довольно общая, независимо от инструментов. Все SCM используют разные слова, но одни и те же понятия, между магистралью и главой нет никакой разницы; или багажник и мастер. Эта диаграмма показывает, как моя нынешняя компания использует SVN.
gbjbaanb 27.05.2015 10:58:56
@gbjbaanb Спасибо, что поделились. ... и теги, похоже, не решаются с помощью вопроса. Является ли чистым совпадением (также в вашей нынешней компании), что слияния не идут от основного к обслуживаемому филиалу?
Wolf 27.05.2015 11:17:58
@ Волк Не случайно - только ветка из ствола, делайте работу, сливайтесь обратно в ствол. Затем ветвь от ствола к ветви тега. Мы рассматриваем еще один «ствол», который называется «Интеграция», в котором завершены ветви, объединенные с ним, для тестирования, которое не составляет релиз, транк все еще используется для тех веток, которые мы решили добавить в следующий выпуск. Единственный раз, когда вы объединяетесь из ствола в ветку, это обновить долгосрочную ветку, но лучше (и проще) просто создать новую ветку из ствола и объединить изменения вашей старой ветки с ней, если вам это нужно.
gbjbaanb 27.05.2015 12:10:50

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

6
19.08.2008 17:24:07

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

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

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

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

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

8
9.04.2012 18:37:51
Альтернативная перспектива заключается в том, что верно обратное, что навязывание концепции тегов на объектной модели Subversion было бы неплотной абстракцией в противоположном направлении. Как я полагаю, вы знаете, Subversion была реакцией на CVS, попыткой «сделать CVS правильно». Я не смог найти ссылку, но разработчики оригинальной Subversion сказали, что они на 100% отбросили концепцию тегов, что различие между ветвями и тегами является чисто политическим вопросом. Если команды хотят навязать политику и соглашение поверх объектной модели Subversion, пусть будет так. Это именно то, что мы имеем сегодня.
Darryl 28.05.2013 18:11:02

Прежде всего, как указывают @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 бета 1

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

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


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

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

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


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

556
10.04.2012 06:05:55
@baruch - Это совершенно неправильно. Теги легковесны и (что касается самого Subversion) идентичны ветвям.
Josh Kelley 14.07.2014 14:08:16
Люблю детали использования. Спасибо @gregmac.
Jeromy French 2.12.2014 17:02:54
Могу ли я получить цитату о том, что теги / ветки легкие? Кажется, что это не так ...
Cardin 8.05.2015 02:45:05
Это должен быть принятый ответ, который намного лучше ^^
Nam G VU 17.12.2015 07:27:06
@Cardin У меня нет ссылки прямо сейчас, но важно отметить, что теги легковесны на сервере, но не на клиенте. Если вы извлечете все теги, вы получите столько полных копий. Однако, если вы посмотрите на размер репозитория на сервере, он увеличится только на несколько байтов на тег. Вот почему вы не должны извлекать корневой каталог, вообще говоря.
gregmac 2.02.2016 21:19:07

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

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

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

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

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

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

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

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

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

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

75
3.01.2016 20:07:14

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

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

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

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

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

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

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

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

12
30.06.2009 11:50:56

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

9
9.04.2012 18:23:30

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

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

Цитируется прямо из его урока:

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

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

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

10
15.06.2018 15:14:46

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

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

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

4
25.04.2017 11:43:37
Это ваш конкретный рабочий процесс, он вообще не применим.
Jason S 18.09.2018 16:55:47

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

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

4
4.04.2018 05:07:23