Подтвердить что ты не робот

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

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

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

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

4b9b3361

Ответ 1

Мне кажется, что ты уже ответил на свой вопрос. Создайте ветвь с именем "vanilla" или что-то, что отслеживает ведущую ветвь вверх и имеет ветвь "master", которая содержит ваши пользовательские расширения. Создавайте ветки для каждой вещи, которую вы делаете. Для исправлений, начните их с "vanilla". Для своих вещей, начните их с мастера. Время от времени сливайте ваниль в мастера. Чтобы получить исправления в своей ветке пользовательских расширений, вы можете напрямую объединить свои ветки в мастер или просто ждать, пока восходящий поток примет ваши запросы на удаление ошибок, а затем следующее слияние от ванили к хозяину будет содержать исправления. Это похоже на очень нормальный рабочий процесс.

Ответ 2

То, что вы хотите настроить, - это долгосрочная fork, чтобы сделать это, поскольку вы уже поняли, что решение может создать специальную ветвь, связанную с исходным проектом "vanilla", и иметь мастер где вы сохраняете свою рабочую копию.

Единственное, что вы должны иметь в виду (с моей точки зрения), это то, что вы не должны объединять две ветки, когда хотите синхронизировать изменения, но в этом случае (Когда ветки расходятся) есть удобная команда Git Cherry-Pick, которая позволяет вам взять одну фиксацию из одной ветки и применить ее к другой, это может быть особенно полезна в случае поддержки вилки, потому что вы можете легко обмениваться одной фиксацией из одной ветки на другую...