Wir haben ein OSS-Projekt auf GitHub gespalten und fügen ihm einige benutzerdefinierte Erweiterungen hinzu. Wir werden einige der Änderungen, die wir vorgenommen haben, an das ursprüngliche Projekt zurücksenden (Fehlerkorrekturen und Ähnliches), aber andere Änderungen sind Funktionserweiterungen, an denen die ursprünglichen Projektbetreuer im Moment nicht interessiert sind. Ich versuche, den besten Workflow für die Bewältigung dieser Situation herauszufinden.

Ich möchte, dass unser Hauptzweig die Summe von (Commits aus dem ursprünglichen Projekt) + (unsere Fehlerbehebungen für den Beitrag) + (unsere benutzerdefinierten Erweiterungen) enthält. Ich stelle mir vor, wir wollen ein Modell für einzelne Zweigstellen, damit wir Fehlerbehebungen von benutzerdefinierten Erweiterungen trennen können. Wir können benutzerdefinierte Erweiterungszweige von unserem Hauptzweig aus starten, aber ich denke, wir möchten auch einen lokalen "Ursprungs" -Zweig oder etwas, das das ursprüngliche Projekt verfolgt, beibehalten, damit wir Bugfix-Zweige von dort starten können, die nicht mit unserem verschmutzt sind benutzerdefinierte Sachen. Oder so.

Kann jemand den besten Weg vorschlagen, um diesen Workflow so zu strukturieren, dass alle verschiedenen Commits dahin gehen, wohin sie gehen sollen, und keine dahin, wohin sie nicht gehen sollen?