Чи є недоліки в цій моделі розгалуження Git?

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

(Вам не потрібно відповідати на кожне запитання, що б вам не було корисно)

1. Чи використовуєте ви цей чи подібний робочий процес з розгалуженням git?

2. Ви вважаєте це продуктивним підходом?

3. Чи бачите ви недоліки при такому підході? Будь-який потенційний мінус?

4. Якщо ви маєте кращий підхід, чи не заперечуєте ви поділитися або надати посилання на статтю чи дискусію про неї?

Здебільшого це звичайний робочий процес, використовуваний у будь-якому СКС, яким ми користувалися до цього часу. З деякими (CVS, SVN) це важче зробити, а з GIT - тривіально. Однак, у мене є два зауваження:

По-перше, є дві школи думки, коли мова йде про особливості галузей:

1. Об’єднайте їх
2. Побазуйте їх

(1) - це те, що, здається, пропонує стаття. Проблема з об'єднаннями злиття - це так звані Evil Merges . Зокрема, ті, які приєднуються до шляхів розвитку, де функція змінила семантику в одній з гілок, але автоматичне злиття не зможе зафіксувати всі події в коді, що надходять з іншої гілки. Регресії, запроваджені таким чином, важко налагодити. Як користувач GIT, ви, як правило, можете бути більш спокійними щодо регресій, тому що вам доведеться автоматично git bisectзнаходити їх причини. Однак в описуваній ситуації вкажете git bisectна злиття, що вам зовсім не допомагає.

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

Особисто я твердо перебуваю в таборі (2), тому що ціную достовірність git bisectрезультатів більше, ніж потенційну втрату тестового покриття, що легко компенсується за допомогою належної системи CI.

По-друге, я вирішив, що натискання між розробниками рідко є доброю ідеєю. Існують проблеми безпеки, що дозволяють кожному зазирнути у вашу скриньку або запустити локальну службу git-deamon, і, що ще важливіше, в командах, не дуже малих, нагляд може втратити досить швидко.

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

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

В основному це дві основні галузі, masterде розвиваються нові особливості, і toolkit-conversionгалузь. Найважливіше правило просте: робіть у toolkit-conversionгілці лише ті речі, які мають значення для перетворення. Щоразу, коли щось можна зробити в master(старий інструментарій графічного інтерфейсу), я роблю це там і перескладаю свої toolkit-conversionзміни на нову masterголову. Ще одне правило - тримати toolkit-conversionгілку досить короткою. Тому я часто використовую скидання, вишневе виправлення та поправка-фіксація та перезавантаження для склеювання належних менших розмірів до більших (які в кінці мають те саме призначення). Це також добре працює, коли я спробував щось, що не спрацювало, щоб "скасувати" зміну, або після того, як я відновив деякий код з тимчасовим помічником.

Я вирішив не об'єднувати зміни masterв toolkit-conversionгалузь, тому що це значно ускладнить перезавантаження попередніх зобов’язань, щоб зберегти гілку в чистоті та легко переглядати. Також злиття можуть спричинити конфлікти, рішення яких не настільки чіткі, як при збереженні чистої історії.

Звичайно, цей робочий процес має і недоліки. Найголовніше - це те, що він добре працює лише для однієї людини. Коли коли-небудь я змушую натиснути toolkit-conversionгілку після того, як повернути її на голову master, тягнути її до іншого сховища стає важко (автоматичне перезавантаження на відстежуючу гілку часто не вдається з конфліктами).

Зрештою, мій toolkit-conversion гілка залишається короткою, чистою та легкою для огляду. Я не міг собі уявити, щоб це робив подібний потужний, наприклад, з SVN.

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

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

Крім того, це виявилося надійним :).

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

Єдиним невеликим недоліком є ​​те, що потрібно стримувати цей робочий процес і не намагатися приймати ярлики.

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

Чи використовуєте ви цей чи подібний робочий процес з розгалуженням git?

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

Ви вважаєте це продуктивним підходом?

Продуктивний. Як Ви визначаєте продуктивність? Ну, на мій погляд, найважливіше - мати високу якість, принаймні намагатися і досягати кращої якості весь час. Постійне вдосконалення процесу тощо. Якщо ви можете створити якісний код, від цього виграє продуктивність. Отже, питання справді: чи покращує це якість програмного забезпечення? І моя відповідь на це, безумовно, так.

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

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

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

Чи бачите ви недоліки при такому підході? Будь-який потенційний мінус?

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

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

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

Якщо ви маєте кращий підхід, чи не заперечуєте ви поділитися або надати посилання на статтю чи дискусію про неї?

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

Найважливіший момент - почати роботу з git, а решта буде слідувати природним шляхом. Почніть просто і поступово вдосконалюйтесь! Будь креативним!

Ура