Что означают "ветвь", "тег" и "багажник" в репозиториях Subversion?

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

• trunk/- версия для разработки, скоро будет 1.1
• branch/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
• branch/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.0.0
• tags/1.0.0 - версия 1.0.0 версия
• tags/1.0.1 - версия версии 1.0.1
• теги /1.1beta1 - версия 1.1 beta 1

После того, как вы отпустите 1.1 final, вы делаете тег "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". (Кроме того, семантическое управление версиями является хорошим руководством по порядку номеров версий).

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

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

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

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

• Источник управления HOWTO

Статьи в Википедии также заслуживают внимания.

Ответ 8

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

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

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

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

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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

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

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

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

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

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

Ответ 12

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

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

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

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

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

Ответ 13

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

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

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

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

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

Ответ 14

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

Ответ 15

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

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

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

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

Ответ 16

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

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

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

Ответ 17

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

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