Git робочий процес для декількох команд

Ми почнемо використовувати Git (ще не використовуємо його), і я хочу визначити робочий процес.

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

Чи є рекомендація щодо роботи Git для такого середовища?

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

Також у цій статті представлений приємний підхід.

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

git version-control

— Ігор Окс
джерело

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

Я впевнений, що 10 людей могли відповісти на це за допомогою 10 різних відповідей. Ось що для мене працює: У нас є один master repo, розміщений на github, який позначає "поточний" реліз. Старіші випуски розгалужені (хоча тег також працює). Членів команди рекомендується створити гілки для виконання завдань, над якими вони працюють. По завершенні вони роблять запит на тягнення для управління (або там, де коли-небудь його потрібно об'єднати), а потім хтось інший переглядає запит на витягування і може повторно об'єднати його в головний. Вони також несуть відповідальність за очищення філії після її об'єднання.

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

— Фред Фоо

@larsmans & carbonbasednerd - Ваші коментарі повинні були відповісти, вони отримали б голоси від мене. * 8 ')

— Марк Бут

Відповіді:

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

Успішна модель розгалуження git

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

— Нік Хаддад
джерело

Я б сказав, що у кожної команди є своя версія сховища, з одним глобальним сховищем, куди всі беруть на себе зобов’язання (як у ядрі Linux, де сховище Linus - це ядро та центральне сховище).

Тоді для збереження коду продукту ви можете використовувати підмодулі, як сказав @larsmans, тоді кожна команда може працювати лише в основному над тією частиною, яка є найважливішою для них, і якщо їм потрібно працювати з іншою частиною, вони можуть це зробити, але вони доведеться пам’ятати, щоб оновити підмодуль, і саме тут і полягає проблема (оскільки дуже легко помилитися при використанні git, на щастя, також легко їх відійти).

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

— Койот21
джерело