Git - Які проблеми виникають при роботі безпосередньо над майстром?

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

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

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

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

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

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

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

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

Майстер повинен бути потенційно звільненим. Період. Не повинно бути жодної напівзавершеної роботи в майстрі (якщо вимкнено прапор функції)

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

Не використовувати PR під час інтеграції в master - помилка, оскільки розробники не матимуть права обирати, коли відбувається інтеграція.

Єдина галузь розвитку приносить дуже мало значення. Зазвичай це просто ускладнює речі. Багато функціональних галузей приносить велику цінність.

Створення гілок для кожного середовища (dev, test, prod) - помилка. Це не підходить для git, і слід вирішувати випускний конвеєр. Точну ж збірку слід розгорнути у всіх середовищах, що неможливо, якщо для кожного середовища є гілки.

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

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

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

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

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

По-друге, це робить перегляд перед об'єднанням дуже важким. У цьому пункті вам насправді не потрібно переконувати його. Ви можете прийняти такий інструмент, як github, gerrit або gitlab, і вимагати перевірки коду запиту та пройдених автоматизованих тестів для всіх злиттів. Якщо ви не робите щось подібне, відверто кажучи, ви не використовуєте git у повному обсязі, і недарма ваш колега не бачить у цьому потенціалу.

В інших відповідях вже згадуються різні переваги (окремі функції, завжди доступний код для master та ін.) Для роботи НЕ над майстром безпосередньо.

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

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

"Не використовувати головну гілку" недостатньо.

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

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

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

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

Немає «поганої практики» навколо роботи безпосередньо на гілці. Але ви повинні вирішити, що найкраще підтримує ваш процес:

Запитання 1: Чи повинен ваш майстер представляти поточний стан випуску вашого програмного забезпечення? Тоді вам слід запровадити галузь глобального розвитку та об'єднати розробку наприкінці розробки релізу.

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

Питання 3: Чи потрібно ділитися проміжним станом коду іншим розробникам, які ще не повинні бути опубліковані у виробництво (або тест)? У цьому випадку більше, ніж один розробник розробляє функцію. Тоді вам слід ввести "функції гілок".