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

Обзор

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

Критерии

  1. Мы должны иметь возможность легко отправлять пулл-реквесты/патчи вверх по течению.
  2. Проект должен отслеживать выпуски с тегами и может быть обновлен до более новых выпусков в рамках нашего собственного рабочего процесса выпуска.
  3. Должен иметь свои собственные релизы с тегами
  4. Должен иметь свою собственную структуру ветвления для процесса разработки, подобного git-flow.

Опция 1

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

Вариант 2

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

Вариант 3

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

Вариант ?

Что-то я не учел?


git github git-flow git-fork
person jhogendorn    schedule 18.03.2014    source источник
comment
Кто-нибудь пробовал какой-либо из этих методов в течение значительного периода времени? Если да, то какие неочевидные проблемы у вас были? Какую схему именования ветвей вы использовали (чтобы я и другие могли использовать ее для создания/следования псевдостандартной системе именования для этого процесса)?   -  person Jeff Hykin    schedule 31.05.2020

Ответы (1)


arrow_upward
5
arrow_downward

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

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

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

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