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

прежде всего, как указывают @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 версия
• теги / 1.0.0-1.0.0 release version

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

• trunk / - версия для разработки, скоро будет 1.1
• филиалы/1.0 - предстоящий релиз 1.0.1
• теги/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
• теги/1.0.0 - 1.0.0 версия
• теги / 1.0.1-1.0.1 release version

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

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

после выпуска 1.1 final вы делаете тег "1.1" из ветви "1.1".

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

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

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

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

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

на этом рисунке main багажник, rel1-maint филиала и 1.0 - это тег.

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

• багажник главный филиал рекомендовано по Subversion, но вы никоим образом не обязаны его создавать. Вы можете назвать его "main" или "releases", или не иметь его вообще!

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

  • цель "myProject_dev" или "myProject_Merge"
  • периметр выпуска myProjetc1.0_dev'or myProject2.3_Merge ' или ' myProject6..2_Patch1'...

• Tag является моментальным снимком файлов, чтобы легко вернуться в это состояние. проблема в том, что тег и ветвь одинаковы в Subversion. И я бы определенно рекомендую параноидальный подход:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• управление версиями HOWTO

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

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

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

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

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

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

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

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

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

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

у него есть учебник о том, как использовать SVN и что означают фразы "trunk", " tag " и "branch".

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

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

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

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

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

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

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

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

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

Я думаю, что это то, что обычно понимается под "тегом". Но в Subversion:

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

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

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

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

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

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

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

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

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

багажник является базовой папкой кода вашего приложения. Именно здесь вы работаете над своей следующей версией / выпуском.

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

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

Теги - Это папка, которая позволяет делать снимки вашего приложения, и работайте только с этими конкретными "сборками". Это позволяет вашей команде проявлять гибкость как при тестировании, так и при поиске различий между сборками. Вы часто найдете соглашение об именах в /Branch, которое относится к вашим сборкам, т. е. / Branch / 2.0.0,/Branch /2.0.1,/Branch / 3.1.0 и так далее. Соглашение об именах зависит от вас и вашей команды; держите его последовательным!

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

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

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

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

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