Я часто встречал эти слова в обсуждениях Subversion (и, я полагаю, общего репозитория).
Я использую SVN для своих проектов в течение последних нескольких лет, но никогда не понимал полная концепция этих каталогов.
Что они имеют в виду?
Я часто встречал эти слова в обсуждениях Subversion (и, я полагаю, общего репозитория).
Я использую SVN для своих проектов в течение последних нескольких лет, но никогда не понимал полная концепция этих каталогов.
Что они имеют в виду?
Хм, не уверен, что согласен с тем, что тег Ника похож на ветку. Тег - это просто маркер
Багажник strong > будет основной частью разработки, начиная с начала проекта и до настоящего времени.
Филиал будет копия кода, полученная из определенной точки в магистрали, которая используется для внесения основных изменений в код при сохранении целостности кода в магистрали. Если основные изменения работают по плану, они обычно объединяются обратно в ствол.
Тег будет момент времени на стволе или ветке, который вы хотите сохранить. Двумя основными причинами сохранения могут быть то, что либо это основной выпуск программного обеспечения, будь то альфа, бета, RC или RTM, либо это наиболее стабильная часть программного обеспечения до того, как были внесены основные изменения в магистраль.
В проектах с открытым исходным кодом основные ветки, которые не принимаются участниками проекта в магистраль, могут стать основой для вилок - например, полностью отдельных проектов, имеющих общее происхождение с другим исходным кодом.
Поддеревья веток и тегов отличаются от ствола следующими способами:
Subversion позволяет системным администраторам создавать скрипты ловушек, которые запускаются для выполнения при возникновении определенных событий; например, фиксация изменения в репозитории. Типичная реализация репозитория Subversion очень часто обрабатывает любой путь, содержащий «/ tag /», как защищенный от записи после создания; Конечный результат состоит в том, что однажды созданные теги неизменяемы (по крайней мере, для «обычных» пользователей). Это делается с помощью сценариев ловушек, которые обеспечивают неизменность, предотвращая дальнейшие изменения, если тег является родительским узлом измененного объекта.
В Subversion, начиная с версии 1.5, также добавлены функции, относящиеся к «отслеживанию слияния ветвей», так что изменения, зафиксированные в ветке, могут быть объединены обратно в ствол с поддержкой инкрементного «умного» слияния.
Tags
также часто используется для тестирования этапов и проверки обычным пользователем. Это было бы хорошим местом для размещения прототипа (просто некоторые идеи в голове).
- person Jeff Noel; 26.10.2012
trunk
. (* для подробностей я бы рекомендовал взглянуть на ответ @EricZBeard.)
- person apple apple; 03.12.2019
Прежде всего, как указывают @AndrewFinnell и @KenLiu, в SVN сами имена каталогов ничего не значат - «ствол, ветки и теги» - это просто общее соглашение, которое используется в большинстве репозиториев. Не все проекты используют все каталоги (разумно вообще не использовать «теги»), и на самом деле ничто не мешает вам называть их как угодно, хотя нарушение соглашения часто сбивает с толку.
Я опишу, вероятно, наиболее распространенный сценарий использования веток и тегов и приведу примерный сценарий их использования.
Ствол: основное направление развития. Здесь обитает ваш следующий крупный выпуск кода, и, как правило, он содержит все новейшие функции.
Ветви: каждый раз, когда вы выпускаете основную версию, создается ветка. Это позволяет вам исправлять ошибки и выпускать новый выпуск без необходимости выпускать новейшие - возможно, незаконченные или непроверенные - функции.
Теги: каждый раз, когда вы выпускаете версию (финальный выпуск, кандидаты на выпуск (RC) и бета-версии), вы делаете для нее тег. Это дает вам копию кода на определенный момент времени в том виде, в котором он был в этом состоянии, что позволяет вам вернуться и воспроизвести любые ошибки, если это необходимо в прошлой версии, или повторно выпустить предыдущую версию в точности так, как это было. Ветви и теги в SVN легковесны - на сервере он не делает полную копию файлов, а только маркер, говорящий «эти файлы были скопированы в этой ревизии», который занимает всего несколько байтов. Имея это в виду, вы никогда не должны беспокоиться о создании тега для любого выпущенного кода. Как я сказал ранее, теги часто опускаются, и вместо этого в журнале изменений или другом документе уточняется номер редакции при выпуске релиза.
Например, предположим, вы начинаете новый проект. Вы начинаете работать в «стволе», над которым в конечном итоге выйдет версия 1.0.
Как только 1.0.0 будет завершена, вы разветвляете ствол в новую ветку «1.0» и создаете тег «1.0.0». Теперь работа над тем, что в конечном итоге будет 1.1, продолжается в багажнике.
Вы сталкиваетесь с некоторыми ошибками в коде и исправляете их в основной ветке, а затем объединяете исправления в ветку 1.0. Вы также можете сделать обратное и исправить ошибки в ветке 1.0, а затем объединить их обратно в основную ветку, но обычно проекты придерживаются одностороннего слияния только для того, чтобы уменьшить вероятность чего-то пропустить. Иногда ошибку можно исправить только в версии 1.0, потому что она устарела в версии 1.1. На самом деле это не имеет значения: вам нужно только убедиться, что вы не выпускаете 1.1 с теми же ошибками, которые были исправлены в 1.0.
Как только вы обнаружите достаточно ошибок (или, возможно, одну критическую), вы решите выпустить выпуск 1.0.1. Итак, вы создаете тег «1.0.1» из ветки 1.0 и выпускаете код. На этом этапе магистраль будет содержать то, что будет 1.1, а ветка «1.0» будет содержать код 1.0.1. В следующий раз, когда вы выпустите обновление до 1.0, это будет 1.0.2.
В конце концов, вы почти готовы к выпуску 1.1, но сначала вы хотите сделать бета-версию. В этом случае вы, вероятно, сделаете ветку «1.1» и тег «1.1beta1». Теперь работа над тем, что будет 1.2 (или, возможно, 2.0), продолжается в магистрали, но работа над 1.1 продолжается в ветви "1.1".
После того, как вы выпустите финальную версию 1.1, вы сделаете тег «1.1» из ветки «1.1».
Вы также можете продолжать поддерживать 1.0, если хотите, перенос исправлений ошибок между всеми тремя ветвями (1.0, 1.1 и стволом). Важным выводом является то, что для каждой основной версии программного обеспечения, которое вы поддерживаете, у вас есть ветка, содержащая последнюю версию кода для этой версии.
Другое использование веток - для функций. Здесь вы разветвляете магистраль (или одну из веток выпуска) и работаете над новой функцией изолированно. Как только функция будет завершена, вы снова объедините ее и удалите ветку.
Идея заключается в том, что вы работаете над чем-то разрушительным (что может задерживать или мешать другим людям выполнять свою работу), над чем-то экспериментальным (что может даже не получиться) или, возможно, просто над чем-то, что занимает много времени. (и вы боитесь, что если он будет поддерживать выпуск 1.2, когда вы будете готовы к ветвлению 1.2 из магистрали), вы можете сделать это изолированно в ветке. Обычно вы поддерживаете его в актуальном состоянии с помощью ствола, постоянно добавляя в него изменения, что упрощает повторную интеграцию (слияние обратно в ствол), когда вы закончите.
Также обратите внимание, что схема управления версиями, которую я использовал здесь, - лишь одна из многих. Некоторые команды будут выпускать исправления ошибок / выпуски обслуживания, такие как 1.1, 1.2 и т. Д., И основные изменения как 1.x, 2.x и т. Д. Использование здесь такое же, но вы можете назвать ветку "1" или "1". .x вместо «1.0» или «1.0.x». (Кроме того, семантическое управление версиями является хорошим руководством по определению номеров версий).
В дополнение к тому, что сказал Ник, вы можете узнать больше на Потоковые линии: шаблоны ветвления для параллельной разработки программного обеспечения
На этом рисунке main
- магистраль, rel1-maint
- ветвь, а 1.0
- тег.
В целом (взгляд без привязки к инструментам) ветвь - это механизм, используемый для параллельной разработки. SCM может иметь от 0 до n ветвей. Subversion имеет 0.
Транк - это основная ветка рекомендуется Subversion, но вас никоим образом не принуждают к его созданию. Вы можете называть это «основными» или «релизами» или не иметь их вообще!
Филиал представляет собой попытку разработки. Он никогда не должен называться в честь ресурса (например, vonc_branch), но после:
# P5 #
Тег окончательный. Его содержание никогда не должно меняться. НИКОГДА. Всегда. Вы забыли строчку в примечании к выпуску? Создайте новый тег. Устаревший или удалите старый.
Я много читал о «обратном слиянии такого-то и такого-то в таких-то и таких-то ветвях, а затем, наконец, в основной ветке». Это называется рабочий процесс слияния, и здесь нет ничего обязательного. Вам не нужно объединять что-либо из-за того, что у вас есть магистральная ветвь.
По соглашению, магистральная ветка может представлять текущее состояние вашей разработки, но это для простого последовательного проекта, то есть проекта, который имеет:
Потому что с одним (или всеми) из этих сценариев вы получаете четыре «ствола», четыре «текущих развития», и не все, что вы делаете в этих параллельных разработках, обязательно нужно будет снова объединить в «ствол».
В SVN тег и ветка действительно похожи.
Тег = определенный отрезок времени, обычно используемый для выпусков.
Ветвь = также определенный отрезок времени, в течение которого разработка может продолжаться, обычно используется для основных версий, таких как 1.0, 1.5, 2.0 и т. д., а затем, когда вы выпускаете, вы помечаете ветку. Это позволяет вам продолжать поддерживать производственный выпуск, продвигаясь вперед с критическими изменениями в основной ветке.
Магистраль = рабочее пространство разработки, именно здесь должна происходить вся разработка, а затем изменения, объединенные обратно из выпусков ветки.
На самом деле они не имеют никакого формального значения. Папка - это папка для SVN. Это общепринятый способ организации вашего проекта.
Ствол - это то место, где вы держите свое основное направление развития. Папка веток - это то место, где вы можете создавать ветки, которые трудно объяснить в коротком посте.
Ветвь - это копия подмножества вашего проекта, над которым вы работаете отдельно от ствола. Может быть, это для экспериментов, которые никуда не денутся, или, может быть, для следующего выпуска, который вы позже объедините обратно в магистраль, когда он станет стабильным.
А папка тегов предназначена для создания тегированных копий вашего репозитория, обычно на контрольных точках выпуска.
Но, как я уже сказал, для SVN папка - это папка. branch
, trunk
и тег - это просто соглашение.
Я широко использую слово «копировать». SVN на самом деле не делает полные копии вещей в репозитории.
Основная линия - это линия разработки, которая содержит последний исходный код и функции. В нем должны быть последние исправления ошибок, а также последние функции, добавленные в проект.
Ветви обычно используются для выполнения каких-либо действий вне основной ветки (или другой линии разработки), что в противном случае могло бы сломать сборку. Новые функции часто встраиваются в ветку, а затем снова объединяются в магистраль. Ветви часто содержат код, который не обязательно одобрен для линии разработки, от которой они разветвляются. Например, программист может попробовать оптимизировать что-то в ветке и вернуться обратно в линию разработки только после того, как оптимизация окажется удовлетворительной.
Теги - это снимки репозитория в определенное время. На них не должно происходить никакого развития. Чаще всего они используются для копирования того, что было передано клиенту, чтобы вы могли легко получить доступ к тому, что использует клиент.
Вот ссылка на очень хорошее руководство по репозиториям:
Также стоит прочитать статьи в Википедии.
Вот в чем суть разработки программного обеспечения: здесь нет согласованных знаний ни о чем, кажется, у всех все по-своему, но это потому, что это относительно молодая дисциплина в любом случае.
Вот мой простой простой способ,
ствол. Каталог ствола содержит самые последние, одобренные и объединенные работы. Вопреки тому, что многие признались, мой багажник предназначен только для чистой, аккуратной, одобренной работы, а не для области разработки, а скорее для области выпуска.
В какой-то момент времени, когда кажется, что ствол полностью готов к выпуску, он помечается и освобождается.
ветки - каталог ветвей содержит эксперименты и текущую работу. Работа в ветке остается там до тех пор, пока не будет одобрено включение в магистраль. Для меня это та область, где делается вся работа.
Например: у меня может быть ветвь iteration-5 для пятого раунда разработки продукта, возможно, ветвь prototype-9 для девятого раунда экспериментов, и так на.
теги - каталог тегов содержит снимки утвержденных веток и выпусков магистрали. Каждый раз, когда ветвь утверждается для слияния с основной ветвью, или когда из ствола производится выпуск, с тегами создается моментальный снимок утвержденной ветви или выпуск основной ветви.
Я полагаю, что с помощью тегов я могу довольно легко прыгать вперед и назад во времени к интересующим точкам.
Я нашел этот отличный учебник по SVN, когда искал веб-сайт автора OpenCV 2 Поваренная книга по программированию приложений компьютерного зрения, и я подумал, что должен поделиться.
У него есть руководство о том, как использовать SVN и что означают фразы «ствол», «тег» и «ветвь».
Цитируется непосредственно из его учебника:
Текущая версия вашего программного проекта, над которым в настоящее время работает ваша команда, обычно находится в каталоге под названием trunk. По мере развития проекта разработчик обновляет эту версию, исправляет ошибки, добавляет новые функции и отправляет свои изменения в этот каталог.
В любой момент времени вы можете заблокировать версию и сделать снимок программного обеспечения на данном этапе разработки. Обычно это соответствует официальным версиям вашего программного обеспечения, например, тем, которые вы доставляете своим клиентам. Эти снимки находятся в каталоге тегов вашего проекта.
Наконец, в какой-то момент часто бывает полезно создать новую линию разработки для вашего программного обеспечения. Это происходит, например, когда вы хотите протестировать альтернативную реализацию, в которой вам нужно изменить свое программное обеспечение, но вы не хотите отправлять эти изменения в основной проект, пока вы не решите, принимаете ли вы новое решение. После этого основная команда может продолжить работу над проектом, в то время как другие разработчики будут работать над прототипом. Вы бы поместили эти новые направления развития проекта в каталог под названием филиалы.
Каталог магистрали - это каталог, с которым вы, вероятно, наиболее знакомы, поскольку он используется для хранения самых последних изменений. Ваша основная кодовая база должна быть в багажнике.
Каталог веток предназначен для хранения ваших веток, какими бы они ни были.
Каталог тегов в основном предназначен для тегирования определенного набора файлов. Вы делаете это для таких вещей, как выпуски, где вы хотите, чтобы «1.0» был этими файлами в этих ревизиях, а «1.1» - этими файлами в этих ревизиях. Обычно вы не изменяете теги после того, как они созданы. Для получения дополнительной информации о тегах см. Глава 4. Ветвление и Слияние (в Контроль версий с Subversion).
Одна из причин, по которой у всех несколько разные определения, заключается в том, что Subversion реализует нулевую поддержку веток и тегов. Subversion в основном говорит: Мы рассмотрели полнофункциональные ветки и теги в других системах и не нашли их полезными, поэтому мы ничего не реализовали. Просто сделайте копию в новый каталог с именем соглашением вместо. Тогда, конечно, каждый волен иметь немного разные условности. Чтобы понять разницу между реальным тегом и соглашением о простом копировании + именовании, см. Запись в Википедии Теги и ветки Subversion.
Тег = определенный отрезок времени, обычно используемый для релизов
Я думаю, это то, что обычно подразумевают под «тегом». Но в Subversion:
На самом деле они не имеют никакого формального значения. Папка - это папка для SVN.
что меня сбивает с толку: система контроля версий, которая ничего не знает о ветвях или тегах. С точки зрения реализации, я думаю, что Subversion способ создания «копий» очень умен, но мне нужно знать об этом, я бы назвал дырявая абстракция.
Или, возможно, я просто слишком долго использую CVS.
Я думаю, что некоторая путаница возникает из-за разницы между концепцией тега и реализацией в SVN. Для SVN тег - это ветвь, которая является копией. Изменение тегов считается неправильным, и на самом деле такие инструменты, как TortoiseSVN, предупредят вас, если вы попытаетесь изменить что-либо с ../tags/ .. в пути.
Я не совсем уверен, что такое «тег», но ветвь - довольно распространенная концепция управления версиями.
По сути, ветка - это способ работать над изменениями кода, не затрагивая транк. Допустим, вы хотите добавить новую довольно сложную функцию. Вы хотите иметь возможность фиксировать изменения по мере их внесения, но не хотите, чтобы они влияли на магистраль, пока вы не закончите работу с этой функцией.
Сначала вы создадите ветку. По сути, это копия ствола на момент создания ветки. Затем вы будете выполнять всю свою работу в ветке. Любые изменения, внесенные в ветку, не влияют на магистраль, поэтому магистраль по-прежнему может использоваться, позволяя другим продолжать работать там (например, исправлять ошибки или небольшие улучшения). Как только ваша функция будет готова, вы должны интегрировать ветку обратно в магистраль. Это переместит все ваши изменения из ветки в ствол.
Есть несколько шаблонов, которые люди используют для веток. Если у вас есть продукт, у которого одновременно поддерживается несколько основных версий, обычно каждая версия является ветвью. Там, где я работаю, у нас есть отдел контроля качества и производственный отдел. Перед выпуском нашего кода для QA мы интегрируем изменения в ветвь QA, а затем выполняем развертывание оттуда. При выпуске в производственную среду мы интегрируемся из ветви QA в производственную ветвь, поэтому мы знаем, что код, работающий в производственной среде, идентичен тому, что тестировал QA.
Вот запись в Википедии о ветках, поскольку они, вероятно, объясняют вещи лучше, чем я . :)
Багажник: после завершения каждого спринта в Agile мы выпускаем частично готовый к отправке продукт. Эти релизы хранятся в багажнике.
Ветви: все коды параллельных разработок для каждого текущего спринта хранятся в ветвях.
Теги: каждый раз, когда мы выпускаем бета-версию продукта с частичной доставкой, мы делаем для него тег. Это дает нам код, который был доступен на тот момент, что позволяет нам вернуться в это состояние, если это потребуется в какой-то момент во время разработки.
Для людей, знакомых с GIT, master в GIT эквивалентен транку в SVN.
Ветвь и тег имеют одинаковую терминологию как в GIT, так и в SVN.