Meilleures pratiques pour les référentiels git sur les projets open source

Je consortingbue à un assez petit projet open source hébergé sur Github. Pour que d’autres personnes puissent profiter de mon travail, j’ai créé ma propre diapositive sur Github. Malgré le choix de la terminologie de Github, je ne souhaite pas diverger totalement du projet principal. Cependant, je ne m’attends pas à ce que tout mon travail soit accepté dans le référentiel principal. Certains d’entre eux ont cependant déjà été fusionnés dans le référentiel principal et je pense que cela continuera. Le problème que je rencontre est la meilleure façon de garder nos deux arbres dans un état où le code peut être partagé facilement entre eux.

Voici certaines des situations que j’ai ou que je vais rencontrer:

Je valide le code qui sera accepté ultérieurement dans le référentiel principal. Lorsque je retirerai de ce référentiel à l’avenir, mon commit est dupliqué dans mon référentiel.
Je valide un code qui n’est jamais accepté dans le référentiel principal. Lorsque je sortirai de ce repository à l’avenir, les deux arbres ont divergé et il est difficile de le réparer.
Une autre personne arrive et base son travail sur mon référentiel. Donc, si possible, évitez de changer les commits que j’ai poussés, par exemple en utilisant git rebase.
Je souhaite soumettre du code au référentiel maître. Idéalement, mes modifications devraient facilement pouvoir être transformées en correctifs (idéalement en utilisant git format-patch) qui peuvent s’appliquer directement et proprement au référentiel maître.

Autant que je sache, il y a deux ou peut-être trois façons de gérer cela, dont aucune ne fonctionne particulièrement bien:

Exécutez fréquemment rebit git pour garder mes modifications basées sur la tête du référentiel en amont. De cette façon, je peux éliminer les commits en double, mais je dois souvent réécrire l’histoire, ce qui pose des problèmes aux personnes qui souhaitent tirer leur travail du mien.
Fusionner fréquemment les modifications du référentiel en amont dans la mienne. Cela fonctionne bien de mon côté, mais ne semble pas faciliter la soumission de mon code au référentiel en amont.
Utilisez une combinaison de ceux-ci et éventuellement git cherry-pick pour garder les choses en ordre.

Qu’ont fait les autres dans cette situation? Je sais que ma situation est analogue à la relation entre les différents consortingbuteurs du kernel et le repository principal de Linus. J’espère donc qu’il y a de bonnes façons de gérer cela. Je suis assez nouveau pour git, donc je n’ai pas maîsortingsé toutes les nuances. Enfin, surtout en raison de Github, ma terminologie peut ne pas être entièrement cohérente ou correcte. N’hésitez pas à me corriger.

Quelques conseils que j’ai appris d’une situation similaire:

Avoir une twig de suivi à distance pour le travail de l’auteur en amont.
Tirez les changements de cette twig de suivi dans votre twig principale de temps en temps.
Créez une nouvelle twig pour chacun des sujets sur lesquels vous travaillez. Ces twigs ne devraient généralement être que locales. Lorsque vous obtenez des modifications de l’amont vers le maître, rebasez vos twigs de sujet pour refléter ces modifications.
Lorsque vous avez terminé avec le travail sur un sujet, fusionnez-le en maître. De cette façon, les personnes qui dérivent du travail ne verront pas trop d’historique réécrit, car le rebasage s’est produit dans vos twigs locales.
Soumettre des modifications: votre twig principale sera essentiellement une série de commits, dont certains sont identiques à l’amont, le rest vous appartient. Ce dernier peut être envoyé sous forme de patch si vous le souhaitez.

Bien sûr, votre choix de noms de succursales et de télécommandes vous appartient. Je ne suis pas sûr que ceux-ci soient exhaustifs pour le scénario, mais ils couvrent la plupart de mes obstacles.