Стратегия ветвления и слияния - ядро ​​Linux

Question

Фон

Со страницы Linux GitHub за последний месяц более 500 авторов отправили 1946 коммитов во все ветви, за исключением слияний.

В master изменилось 11 000+ файлов иЕсть 549K добавлений и 308K удалений.

800K loc были затронуты за 1 месяц на 600 разработчиков.

Все разработчики распределены по всему миру и работают независимо.Они не управляются одним менеджером.

Ядро Linux все еще работает !!!

---

Рабочий процесс

Ниже приведены два рабочих процесса, с которыми я столкнулся:

TBD:

Рабочий процесс Gitflow:

1) Что такоерабочий процесс, который следует за разработчиком ядра Linux?Какова стратегия слияния в зависимости от рабочего процесса?чтобы сохранить master код ветви без конфликтов.

2) Перед git push изменениями из локального репо (ноутбука), вы предварительно проверяете фиксацию с некоторой базовой линией?проверить VCS или конфликты не-VCS

3) В каких случаях разработчик ядра Linux помечает / маркирует коммит?

Answer 1

Страница 123 из ProGit сообщает мне, что ядро ​​Linux использует «Рабочий процесс диктатора и лейтенантов» ( Раздел Распределенные рабочие процессы в ProGit )

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