Что означают «ветвь», «тег» и «ствол» в репозиториях Subversion?
Я часто встречал эти слова в обсуждениях Subversion (и, я думаю, общего репозитория). Я использую SVN для своих проектов в течение последних нескольких лет, но я никогда не понимал всей концепции этих каталогов.
Что они имеют в виду?
Ответы 15
В SVN тег и ветка действительно похожи.
Тег = определенный отрезок времени, обычно используемый для релизов
Ответвляться = также определенный отрезок времени, в течение которого разработка может продолжаться, обычно используется для основных версий, таких как 1.0, 1.5, 2.0 и т.д., затем, когда вы выпускаете, вы помечаете ветку. Это позволяет вам продолжать поддерживать производственный выпуск, продвигаясь вперед с критическими изменениями в основной ветке.
Хобот = рабочая область разработки, здесь должна происходить вся разработка, а затем изменения, объединенные обратно из выпусков ветки.
На самом деле они не имеют никакого формального значения. Папка - это папка в SVN. Это общепринятый способ организации вашего проекта.
Ствол - это то место, где вы держите свое основное направление развития. Папка веток - это то место, где вы можете создавать ветки, которые трудно объяснить в коротком посте.
Ветвь - это копия подмножества вашего проекта, над которым вы работаете отдельно от ствола. Может быть, это для экспериментов, которые никуда не денутся, или, может быть, для следующего выпуска, который вы позже объедините обратно в магистраль, когда он станет стабильным.
А папка тегов предназначена для создания тегированных копий вашего репозитория, обычно на контрольных точках выпуска.
Но, как я уже сказал, для SVN папка - это папка. branch, trunk и тег - это просто соглашение.
Я широко использую слово «копировать». SVN на самом деле не делает полные копии вещей в репозитории.
Каталог магистрали - это каталог, с которым вы, вероятно, наиболее знакомы, поскольку он используется для хранения самых последних изменений. Ваша основная кодовая база должна быть в багажнике.
Каталог веток предназначен для хранения ваших веток, какими бы они ни были.
Каталог тегов в основном предназначен для тегирования определенного набора файлов. Вы делаете это для таких вещей, как выпуски, где вы хотите, чтобы «1.0» был этими файлами в этих ревизиях, а «1.1» - этими файлами в этих ревизиях. Обычно вы не изменяете теги после их создания. Для получения дополнительной информации о тегах см. Глава 4. Ветвление и слияние (в Контроль версий с помощью Subversion).
Я не совсем уверен, что такое «тег», но ветвь - довольно распространенная концепция управления версиями.
По сути, ветвление - это способ работать над изменениями кода, не затрагивая транк. Допустим, вы хотите добавить новую довольно сложную функцию. Вы хотите иметь возможность фиксировать изменения по мере их внесения, но не хотите, чтобы они влияли на магистраль, пока вы не закончите работу с этой функцией.
Сначала вы создадите ветку. По сути, это копия ствола на момент создания ветки. Затем вы будете выполнять всю свою работу в ветке. Любые изменения, внесенные в ветку, не влияют на магистраль, поэтому магистраль по-прежнему может использоваться, позволяя другим продолжать работать там (например, исправлять ошибки или небольшие улучшения). Как только ваша функция будет готова, вы должны интегрировать ветку обратно в магистраль. Это переместит все ваши изменения из ветки в ствол.
Есть несколько шаблонов, которые люди используют для веток. Если у вас есть продукт, который поддерживает одновременно несколько основных версий, обычно каждая версия является ветвью. Там, где я работаю, у нас есть отдел контроля качества и производственный отдел. Перед выпуском нашего кода для QA мы интегрируем изменения в QA-ветку, а затем выполняем развертывание оттуда. При выпуске в производственную среду мы интегрируемся из ветви QA в производственную ветвь, поэтому мы знаем, что код, работающий в производственной среде, идентичен тому, что тестировал QA.
Вот Запись в Википедии о ветках, поскольку они, вероятно, объясняют вещи лучше, чем я. :)
Хм, не уверен, что согласен с тем, что тег Ника похож на ветку. Тег - это просто маркер
Хобот будет основной частью разработки, начиная с начала проекта и до настоящего времени.
Ответвляться будет копией кода, полученного из определенной точки в магистрали, которая используется для внесения основных изменений в код при сохранении целостности кода в магистрали. Если основные изменения работают по плану, они обычно объединяются обратно в ствол.
Тег будет моментом времени в магистрали или ветке, которую вы хотите сохранить. Двумя основными причинами сохранения могут быть то, что либо это основной выпуск программного обеспечения, будь то альфа, бета, RC или RTM, либо это наиболее стабильный момент программного обеспечения до того, как были внесены основные изменения в магистраль.
В проектах с открытым исходным кодом основные ветки, которые не принимаются в магистраль заинтересованными сторонами проекта, могут стать основой для вилки - например, полностью отдельные проекты, которые имеют общее происхождение с другим исходным кодом.
Поддеревья веток и тегов отличаются от ствола следующими способами:
Subversion позволяет системным администраторам создавать скрипты перехвата, которые запускаются для выполнения при возникновении определенных событий; например, фиксация изменения в репозитории. Типичная реализация репозитория Subversion очень часто обрабатывает любой путь, содержащий «/ tag /», как защищенный от записи после создания; Конечный результат состоит в том, что однажды созданные теги неизменяемы (по крайней мере, для «обычных» пользователей). Это делается с помощью сценариев ловушек, которые обеспечивают неизменность, предотвращая дальнейшие изменения, если тег является родительским узлом измененного объекта.
В Subversion, начиная с версии 1.5, также добавлены функции, относящиеся к «отслеживанию слияния ветвей», так что изменения, зафиксированные в ответвляться, могут быть объединены обратно в магистраль с поддержкой инкрементного «интеллектуального» слияния.
Путаница с тегами и ветвями заключается в том, что в svn действительно нет различия между ними, кроме имени каталога. В svn вы можете фиксировать изменения в теге, и на самом деле это сложно предотвратить. Большинство других VCS обрабатывают теги как неизменяемые моментальные снимки (моменты времени).
Каталог Tags также часто используется для тестирования этапов и проверки обычным пользователем. Это было бы хорошим местом для размещения прототипа (просто некоторые идеи в голове).
@KenLiu Есть хуки, которые могут сделать теги неизменяемыми. То есть вы можете создавать и извлекать теги, но не вносить никаких изменений. Конечно, тег, являющийся просто частью репозитория, означает, что доступна полная история. Если кто-то меняет тег, вы можете отследить это и почему. Во многих VCS, если вы изменяете тег, может не быть никакого способа узнать.
Возможно, стоит упомянуть стабильные отделения: сделанные там изменения обычно не относятся к слился обратно в багажник.
В чем тогда будет разница между стабильной веткой и тегом?
Я понимаю, что в «идеальном мире» никакая разработка никогда не должна происходить в стволе, ствол всегда должен быть либо точным кодом, который находится в реальном времени, либо кодом, который вот-вот будет выпущен в эфир. как таковой, что сделало бы ветви основной частью развития.
Кроме того, я понимаю, что тег должен делать, так это то, что тег больше похож на вторичные стволы, то есть у вас есть продукт на рынке, у которого есть активная база пользователей. вы решаете выпустить версию 2 как отдельный продукт, а не как обновление, однако, если ошибка обнаружена в версии 1 вашего продукта, вам необходимо предоставить поддержку существующей базе пользователей, даже если они не обновились до версии 2, поэтому вы создаст тег перед переходом на v2, а затем любые исправления ошибок, необходимые для v1, могут быть выполнены в ветвях, происходящих из тега v1
Я считаю, что тег должен создаваться каждый раз, когда выпускается код в стволе (или ветке). Под «выпущенной» я подразумеваю версию x.y.z, которую можно развернуть в тестовом или производственном режиме. Если ошибка отображается в версии x.y.z, но ствол изменился в связи с новой разработкой, тег x.y.z можно скопировать в ветку x.y.z, и здесь ошибка будет исправлена. Я думаю, что того же можно достичь, указав номер версии SVN при выпуске, и проверив эту версию при исправлении ошибки в производстве. Но тег более явный.
Это не отвечает на исходный вопрос. Вместо этого ответ дает (правильное) общее введение в общие понятия «магистраль», «ветвь» и «тег». ОДНАКО: SVN это НЕ делает. А именно: концепция «тега» как неизменяемого моментального снимка с отметкой времени НЕ поддерживается в SVN. И если вы сами не добавляете неизменяемость через хук предварительной фиксации, тогда «TAG» в SVN - это просто «BRANCH», который вы выбрали для помещения в каталог, который вы выбрали для имени «Tag». И все, что мешает вам изменить его впоследствии, - это невыполненное соглашение.
Кое-что относится к «стволу»: объяснение общей концепции правильное. Однако в СВН «Магистраль» НЕ обрабатывается. Это просто еще одно название папки для веток. Не более чем условности. Для получения дополнительной информации см. Ответ Эрика.
@ChrisVoon, как сказал @ StackzOftuff, ствол - это не безымянная ветвь в SVN, это ветка * с именем trunk. (* для подробностей я бы рекомендовал посмотреть ответ @EricZBeard.)
@ChrisVoon Определение Википедии слишком ограничительно. Он основан на более старых системах контроля версий, таких как CVS, в которых действительно есть место без имени по умолчанию для фиксации изменений. Это безымянное место в разговоре называется «стволом». Это было подходящее имя, потому что репозиторий начинался только с магистрали, а все остальное разветвлялось оттуда. Невозможно было создать ветку, которая каким-либо образом не ведет к стволу. И у git, и у svn есть соглашения, которые служат той же цели, что и ствол. Несмотря на то, что это всего лишь условные обозначения, термин «ствол» по-прежнему уместен.
хобот - это линия разработки, которая содержит последний исходный код и функции. В нем должны быть последние исправления ошибок, а также последние функции, добавленные в проект.
ветви обычно используются, чтобы делать что-то вне магистрали (или другой линии разработки), что в противном случае привело бы к перемена сборки. Новые функции часто встраиваются в ветку, а затем снова объединяются в магистраль. Ветви часто содержат код, который не обязательно одобрен для линии разработки, от которой они разветвляются. Например, программист может попробовать оптимизировать что-то в ветке и вернуться обратно в линию разработки только после того, как оптимизация окажется удовлетворительной.
теги - это снимки репозитория в определенное время. На них не должно происходить никакого развития. Чаще всего они используются для копирования того, что было передано клиенту, чтобы вы могли легко получить доступ к тому, что использует клиент.
Вот ссылка на очень хорошее руководство по репозиториям:
Также стоит прочитать статьи в Википедии.
В дополнение к тому, что сказал Ник, вы можете узнать больше на Потоковые линии: шаблоны ветвления для параллельной разработки программного обеспечения
На этом рисунке main - это магистраль, rel1-maint - это ветвь, а 1.0 - тег.
@Wolf он мог бы быть - эта диаграмма довольно общая, независимо от инструментов. Все SCM используют разные слова, но одни и те же концепции, нет разницы между магистралью и основной; или багажник и хозяин. Эта диаграмма показывает, как моя текущая компания использует SVN.
@gbjbaanb Спасибо, что поделились. ... и теги, похоже, не рассматривается в вопросе. Это чистое совпадение (также в вашей нынешней компании), что никакие слияния не переходят из основного в поддерживаемый филиалы?
@Wolf Не случайно - только ответвление от ствола, делай работу, сливайся обратно на ствол. Затем перейдите от магистрали к ответвлению тега. Мы рассматриваем еще один «ствол» под названием «Интеграция», в котором для тестирования были объединены завершенные ветки, которые не являются выпуском, ствол по-прежнему используется для тех ветвей, которые мы решили включить в следующий выпуск. Единственный раз, когда вы выполняете слияние из ствола в ветвь, - это обновляете давно работающую ветку, но лучше (и проще) просто создать новую ветку из основной ветви и объединить с ней изменения вашей старой ветки, если вам это нужно.
Я думаю, что некоторая путаница возникает из-за разницы между концепцией тега и реализацией в SVN. Для SVN тег - это ветвь, которая является копией. Изменение тегов считается неправильным, и на самом деле такие инструменты, как TortoiseSVN, предупредят вас, если вы попытаетесь изменить что-либо с ../tags/ .. в пути.
Tag = a defined slice in time, usually used for releases
Я думаю, это то, что обычно подразумевают под «тегом». Но в Subversion:
They don't really have any formal meaning. A folder is a folder to SVN.
что меня сбивает с толку: система контроля версий, которая ничего не знает о ветвях или тегах. С точки зрения реализации, я считаю, что способ создания «копий» в Subversion очень умен, но мне нужно знать об этом, что я бы назвал дырявая абстракция.
Или, возможно, я просто слишком долго использую CVS.
Альтернативная точка зрения состоит в том, что верно обратное: навязывание концепции тегов объектной модели Subversion было бы ненадежной абстракцией в противоположном направлении. Как я полагаю, вы знаете, что подрывная деятельность была реакцией на CVS, попыткой «сделать CVS правильно». Я не смог найти ссылку, но оригинальные разработчики подрывной деятельности заявили, что они полностью отказались от концепции тегов, что различие между ветвями и тегами является чисто политическим вопросом. Если команды хотят наложить политику и соглашения поверх объектной модели Subversion, пусть будет так. Это именно то, что у нас есть сегодня.
В целом (взгляд, независимый от инструмента), ветвь - это механизм, используемый для параллельной разработки. SCM может иметь от 0 до n ветвей. Subversion имеет 0.
Хобот - это основная ветвь рекомендуемые от Subversion, но вы никоим образом не обязаны ее создавать. Вы можете называть это «основными» или «релизами» или не иметь их вообще!
Ответвляться представляет собой усилие разработки. Он никогда не должен называться в честь ресурса (например, vonc_branch), но после:
- цель myProject_dev или myProject_Merge
- периметр выпуска myProjetc1.0_dev или myProject2.3_Merge или myProject6..2_Patch1 ...
Тег - это снимок файлов, позволяющий легко вернуться в это состояние. Проблема в том, что тег и ветка в Subversion одинаковые.. И я бы определенно рекомендовал параноидальный подход:
you can use one of the access control scripts provided with Subversion to prevent anyone from doing anything but creating new copies in the tags area.
Тег окончательный. Его содержание никогда не должно меняться. НИКОГДА. Всегда. Вы забыли строчку в примечании к выпуску? Создайте новый тег. Устаревший или удалите старый.
Я много читал о «обратном слиянии такого-то и такого-то в таких-то ветвях, а затем, наконец, в основной ветви». Это называется рабочий процесс слияния, а есть здесь нет ничего обязательного. нужно слить обратно ничего не происходит из-за того, что у вас есть магистральная ветка.
По соглашению, магистральная ветка может представлять текущее состояние вашей разработки, но это для простого последовательного проекта, то есть проекта, который имеет:
- нет «заблаговременной» разработки (для подготовки следующей-следующей версии, подразумевающей такие изменения, что они несовместимы с текущей «основной» разработкой)
- нет массового рефакторинга (для тестирования нового технического решения)
- отсутствие долгосрочного обслуживания предыдущей версии
Потому что с одним (или всеми) из этих сценариев вы получаете четыре «ствола», четыре «текущих развития», и не все, что вы делаете в этих параллельных разработках, обязательно нужно будет снова объединить в «ствол».
Вот в чем суть разработки программного обеспечения: здесь нет согласованных знаний ни о чем, кажется, у всех все по-своему, но это потому, что в любом случае это относительно молодая дисциплина.
Вот мой простой простой способ,
хобот - основной каталог содержит самые последние, утвержденные и объединенные работы. Вопреки тому, что многие признались, мой багажник предназначен только для чистой, аккуратной, одобренной работы, а не для области разработки, а скорее для области выпуска.
В какой-то момент, когда кажется, что ствол полностью готов к выпуску, он помечается и освобождается.
ветви - Каталог веток содержит эксперименты и текущие работы. Работа в ветке остается там до тех пор, пока не будет одобрено включение в магистраль. Для меня это та область, где делается вся работа.
Например: у меня может быть ветвь итерация-5 для пятого раунда разработки продукта, возможно, ветвь прототип-9 для девятого раунда экспериментов и так далее.
теги - каталог тегов содержит снимки утвержденных веток и выпусков ствола. Каждый раз, когда ветвь утверждается для слияния с основной линией, или когда из ствола производится выпуск, с тегами создается моментальный снимок одобренной ветви или выпуск основной ветви.
Я полагаю, что с помощью тегов я могу довольно легко прыгать вперед и назад во времени к интересующим точкам.
Одна из причин, по которой у всех несколько разные определения, заключается в том, что Subversion реализует поддержку нуль для веток и тегов. Subversion в основном говорит: Мы посмотрели на полнофункциональное соглашение ветки и теги в других системах и не сочли их полезными, поэтому мы ничего не реализовали. Просто сделайте копию в новый каталог с именемвместо. Тогда, конечно, каждый волен иметь немного разные условности. Чтобы понять разницу между тегом настоящий и соглашением о простом копировании + именовании см. запись в Википедии Теги и ветки Subversion.
Я нашел этот отличный учебник по SVN, когда искал веб-сайт автор из Поваренной книги по программированию приложений компьютерного зрения OpenCV 2, и подумал, что должен поделиться.
У него есть руководство о том, как использовать SVN и что означают фразы «ствол», «тег» и «ветвь».
Цитируется непосредственно из его учебника:
The current version of your software project, on which your team is currently working is usually located under a directory called trunk. As the project evolves, the developer updates that version fix bugs, add new features) and submit his changes under that directory.
At any given point in time, you may want to freeze a version and capture a snapshot of the software as it is at this stage of the development. This generally corresponds to the official versions of your software, for example, the ones you will deliver to your clients. These snapshots are located under the tags directory of your project.
Finally, it is often useful to create, at some point, a new line of development for your software. This happens, for example, when you wish to test an alternative implementation in which you have to modify your software but you do not want to submit these changes to the main project until you decide if you adopt the new solution. The main team can then continue to work on the project while other developer work on the prototype. You would put these new lines of development of the project under a directory called branches.
Хобот: После завершения каждого спринта в Agile мы выпускаем частично поставляемый продукт. Эти релизы хранятся в багажнике.
ветви: все коды параллельных разработок для каждого текущего спринта хранятся в ветвях.
Теги: Каждый раз, когда мы выпускаем частично поставляемую бета-версию продукта, мы делаем для него тег. Это дает нам код, который был доступен на тот момент, что позволяет нам вернуться в это состояние, если это потребуется в какой-то момент во время разработки.
Это конкретный рабочий процесс ваш, он не применим в целом.
Для людей, знакомых с GIT, master в GIT эквивалентен транку в SVN.
Ветвь и тег имеют одинаковую терминологию как в GIT, так и в SVN.
Вот хорошая статья, на которую я наткнулся, в которой объясняется, как и когда использовать ствол, ветвь и теги. Раньше я не использовал систему управления версиями, но эта статья упростила ее понимание для такого новичка, как я. Изо дня в день с Subversion