Маючи справу з великим запитом на тягу

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

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

Який найкращий спосіб вирішити таку ситуацію, коли одна гілка дійсно далека від інших? Якими способами ми можемо уникнути того, щоб гілки в майбутньому отримували дуже велику кількість комісій від майстра?

Дозвольте розробнику, який пішов на пару місяців без злиття, виправити це. Можливо, вони можуть отримати один великий шматок коду для злиття, можливо, вони можуть отримати купу маленьких шматочків, щоб злити один за одним. У будь-якому випадку, вони повинні робити ніжки для вирішення проблеми, оскільки вони її спричинили.

Який найкращий спосіб вирішити таку ситуацію, коли одна гілка дійсно далека від інших?

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

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

Щоб відповісти на буквальне запитання: найкращий спосіб вирішити подібну ситуацію - не потрапити в таку ситуацію.

Якими способами ми можемо уникнути того, щоб гілки в майбутньому отримували дуже велику кількість комісій від майстра?

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

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

"Якщо ви зливаєтеся щодня, раптом ви ніколи не доходите до того, що у вас є величезні конфлікти, які важко вирішити". --Лінус Торвальдс

Ця цитата з розмови, яку він виголосив в Google, ось стенограма , і ось відео .

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

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

1. Створіть нову гілку, і вишня вибирайте добрі справи, зливайтеся з господарем.
2. Спробуйте перебазувати небажані зобов’язання до вершини (можливо, на новій гілці просто для безпеки).

Що стосується методів профілактики, спробуйте визначити деякі кумедні правила команди, наприклад "Той, хто не злиється з господарем протягом тижня, замовить піцу на місяць".

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

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

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

Ось просте рішення.

Відслідковуйте функції, які ця особа реалізувала, та переходьте до кожного комітету у тій гілці, яка оновлювалася за функцією Візьміть це зобов’язання і з'єднайте його з master repo.

Дозвольте мені розбити це на прикладі.

Нехай: Відділення A - це гілка від головного Відділення A + = Відділення A + нова функція 1 Відділення A ++ = Відділення A + нова функція 2 тощо і так далі

Що потрібно зробити, це повернутися до: Відділення A +

Візьміть відділення A + і з'єднайте його з Master.

Тепер перейдіть до відділення A ++ і з’єднайте його з (Master + Branch A +).

Повторюйте, поки ви не досягнете остаточного відділення А + ... +, яке є стабільним.

Цей метод спочатку може здатися контр-інтуїтивним, але якщо ви з’єднаєте кожну окрему нову функцію самостійно з головним, то легко переходити між ведучою гілкою " за доданою функцією "

Якими способами ми можемо уникнути того, щоб гілки в майбутньому отримували дуже велику кількість комісій від майстра?

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

Я б запропонував використовувати підхід:

передмайстер і майстер

майстер: Підсумковий / виробничий рівень. Змінюється не часто. Вважається завжди стабільним

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

Ви також повинні спробувати функції поєднання та націлювання на націлювання на версії.

Націлювання на версію: Вкажіть довільне число, яке буде виконувати функції заповнення основного відділення. "У V1.0.0 ми хочемо досягти функцій X, Y, Z. У V1.0.0 також будуть доступні всі ці функції: ..."

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

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

Якщо ви працюєте в рамках Agile або SCRUM, команда повинна насправді запитувати, чому функція не була завершена і об'єднана як частина ітерації / спринту. Якби вона була "занадто великою", щоб вписатися в ітерацію, вона мала бути розбита на менші шматки.

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

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

Багато в чому це стає процесним питанням. Можливо, потрібний вам процес включає періодичну перевірку (щотижня? Щомісяця?) На наявність довготривалих, незанурених гілок. Деякі інструменти спрощують візуальну перевірку; наприклад, на Github відвідайте посилання "гілки", і це показує, наскільки далеко вперед / позаду кожної гілки.