В даний час наша компанія використовує просту модель розгалуження магістралі / випуску / виправлень і радить поради щодо того, які моделі розгалуження найкраще підходять для вашої компанії або процесу розвитку.
Моделі робочих процесів / розгалуження
Нижче наведено три основні описи цього, що я бачив, але вони частково суперечать один одному або не заходять досить далеко, щоб розібратися з подальшими проблемами, з якими ми стикалися (як описано нижче). Таким чином, наша команда поки що за замовчуванням не настільки великі рішення. Ви робите щось краще?
Злиття та повторне звільнення (заплутане по відношенню до послідовної історії)
Потрібно
pull --rebaseабо чекати, коли з’єднатись з основною лінією, поки ваше завдання не буде закінчено? Особисто я схиляюся до злиття, оскільки це зберігає візуальну ілюстрацію того, на якій основі було розпочато і закінчено завдання, і я навіть віддаю перевагуmerge --no-ffдля цієї мети. Однак він має й інші недоліки. Також багато хто не усвідомив корисну властивість злиття - те, що воно не є комутативним (об'єднання гілки теми в головний не означає злиття головного в тему гілки).Я шукаю природний робочий процес
Іноді помилки трапляються, оскільки наші процедури не охоплюють конкретну ситуацію простими правилами. Наприклад, виправлення, необхідне для попередніх випусків, звичайно, має бути засноване на достатній низці, щоб можна було об'єднати вгору за всіма гілками (чи достатньо зрозумілим є використання цих термінів?). Однак трапляється, що виправлення перетворює його на майстра до того, як розробник зрозуміє, що його слід було розмістити далі за течією, і якщо це вже натиснуто (що ще гірше, об'єднане чи щось на його основі), то залишилася опція - вибирання вишні, з пов'язані з цим небезпеки. Які прості правила типу таких ви використовуєте?Також в це включено незграбність однієї тематичної гілки, обов'язково виключаючи інші галузі тем (припускаючи, що вони розгалужені із загальної базової лінії). Розробники не хочуть закінчити функцію, щоб почати ще одне відчуття, як код, який вони тільки що написали, вже не існує
Як уникнути створення конфліктів злиття (через вишню)?
Як виглядає вірний спосіб створити конфлікт злиття - це вишня між гілками, їх більше ніколи не можна об’єднати? Чи застосувати одне і те ж зобов’язання у зворотному порядку (як це зробити?) В будь-якій галузі, можливо, вирішити цю ситуацію? Це одна з причин, що я не наважуюся наполягати на значному об'єднанні робочого процесу.
Як розкласти на актуальні гілки?
Ми розуміємо, що було б чудово зібрати готову інтеграцію з тематичних галузей, але часто робота наших розробників не є чітко визначеною (іноді такою простою, як "розколювання"), і якщо якийсь код уже перейшов у "різне" тему, її не можна вивозити звідти знову, відповідно до вищезазначеного питання? Як ви працюєте з визначенням / затвердженням / закінченням / випуском галузей тем?
Правильні процедури, такі як перегляд коду та його закінчення , звичайно, були б чудовими.
Але ми просто не можемо тримати речі недостатньо розметаними для управління цим - будь-які пропозиції? інтеграційні галузі, ілюстрації?
Нижче наведено перелік пов’язаних питань:
- Які є хороші стратегії, щоб дозволити розгорнуті програми можна виправити?
- Опис робочого процесу для використання Git для внутрішньої розробки
- Git робочий процес для розробки корпоративного Linux ядра
- Як ви підтримуєте код розробки та виробничий код? (спасибі за цей PDF!)
- управління випусками git
- Git Cherry-pick vs Merge Workflow
- Як вишнево підбирати кілька комірок
- Як ви з’єднуєте селективні файли з git-merge?
- Як вишня вибирати діапазон комітетів і зливатися в іншу гілку
- ReinH Git Workflow
- git робочий процес для внесення змін, які ви ніколи не відштовхуватиметься від початку
- Вишневий вибір злиття
- Правильний робочий процес Git для комбінованої ОС та приватного коду?
- Підтримка проекту з Git
- Чому не можна змінювати файл злиття Git із модифікованим батьківським / головним.
- Гіт розгалуження / звільнення передового досвіду
- Коли "git pull --rebase" приведе мене до неприємностей?
- Як DVCS використовуються у великих командах?
Також перевірте, що пише Plastic SCM щодо розробки завдань , і якщо Plastic не є вашим вибором, вивчіть модель розгалуження nvie та його підтримуючі сценарії .