Кожен раз, коли починається новий проект, зазвичай має сенс почати, виконуючи пряму майстерність, поки у вас щось "стабільне", а потім ви почнете працювати у філіях.
Принаймні, це я нормально роблю. Чи є спосіб негайно запустити гілки з другого комітету? Чи є сенс робити це так? Очевидно, що "Початковий комітет" завжди буде головним, але після цього, коли я буду знати, що саме час приступити до створення гілок для нових функцій?
Відповіді:
Відразу.
Ключовим є питання, що таке політика щодо Master. З мерзотником, як правило, політика філії на Master є працездатна реліз стабільною. Іноді Master є "основною лінією", де гілки робляться з об'єднаних до об'єднаних до гілок випуску. Це два різні рольові / політичні підходи.
Люди часто є джерелом помилок, щоб люди міняли роль або політику частини галузі шляхом проекту. Солоному розробнику простіше повідомити про ці зміни учасникам, але намагаючись змусити з десяток програмістів усвідомити: "Майстру зараз 1.0, будь ласка, використовуйте функції філій, а не всі, хто до цього натискає".
Я торкнувся вище політичного підходу. Політика Master є те , що вона є працездатний релізом стабільного. Перевірка невеликих поступових змін у цьому означає, що у вас немає чогось стабільного для зберігання . Якщо не перевіряти невеликі зміни, це суперечить "безлічі невеликих (але повних) чеків", яка, як правило, є найкращою політикою (і заохочується легким розгалуженням).
З точки зору ролей, ви почали з головного, основного, випускного, технічного обслуговування та розробки, а потім деякий момент вниз дорогою роль розвитку та обслуговування рухається до гілок. Це ще раз означає зміну того, що дозволено на master і може збити з пантелику дописувачів щодо того, куди належать речі. Це також може (трохи) плутати історію галузей, заохочуючи великі комісії, що означають більші та складніші для розуміння злиття.
Ключові ролі та політики у галузях прості та послідовні з самого початку.
Цю "галузь щодо зміни політики" можна побачити у шаблонах розгалуження . Ідею кожної гілки, яка має ролі, можна прочитати в розширених стратегіях розгалуження SCM . Обидва вони дуже добре читають.
В основному є дві ситуації, коли ти зазвичай хочеш почати працювати з галузями:
коли вам або вашій команді належить запустити нову функцію, яка має найменший шанс не бути доданою до наступного випуску (який може бути першим випуском коли-небудь), тоді розпочніть розробку в окремій галузі функції
коли вам потрібно надати виправлення серйозних помилок до останнього випуску, і ви хочете створити нову версію помилок, що містить лише ці виправлення, але не має нових розроблених (і, мабуть, нестабільних) функцій
Для таких рішень я вважаю, що корисно завжди думати над «новими можливостями» або «виправленнями», з тієї точки, де у вас є перша версія програми, що можна скласти / запустити.
Майкл Пірс перераховує чотири причини зміни у своїй знаменитій книзі, але я б поставив "оптимізувати ресурси" під "новою галуззю функцій" (для нефункціональної функції) та "покращення дизайну" більшість разів під "новою гілкою". , оскільки IMHO ніколи не повинен вдосконалювати дизайн, коли це не призначене для полегшення реалізації певної функції.
Якщо ви слідуєте за git-flow - і, чесно кажучи, я вважаю, що ви божевільні, якщо ви використовуєте Git і не використовуєте цю модель розгалуження - тоді вам ніколи не слід брати на себе зобов’язання, masterпоки ви насправді не готові до публічного релізу.
Вашим першим зобов’язанням masterмає стати порожнє сховище. Наступним зобов’язанням masterслід стати об'єднанням з developфілії або відділенням тимчасового випуску, і воно має бути стабільним, перевіреним та готовим до розгортання (якщо це програма) або публічного розповсюдження (якщо це бібліотека).
Там є інші моделі розгалуження для Git, але більшість з них є похідними від старіших моделей централізованого SCM і може привести до серйозних проблем в середовищі DVCS. Вам не потрібно насправді використовувати розширення ГИТ-потоку, і вам не обов'язково потрібні всі ці релізи / виправлення / повнометражних гілки, але голі кістки є developі master, і нестабільний код йде в develop.
master. Пам'ятайте, що masterце не щось особливе для git, воно не повинно бути там. Ви можете просто мати галузь розвитку, поки не захочете зробити реліз.
Ніл Форд із думок виступає за використання функціональних перемикань на розгалуження, щоб уникнути проблеми "злиття пекла". Розглянемо випадок, коли два програміста щоденно зливаються з основної гілки, а один із них вносить значні зміни протягом декількох тижнів, а потім здійснює. Інший програміст міг би дуже добре потрапити в пекло злиття. Щоб уникнути цієї проблеми, Ford рекомендує "принести біль вперед" (добре відомий спритний атрибут), маючи лише одну гілку і дотримуючись її щодня. Додаткова функція додається за допомогою перемикачів функцій, які відключають функцію до її повного тестування.
Ця методологія, здається, найкраще працює в середовищі, що реалізує постійну доставку, оскільки проблеми з зобов'язанням будуть негайно виявлені.
Минуло два роки з часу останньої відповіді на це питання, і я думаю, зараз історія змінюється. Для мене відповідь - "Кожен раз, коли ви використовуєте управління вихідним кодом для відстеження версій".
Для розробки, відстеження версій проектів за допомогою керування вихідним кодом не завжди працює. (наприклад, використовуючи npm для управління залежністю та вкажіть семантичні версії за допомогою '^'). У цьому випадку артефакти проекту змінюються щоразу, коли відбувається складання, при цьому не потрібно відповідати змінам вихідного коду щоразу. Для вирішення подібних нових викликів деякі команди вирішили створити «артефакти», збережені в системі управління артефактами (наприклад, JFrog Artifactory) для трекових версій проекту.
Очевидно, що у вас вже є контроль версій артефактів, ви не перетягуватимете «виробничий код» з гілки GIT і не збиратиметесь / розгортаєте до виробництва, а замість цього звертаєтесь до системи управління артефактами для прямого запуску версій для розгортання. У таких випадках поняття "гілка випуску" раптово втрачає своє значення. І кожен раз, коли ваша команда вирішить не пов’язувати гіт-гілку з версією випуску, виконувати / наштовхувати безпосередньо на майстер стає знову обгрунтованим вибором: вона стає як гілка за замовчуванням всякий раз, коли репо клонується, отже, автоматично надається семантика загальновизнаною та добре передається зміни. Тим не менш, як свідчить прийнята відповідь, вам, ймовірно, слід очолити призначену роль галузям, включаючи головний, і використовувати ці гілки лише для тих конкретних ролей.
Нарешті, я проходжусь на крок далі і пропоную використовувати майстер як галузь розвитку в проектах, у яких є лише кілька основних комітетів. Це стосується моєї команди та, мабуть, однаково для більшості магазинів мікропослуг. Здійснення майстра знімає процес передачі змін і, можливо, уникає "злиття пекла" при роботі над функціями в декількох спринтах. Крім того, код у головній гілці навіть не повинен «працювати», автоматизований процес складання / тестування скаже вам, що пішло не так, і все одно досить просто перевірити історію git та зв’язатися з автором, який порушив збірку / тест :-)
Я збираюся зайняти радикальну позицію: розглядаю кожну ідею. По-перше, гілки з git дешеві, основна вартість гілки - це запам’ятовування, для чого це потрібно. Я також погоджуюся з тим, що першим зобов’язанням засвоїти є кандидат у звільнення. Я рекомендую почати з доказування галузі поняття. Коли ви довели свою концепцію, ви можете об'єднати її з порожньою галуззю розробки або переписати, залежно від того, наскільки хороша ваша перша спроба. з цього моменту ви відгалужуєте розробку для кожної помилки, функції, абстракції тощо.