Чи добре в потоці GitHub базувати функціональну гілку на іншій гілці функцій?

Ми використовуємо GitHub Flow у своєму проекті, і більшу частину часу ми відкриваємо нову гілку функцій від master , робимо там певну роботу, відкриваємо PR, переглядаємо код та об'єднуємось у master .

Однак моя поточна робота залежить від іншого питання, над яким над цим працює feature-branch-A. Це кошерніше створити мою гілку з тієї іншої гілки чи це проти духу GitHub Flow?

Альтернативою було б базувати мою гілку на головному та злитті в змінах feature-branch-A(часто).

Який варіант є кращим у потоці GitHub?

Ось робочий процес, який я дотримуюся, коли я відгалужуюсь від функції функції:

1. Створити feature-branch-Bзfeature-branch-A
2. Працювати на feature-branch-B
3. Якщо feature-branch-Aпісля розгалуження додано більше комісій, перейдіть feature-branch-Bнаfeature-branch-A
4. Закінчіть роботу feature-branch-Bі дочекайтеся, поки feature-branch-Aоб’єднається master.
5. Після того, як feature-branch-Aзливається master, перебазуватися feature-branch-Bнаmaster
6. Об'єднайтесь feature-branch-Bуmaster

Дотримуючись вищезазначеного робочого процесу, виявиться, що ви розгалужувались masterпісля того, як feature-branch-Aбули об'єднані. Вам не потрібно чекати, поки feature-branch-Aоб’єднається, щоб розпочати роботу feature-branch-B. Однак ви отримаєте чисту історію без складних дерев.

Я думаю, що це цілком нормально, якщо ви створюєте цю функцію за іншою функцією.

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

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

В ідеалі всі гілки зливаються назад до кодової лінії, з якої вони були об'єднані. Зазвичай це злиття від основної лінії (в git-flow це dev). Позначте гілки гілки та злиття з dev, звільнення гілки та злиття з dev (з додатковим об'єднанням у master). Гарячі виправлення гілки та злиття з головного (з цим додатковим злиттям назад до dev).

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

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

1. відділення від функції
2. вивчити ідею
3. злиття для функції

Однак цього ви хочете уникнути:

1. відгалуження від необхідної функції
2. робота над кодом
3. злиття з dev, коли необхідна функція завершена
4. перевірити функціональність (і додаткові комісії) у галузі функцій
5. злиття до дев

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

Однак якщо це нова функція, яка залежить від коду, який ще не знайдений у програмі Dev, потік має бути таким:

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

Зауважте, що це починається з гілки від dev і закінчується злиттям у dev.

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

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

Це забезпечує найбільш стабільний набір гілок і код.

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

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

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

Однак, суворого правила проти цього немає. Це лише зразки та найкращі практики.

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

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