Git рабочий процесс для разработки ядра Linux

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

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

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

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

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

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

Ответы

Ответ 1

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

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

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

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