Git workflow для разработки корпоративного ядра Linux

Question

Я работаю в компании, которая строит встраиваемые системы с использованием Linux. Исторически мы всегда использовали CVS для хранения работы нашего ядра. Наши ядра в конечном итоге представляют собой коллекцию:

• Драйверы для нашего фирменного оборудования
• Случайные исправления для битов Linux, которые мы используем
• Непатентованные аппаратные драйверы
• Случайные взломы юкки для настройки Linux для нашего приложения

Мы находимся на этапе, когда мы хотели бы переоборудовать некоторые из наших старых ядер на более новые версии, а также исправить наш архаичный рабочий процесс CVS на что-то, основанное на наборах изменений. Очевидный выбор - git.

Я изо всех сил пытаюсь придумать разумный рабочий процесс. Я экспортировал наш CVS-репозиторий для одного из наших ядер, и у меня есть коллекция наборов изменений поверх соответствующего базового ядра Linus. Куда мне идти отсюда?

Мне бы хотелось иметь центральное хранилище, в которое все разработчики вносят изменения. Безопасно ли использовать rebase, чтобы перенести нашу коллекцию наборов изменений в новую базовую ревизию ядра, а затем провести наши разработки поверх новой центральной ветви?

Бонусные баллы за получение рабочего процесса, который позволяет нам легко выделять изменения, которые могут подходить для восходящего потока. Я сыт по горло тем, что постоянно собираю небольшие (или крошечные) полезные изменения.

Answer 1

Rebase подходит для интеграции вышестоящих ветвей в свою локальную ветвь, при условии, что никто не проталкивает указанную локальную ветвь (так как история этой локальной ветки была переписана). Например, "рабочий процесс git и ребаз против вопросов слияния" .

В каждом репозитории Git для разработчиков должна быть выделена отдельная «открытая» ветвь (т. Е. Должна быть выдвинута), чтобы merge / cherry-pick соответствующих изменений нажать.
Потенциально, несколько открытых ветвей могут сосуществовать, по одной на версию ядра, чтобы поддерживать / исправлять, если это необходимо.

Тогда можно установить центральное репо, чтобы интегрировать (т. Е. Вытащить) все ветви разработчиков, вставленные в него.

См. Также "управление выпусками git" для получения дополнительной информации о рабочих процессах слияния и темах публикации.