Чи краще об’єднати "часто" або лише після завершення зробити велике об'єднання гілок функцій?

Скажімо кілька галузей розробляються, Aі B, а також крок за кроком гілка «виправлена помилка» C.

Тепер Cуже «закінчено» і злилося в майстер. Aі Bвони все ще знаходяться в розробці, і їх не буде виправлено до (можливо), інша гілка виправлення помилок об'єднана в головний.

Це гарна ідея Cякнайшвидше об'єднатись у нові функції гілок? Так що нові функції залишаються максимально наближеними master? Або краще дозволити новій функції розвиватися у власному «світі», лише зливаючись у головний, коли вони закінчені?

Так чи інакше виникнуть конфлікти, тому на їх виправлення потрібно витратити час.

Чим довше живе гілка, тим більше вона здатна відходити від основної гілки та месіє, і чим складніше отримане злиття буде, коли воно остаточно закінчено. Десять невеликих конфліктів простіше вирішити, ніж 1 масовий конфлікт, і фактично можуть заважати розробникам дублювати чи витрачати сили. З огляду на , що, ви повинні злитися masterв Aі Bрегулярно; раз на день - це досить поширена рекомендація, хоча якщо у вас є велика активність на ваших гілках, ви, можливо, захочете об'єднатися кілька разів на день.

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

Так чи інакше виникнуть конфлікти, тому на їх виправлення потрібно витратити час.

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

Якщо припустити, що ви, зрештою, об'єднати A, B назад у головний і підтримувати єдину базу коду, ніколи не годиться занадто далеко відступати від майстра. Занадто довго відхилятися від master, особливо коли виправлення помилок та інша розробка зливаються з master, оскільки A, B розробляються, безумовно, спричинить конфлікти.

Я б розглядав стратегії, подібні до наступних

1. Хто несе відповідальність за A, B повинен уважно стежити за майстром і зливатися в будь-яких змінах.
2. А ще краще, якщо у вас є автоматизація побудови та тестування, переконайтеся, що A, B злилися в майстер і проходили тести щоночі.
3. Виходячи з коментаря до іншої відповіді, здається, що A, B може зайняти деякий час, щоб розвинутись. У цьому випадку ви навіть можете вважати, що A, B зливаються один з одним, так що зрештою у вас не виникне великих проблем з об'єднанням обох назад у головний.
4. На більш високому рівні подумайте, чому вам потрібні 2 окремі лінії тривалої розробки. Чи можете ви розбитись на менші злиття? Не могли б ви розбитись на окремі мікросервіси?

Зазвичай часто краще, ніж масивний.

Менші, частіші запити на тягнення майже завжди краще.

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

У створенні прапора конфігурації є додаткові накладні витрати, тому на менших функціях це не варто. Але тоді ваш запит на тягнення все одно буде невеликим.

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

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

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

У «Рефакторингу» Мартіна Фаулера порада, яку він дає, ніколи не дозволяє відгалужувати гілку від господаря довше, ніж на день. IIRC, вам слід зробити невелику зміну, протестуйте, щоб переконатися, що ви нічого не зламали, а потім з’єднайте її назад.

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