Какой лучший рабочий процесс Git для работы с проектом с открытым исходным кодом с изменениями, специфичными для работодателя?

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

До сих пор я занимался частной веткой Git, где я фиксирую все свои изменения с соответствующей детализацией. Затем я использую, cherry-pickчтобы добавить коммиты с открытым исходным кодом в основную ветку и отправить их обратно в Github.

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

Например, я полагаю, что я мог бы зафиксировать открытые исходные тексты в основных и специфичных для компании вещах в частной ветви, а затем при необходимости объединить основной в эту ветку, оставив главную ветвь, указывающую на фиксацию перед объединением, так, чтобы я мог снова зафиксируйте в нем вещи с открытым исходным кодом, а затем снова объедините. Что кажется неловким в этом рабочем процессе, так это то, что мне нужно было бы заранее решить для всего, что я делаю, к какой ветви он принадлежал, поработать над тем, что казалось завершением, затем зафиксировать его и объединить перед тестированием. Одна из вещей, которые мне действительно нравятся в Git, это то, как легко просто делать все, что вам нужно, чтобы ваше приложение работало, а потом решать, как и где фиксировать ваши изменения. Насколько я могу судить, если вы в данный момент находитесь на ветке и уже проделали определенную работу,

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

Вот стратегия, которая может работать на вас:

Создайте 2 частных репозитория git, один из которых предназначен для работы в компании, а другой - в качестве общего (я хотел бы зафиксировать) репо.

Чтобы заставить эту систему работать, вам нужно сделать это (что я считаю наиболее важной стратегией): определить, что является «общим» и может использоваться всеми остальными в сообществе.

Имея это определение, вы можете отделить то, что вы будете фиксировать, а что вам не нужно.

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

Теперь, когда вы знаете, что вы собираетесь передать сообществу, вы можете выполнять большую часть «отдачи» в репо, посвященном этому. Затем вы просто переходите от этого репо к своему репо на основе работы и выполняете какую-либо работу над этим.

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

Я также считаю, что Git может сделать намного больше, чем вы думаете. Я смотрел это видео на Vimeo: http://vimeo.com/46010208, и она сделала блестящую работу, объясняя множество дурацких вещей, которые может делать git.

Моя стратегия не единственная, но она определенно может стать отправной точкой для того, чтобы подумать о 1, который подходит именно вам.

В зависимости от природы кодовой базы с открытым исходным кодом и того, что вам нужно сделать, внеся изменения в нее, вы можете получить много пробега, разделив свои проблемы. В ваш форк проекта добавляйте только те вещи, которые вы намереваетесь внести обратно в оригинал. Добавьте хуки или точки расширения, чтобы позволить вам выполнять работу вашей компании, которой не будут делиться.

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