Які переваги використання розгалуження як сольного розробника?


117

По-перше, мені відомо, що про VCS як соло розробника було задано багато питань, але вони часто занадто широкі. Це стосується лише розгалуження, і досі воно позначене як дублікат ... передбачуваний дублікат знову ж таки позначений як ще один дублікат іншого питання, який занадто широкий і не стосується розгалуження конкретно. Ось як моє запитання унікальне.

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


14
Вибачте, я визнаю, що я не дуже досвідчений в моделі StackExchange, але чи варто розуміти, що "найкращі практики" або будь-яке інше питання, на яке немає жодної, детермінованої відповіді, нахмурене, або навіть ні дозволено обговорювати? Я бачу безліч прикладів на основі думки вагомих питань навіть у "пов'язаному" розділі цього питання, наприклад, softwareengineering.stackexchange.com/questions/286928 або softwareengineering.stackexchange.com/questions/132730
flatterino

8
Хоча я погоджуюся з Людиною, що це питання не є точним дублікатом (відмінності в області масштабів є значними), але дуп цільового питання про дуп, пов’язаний із гнатом, має відповіді на тему, яка вас цікавить - чи є щось таке відповіді не охоплювали, про що ви хочете дізнатися більше?
jrh

4
Думаю, що, хоча це питання охоплює цю тему, воно робить це дотично (користувач задає 3 різні питання, пов'язані з різними аспектами розгалуження), і насправді саме це питання було закрито, оскільки воно було занадто широким саме з цієї причини. Я сподівався розпочати дискусію про цю дуже специфічну особливість VCS в цьому подібному конкретному контексті. Щоб відповісти на ваше запитання, тут було згадано кілька його аспектів (у відповідях та коментарях до цих відповідей), які не вказані у відповідях на питання, на яке ви посилалися. Дякую всім за ваш внесок.
flatterino


3
Ден, знову ж таки ... питання, яке ви пов’язали, задає питання: "Як єдиний розробник, якими функціями Git чи GitHub я можу скористатися, що могло б мені зараз принести користь?". Можливою відповіддю на це питання, серед інших, може бути "розгалуження". Це не було б відповіддю на моє запитання. З тієї ж причини він був закритий як занадто широкий. Будь ласка, прочитайте пояснення вгорі мого питання. Мені довелося 3 рази редагувати свою публікацію ...
flatterino

Відповіді:


199

Переваги в основному такі ж, як і для груп розробників. Використовуючи головну гілку, яка завжди готова до випуску, та функції гілок для розробки нових функцій, ви завжди можете звільнити головну. Знайти важливу помилку під час роботи над функцією? Переключіть гілку, виправте, відпустіть, перемкніть назад і продовжуйте розвиватися.

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

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


1
Саме так. Групи теж не повинні використовувати гілки - я працював для команд, які цього не зробили. Зрозуміло, що це було здебільшого через незнайомство з git, і всі ці команди навчилися використовувати гілки, оскільки з’явились проблеми з їх використанням, але ці проблеми також стосуватимуться соло-розробника.
KRyan

42

Тривалий розвиток

Розгалуження для однієї команди може бути корисною для довготривалої розробки, яка в іншому випадку не вписується у ваш цикл випуску.

Ви можете взяти гілку, щоб змінити багатомісячне проміжок часу і все одно мати можливість регулярно виправляти будь-які виправлення помилок або зміни з вашої основної гілки через рівні проміжки часу.

Це має перевагу перед «перемикачами» в одній гілці тим, що ваша основна гілка завжди знаходиться в стані розгортання, і ви гарантуєтесь, що нічого в довготривалій функції не вплинуло на інший, раніше перевірений код.

Експериментальні особливості

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


16

Я використовую його для критичного обслуговування веб-сайту. Я єдиний розробник, але в мене є майстер, розробляти та випускати галузі.

Мій процес роботи з налаштування сайту виглядає приблизно так:

  1. Зробіть працездатну головну гілку. Зробіть початкову фіксацію

  2. Каса розвивати відділення. Нічого не робіть, розробляйте функції тестового буфера для злиття в master.

  3. Відділення випуску замовлення Зашифруйте свою проблему, коли її буде зроблено, виведіть її на розробку, подивіться, чи виникають якісь проблеми, з’єднайте конфлікти тощо ... виправте їх.

Коли достатньо питань об'єднано у розробку для випуску та тестування на стабільність розвитку, потягніть на розробку.

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

Таким чином ви отримуєте повну колекцію тестування в розробці, де ви можете перевірити стабільність, проблеми і т. Д ... без того, щоб ризикувати травмувати Майстра і не потрібно відмовлятися від зобов'язань, якщо вони були шкідливими.

Також, використовуючи окремі гілки для здійснення зобов'язань, ви можете «залишити» роботу, яку ви вже зробили, почати свіжу з чогось іншого, щоб виправити більш нагальну проблему і скоріше виконувати це.

У реальному житті у мене зазвичай є одна галузь випуску, і я розвиваю її, а потім перетворюю на майстер. Іноді це нудно, але раз на два місяці принаймні мені доводиться кидати роботу над краплею капелюха, тому що хтось мав уявлення про те, що я повинен зробити RightNow ™, і таким чином я можу швидко повернутися до базового стану, зробити річ а потім продовжуйте там, де я був. Тим більше, що для великих проектів, що займають кілька тижнів, це бог, що я можу швидко перемикати гілки.

Розглянемо такий сценарій: Ви завжди працює на головній гілці , і ви повинні AwesomeCodeThing ™ в роботах , що залишає свій майстер філія у відкритій хірургії серця і YugeBug ™ вискакує , що потребує в термінової фіксації в іншому випадку тисячі користувачів будуть скаржитися вам про BigProblems ™
єдиний спосіб швидко вирішити свою проблему за такого сценарію,

  1. перевірити свої попередні зобов'язання,
  2. подивіться, коли була остання стабільна комісія (проклинання необов’язково)
  3. відкотись до цього коміту
  4. виправити, підштовхнути виправлення до виробництва
  5. вирішити всі конфлікти та проблеми, які ви зараз намагаєтеся повернути до статусу AwesomeCodeThing ™
  6. відмовтеся, плачте і починайте працювати над собою.

Якщо ви використовуєте гілки:

  1. Майстер замовлення
  2. створити відділення UrgentFix ™ та виправити речі
  3. перетягніть UrgentFix ™ у майстер
  4. поштовх до виробництва
  5. Об'єднайте майстра в розробку
  6. Об'єднання перетвориться на AwesomeCodeThing ™
  7. випити пива і продовжувати працювати.

13
Добування пива перед продовженням необов’язкове.
JamesB

4
@JamesB Отримання пива перед початком - необов’язкове :)
Chris Cirefice

4

Гілки полегшують роботу над декількома функціями одночасно, що може бути дуже корисно, коли пріоритети змінюються під час проекту.

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

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

Що стосується власне процесу, я вважаю, що git flow працює добре. Чит-лист Даніела Куммера - це чудовий ресурс, на який варто звернути увагу, навіть якщо ви не використовуєте git.


2

Як згадують інші афіші, переваги істотно схожі на роботу в командах: Можливість самостійно розробляти та тестувати функції, підтримувати окрему головну гілку для виправлень / виробничих розгортань, експериментувати.

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

Тим НЕ менше, якщо у мене є якісь - або сумніви щодо приводу змін творю я розширитися і тільки PR / злиття раз гілка веде себе , як і очікувалося , і , як правило , повністю протестовані. Таким чином, якщо я виявлю проблему, для якої відкат - найкращий хід дій, це одна фіксація замість цілого ряду (я ніколи не пам'ятаю синтаксис для відкату серії комітетів, але один - це легко).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.