Как поставить разные версии вашей библиотеки под контроль версий? Вы используете теги? Или ветки? Или другой метод?

Я недавно начал ставить свой код под контроль версий (в лаборатории, где я работаю, под SVN, и мои собственные коды в github (очевидно, с git)). Перед использованием контроля версий я делал что-то подобное. У меня была папка с названием библиотеки, внутри многих папок с номером версии. Каждый раз, когда я хотел начать работать с более новой версией, я делал копию последней версии, менял имя на новую версию и начинал внедрять.

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

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

Способ 1: использование тегов

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

Способ 2: версии ветвления

В этом методе основной ветвью будет ветвь разработки. Время от времени, когда создается стабильная версия (скажем v1.2.0), вы создаете ветку для этой версии и никогда не фиксируете ее. Таким образом, если вы хотите скачать определенную версию, вы получите код из этой ветки. Хотя я и сказал, что вы никогда не фиксируете его, возможно, можно исправить ошибки и зафиксировать ветку старой версии, чтобы сохранить работоспособность старой версии. Например, если текущая версия есть v2.0, но есть люди, которые хотят ее использовать v1.2, вы можете получить другую ветку v1.2, а именно v1.2.1и зафиксировать исправления ошибок, или просто оставить версию такой же, как v1.2и просто зафиксировать исправления ошибок.

Таким образом, ветви будут выглядеть так:

                  v1.2.1  v1.2.2
                 /       /
 v1.0.0   v1.2.0---------     v2.0.0
/        /                   /
-------------------------------------- dev

Таким образом, у вас есть ветки для каждого второстепенного обновления версии. (Обратите внимание, что на графике выше v1.2.1 и v1.2.2 или созданные после выпуска v2.0.0, поэтому они не были частью разработки между v1.2.0 и v2.0.0. Думайте об этом как о поддержке более старых версий)

Способ 3: ветвление развития

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

В этом случае ветви будут выглядеть так:

 ________  ____  ________________  _____ dev
/        \/    \/                \/
---------------------------------- latest_version

Возможно, это нужно сделать вместе с тегами, верно?

Вопрос!

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

Теги и ветви не являются взаимными, вы можете (и IMO обычно должны) использовать их оба. Теги предназначены для обозначения вех в развитии. Например , вы открываете отделение для версии 1.2 своего продукта, и вы отметите v1.2 Beta, RC1, RC2, Final(а затем, в случае необходимости, и SP1т.д.) с бирками на той же ветке.

Лично я предпочитаю метод 2 в качестве подхода по умолчанию (хотя я стараюсь избегать нескольких уровней веток, чтобы максимально упростить жизнь). Метод 1 просто не сработает в реальной жизни - тегов недостаточно, вам нужны ветки. И метод 3 негибкий в том, что он имеет только одну стабильную версию в любое время, поэтому (если вы не объедините его с методом 2), вы не сможете поддерживать несколько (последнюю и более старую) версии параллельно. Это требуется практически для всех проектов в реальной жизни - пока вы работаете над версией 2, вы все равно должны публиковать исправления / обновления для v1.9 и часто даже более ранние версии. Конечно, многое зависит от типа приложения. Мы разрабатываем веб-приложение, поэтому в каждый конкретный момент времени существует только одна производственная версия, но все же мы часто манипулируем 3 разными версиями (одна в производстве, один находится в UAT, готовится к развертыванию, один - самая последняя версия в транке). Это может стать более сложным для настольного / клиентского приложения с несколькими более старыми версиями, которые используются - и поддерживаются - параллельно.

У меня была папка с названием библиотеки, внутри многих папок с номером версии.

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

Теперь различные техники, которые вы перечисляете, кажутся одинаково правильными. Вы можете прочитать очень подробную статью, Source Control Done Right , которая включает информацию о тегах и ветвях.

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

Со своей стороны, я бы по умолчанию использовал комбинацию методов 1 и 3, то есть разрабатывал в компоненте или в ветви разработки до тех пор, пока компонент не будет готов к производству, а затем снова слился бы в транк. Таким образом, транк всегда представляет текущее состояние стабильной, используемой разработки и может быть безопасно связан проектами svn: external. Когда вы выпускаете версию, пометьте ее.

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

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

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