Як ви ставите різні версії вашої бібліотеки під контроль версій? Ви використовуєте теги? Або гілки? Або інший метод?

Нещодавно я почав ставити свій код під контроль версій (у лабораторії, де я працюю, під 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, ви все одно можете публікувати виправлення / оновлення для версії 1.9, а часто навіть і більш ранніх версій. Багато залежить від типу програми курсу. Ми розробляємо веб-додаток, тому в будь-який момент часу існує лише одна виробнича версія, але ми часто жонглюємо трьома різними версіями (одна у виробництві, один в UAT готується до розгортання, один - остання версія на магістралі). Це може бути набагато складнішим для додатків для настільних ПК / клієнтів, де паралельно використовуються і підтримуються кілька старих версій.

У мене була папка з назвою бібліотеки, всередині багатьох папок з номером версії.

Як зазначаєте, це фактично неправильний підхід, оскільки у вас вже є контроль версій для ... контролю над версіями.

Тепер різні методи, які ви перераховуєте, здаються однаково правильними. Ви можете прочитати дуже детальну статтю « Виконання контролю над джерелами» , яка містить інформацію про теги та гілки.

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

Зі свого боку, я б використовував комбінацію методів 1 і 3 за замовчуванням, тобто розробляти в особливості або галузі розробки, поки функція не готова до виробництва, а потім об'єднається назад у магістраль. Таким чином, магістраль завжди представляє поточний стан стабільної, використовуваної розробки і може бути безпечно пов'язаний svn: зовнішніми проектами. Коли ви випустите версію, позначте її.

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

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

Дивіться мою відповідь тут для отримання додаткової інформації про використання розгалуження для підтримки декількох версій випуску.