Як слід контролювати версії мого проекту на GitHub

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

Одне питання, яке у мене виникає, - це контроль над версією . Скажімо, ми розпочали проект. Потім члени команди створили деякі відділення та розвивалися там. Коли ми готові до виробництва, ми з’єднали всі гілки з masterгілками. Наприкінці ми переходимо наживо з версією 1.0.

Тепер ця версія 1.0працює в прямому ефірі, і для цієї версії цього програмного забезпечення виникли деякі проблеми. Ми хотіли б почати розробку версії 1.1, щоб виправити ті проблеми, які ми запровадили, поспішаючи на проект.

Тепер питання таке:

Як ми повинні контролювати версію тут?

Чи слід створити нову гілку для v1.0і зберегти там версію 1.0програмного забезпечення та розробляти на деяких гілках (чи ні), об'єднати їх master, перейти до версії 1.1?

Чи існує умовність для подібних ситуацій?

— буксир
джерело

Відповіді:

Я знайшов (і почав приймати) таку галузеву модель :

Зображення від nvie.com

^{(зображення зі статті)}

У цій статті є багато чудових практик і суворих правил, я дуже рекомендую її.

Цікаві місця:

Основна гілка - це тег, де ви позначите свої версії. Ніяких розробок тут не відбувається. У разі помилки, яка була розгорнута у виробництві, ви виправляєте помилку на гілці виправлення, об'єднуєте назад та додаєте теги до нової версії.
Розвиток відбувається на галузях розвитку та особливостей. Особисто я роблю виправлення помилок на гілці розробок та функцій на гілках функцій.
Коли програмне забезпечення починає доходити до випуску, я відключаюсь до випуску гілки. Гілка випуску - це те, де я роблю останні штрихи. Збігати номери версій, змінювати метадані тощо. І незначні виправлення. Коли він закінчений, я зливаю його в master, тег і називаю його версією.
Дві основні гілки: господар - це «свята гілка»; його HEAD завжди є останнім виробничим кодом, а розробкою є нічна галузь; його HEAD завжди відображає останні (але можливі нестабільні) доповнення до коду.

У вашому конкретному випадку кроки залежатимуть від того, наскільки поспішала ця версія. Якщо це функції були залишені, я б повернувся до версії для розробки та зробив би все це заново. Якщо це помилки у розгорнутій версії, я б відключився до гілки виправлень, виправляв помилки, об'єднував назад та мітку v1.1. Якщо це обоє, я б поправив помилки спочатку, а потім додав функції, як описано вище.

— Тамаш Селей
джерело

Дуже інформативний та детальний. А також досконала практика. Це також має багато сенсу. Маючи майстра для продукту, це просто спрощує обслуговування. Мені такі незнайомі з тегом гілки (чи фіксацією?). Чи можете ви мені дати детальну інформацію про це? як ми можемо зробити відповідно до вищезгаданої моделі?

— буксир

У git ціль мітки - це фіксація. Це означає, що ви говорите: "ось ця фіксація, і я називаю її" v1.3 "відтепер". На практиці це означає, що ви переходите до ведучої гілки, об'єднуєтесь у (тепер стабільну) гілку розробки, здійснюєте фіксування та теги. Тоді ви можете перерахувати всі теги, повернутися до цього коду, якщо вам потрібно переглянути, що було вироблено у минулому випуску. Тегів є трохи більше, ніж це (що корисно для широкомасштабної розподіленої розробки, наприклад, ядро Linux). Якщо вас цікавить, пропоную книгу прогрес .

— Тамас Шелей

ProGit - одна з книг, яку я обов'язково прочитаю з нуля. Поки я читаю лише ті частини, які мені цікаві, щоб виконати роботу. Поки ми розвивались на головній галузі, і я думаю, що я повинен це підтримувати. Але я відкрию іншу гілку, яку називають, productionі буду використовувати її як masterгілку відповідно до вищезгаданої моделі.

— буксир

в той час, як я пробую цю модель, одне з чим я намагаюся: це є деякі підтримуючі гілки, про які йшлося в даній статті, гілках функцій та випусків. може бути кілька майбутніх гілок. Наприклад, FeedbackForm - це одна майбутня галузь, а ContactForm - інша. Я думаю, це нормально для цієї моделі? Чи має бути також кілька гілок випуску? і якщо так, то як мені їх назвати?

— буксир

Перш за все, вам не потрібно дотримуватися цього листа, просто встановили правила, яких ви дотримуєтесь. Робіть те, що найкраще підходить для вас та стилю вашої команди. По-друге, так, гілки з декількома функціями та випусками є нормальними, якщо у вас короткочасний проект з однією функцією та одним випуском :) Іменування відповідно до статті - реліз- * та особливість- *. Я думаю, що ви поставите номер майбутньої версії замість зірочки для випуску та ідентифікатора трекера випуску у випадку гілок функції.

— Tamás Szelei

Що я був свідком більшості часу:

Майстер - це для вас продукт. Врешті-решт, вся ваша майбутня версія x.0 буде на майстер.
Ви створюєте тег / гілку для кожної версії у виробництві, щоб ви могли підтримувати їх для будь-якого клієнта, який цього вимагає.
Об’єднання виправлень з одного чи іншого полягає у вирішенні кожного конкретного випадку.

— xsace
джерело

Спасибі! тому ви вважаєте, що розумно зберігати гілку з назвою v1.0, v1.2 розумно?

— буксир

@tugberk, поки у цій версії існує відповідне програмне забезпечення, є сенс тримати гілки навколо, щоб ви могли швидко відщелити їх, якщо вам потрібна певна гілка виправлення. Коли програмного забезпечення в цій версії більше не існує (більше не підтримується, тому більше роботи не може відбутися), може бути сенс зробити остаточне злиття гілки та видалити її. Ви навіть можете створити остаточну порожню комісію (я це роблю часто на початку відділення), просто сказати "Закриття гілки XXXX", інакше ви не збережете історію філії (reflog може трохи допомогти, але це на сховище)

— Патрік Мевзек