Використовуючи Git, чи доцільно використовувати головну гілку для активного розвитку?

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

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

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

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

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

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

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

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