Git рабочий процесс для поддержки производной вилки

Обзор

У меня есть проект, который представляет собой настройку существующего продукта FOSS. Это доходит до того момента, когда мы поддерживаем долгосрочную вилку, а не применяем новые плагины и тому подобное. Я хотел бы получить некоторые сведения о том, какой может быть самый эффективный рабочий процесс для поддержки этого проекта.

Критерии

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

Вариант 1

Просто разветките проект на github. Супер беспорядочно поддерживать и ускорять ход людей. сбой 3,4.

Вариант 2

Создайте новый репозиторий, попросите сопроводителя проекта поместить тегированные потоки исходной кодовой базы по мере необходимости. например, что-то вроде git fetch upstream; git merge upstream/sometag tagintegrationbranch Не уверен, как легко нажать исправления вверх по течению в этой модели. Вид сбоя 1.

Вариант 3

Выполните проект вверх по течению, используйте его как восходящий поток, как в Варианте 2. Используется в качестве помощника для системы PR. Вероятно, придется делать вишневые кирки или некоторые аналогичные микроуправляемые функции, чтобы подталкивать код, поддерживая этот рабочий процесс, в зависимости от того, насколько хорошо управляются ветки функций/ошибок, но должны быть достаточно чистыми. Кажется, удовлетворяет большинство критериев.

Вариант?

Что-то я не рассматривал?

Ответ 1

Вариант 3, по-видимому, представляет собой четкое разделение рабочего процесса между двумя проектами:

один со случайным вкладом обратно в исходный проект с запросами на тягу
один с совершенно новыми ветвями и кодом для нового приложения

Чтобы облегчить слияние, я бы рекомендовал использовать иерархические имена ветвей в вашем репо, чтобы четко разделить:

для разработки вашего проекта (классические имена, в них нет необходимости /)
ветки из восходящего/исходного репо (все префикс с именем, представляющим ветку из исходного репо, например 'original/dev', для того, чтобы вы могли выбирать из вишни или из них)
Эти ветки уже находятся в пространстве имен для прокси-серверов/восходящих потоков, но если вы хотите отменить новые коммиты, вам нужно создать локальную ветвь, и моя точка: имя этой локальной ветки должно иметь в ней "/", чтобы четко различать его с другими регулярными ветвями для вашего проекта.