Вопрос: Что означают «ветвь», «тег» и «багажник» в репозиториях Subversion?


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

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


1127


источник


Ответы:


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

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

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

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

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


860



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

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

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

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

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


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

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

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

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

Вы сталкиваетесь с некоторыми ошибками в коде и исправляете их в trunk, а затем объединяете исправления в ветку 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 версия выпуска
  • теги / 1.0.1 - 1.0.1 версия выпуска

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

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

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

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


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

  • 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 ". (В стороне, семантическое управление версиями является хорошим руководством о том, как делать номера версий).


535



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

enter image description here

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


92



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

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

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

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

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

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

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

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

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

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


73



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

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

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

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


36



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

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

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

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

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

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


27



The trunk is the development line that holds the latest source code and features. It should have the latest bug fixes in it as well as the latest features added to the project.

The branches are usually used to do something away from the trunk (or other development line) that would otherwise break the build. New features are often built in a branch and then merged back into the trunk. Branches often contain code that are not necessarily approved for the development line it branched from. For example, a programmer could try an optimization on something in a branch and only merge back in the development line once the optimization is satisfactory.

The tags are snapshots of the repository at a particular time. No development should occur on these. They are most often used to take a copy of what was released to a client so that you can easily have access to what a client is using.

Here's a link to a very good guide to repositories:

The articles in Wikipedia are also worth reading.


12



Now that's the thing about software development, there's no consistent knowledge about anything, everybody seems to have it their own way, but that's because it is a relatively young discipline anyway.

Here's my plain simple way,

trunk - The trunk directory contains the most current, approved, and merged body of work. Contrary to what many have confessed, my trunk is only for clean, neat, approved work, and not a development area, but rather a release area.

At some given point in time when the trunk seems all ready to release, then it is tagged and released.

branches - The branches directory contains experiments and ongoing work. Work under a branch stays there until is approved to be merged into the trunk. For me, this is the area where all the work is done.

For example: I can have an iteration-5 branch for a fifth round of development on the product, maybe a prototype-9 branch for a ninth round of experimenting, and so on.

tags - The tags directory contains snapshots of approved branches and trunk releases. Whenever a branch is approved to merge into the trunk, or a release is made of the trunk, a snapshot of the approved branch or trunk release is made under tags.

I suppose with tags I can jump back and forth through time to points interest quite easily.


10