Quel est le meilleur flux de travail Git pour travailler avec un projet open source avec des modifications spécifiques à l'employeur?

Chez mon employeur actuel, nous utilisons un projet open source hébergé sur Github en tant que composant de notre application. J'ai travaillé sur ce projet à la fois pour ajouter certaines fonctionnalités dont nous avons besoin et pour l'intégrer à nos systèmes de construction. Mon manager et moi sommes d'accord pour dire que nous aimerions soumettre autant de travail que possible sur ce composant au projet open source. Ma question est de savoir quel est le meilleur workflow / technique pour maintenir mes validations Git de manière à ce que je puisse facilement séparer les choses qui ont du sens à ajouter au projet open source - corrections de bugs et nouvelles fonctionnalités suffisamment générales - à partir d'éléments spécifiques à notre projet, comme les emplacements de génération et les constantes d'application.

Ce que j'ai fait jusqu'à présent, c'est de maintenir une branche Git privée où je valide toutes mes modifications, avec la granularité appropriée. J'utilise ensuite cherry-pickpour ajouter les commits open-sourceable à la branche principale et les renvoyer à Github.

Il semble que je devrais utiliser la fusion pour ce faire, afin de ne pas continuer à créer des validations distinctes avec un contenu identique, mais je ne sais pas comment le faire tout en excluant les validations spécifiques à l'entreprise et en gardant un flux de travail raisonnable.

Par exemple, je suppose que je pourrais valider des choses open-sourcable sur le maître et des choses spécifiques à l'entreprise sur la branche privée, puis fusionner le maître dans cette branche au besoin, en laissant la branche principale pointant sur la validation avant la fusion, de sorte que je puisse y engager à nouveau des éléments open source, puis fusionner à nouveau. Ce qui semble gênant dans ce flux de travail, c'est que je devrais décider à l'avance de tout ce que je fais sur la branche à laquelle il appartenait, travailler sur ce qui semblait être terminé, puis le valider et fusionner avant de tester. L'une des choses que j'aime vraiment à propos de Git est la facilité avec laquelle il suffit de faire tout ce dont vous avez besoin pour faire fonctionner votre application, puis de décider plus tard comment et où valider vos modifications. Pour autant que je sache, si vous êtes actuellement dans une succursale et que vous avez du travail, il '

Ce que je fais est-il un flux de travail raisonnable pour les contributions à long terme? Quelqu'un peut-il recommander un flux de travail différent qui pourrait être meilleur, et pourquoi est-il meilleur?

Voici une stratégie qui pourrait vous convenir:

Créez 2 référentiels git privés, un référentiel étant destiné au travail de l'entreprise et l'autre étant le référentiel général (j'aimerais revenir en arrière).

Pour que ce système fonctionne, vous devez le faire (que je considère comme la stratégie la plus importante): définir ce qui est "général" et peut être utilisé par tous les autres membres de la communauté

En ayant cette définition, vous pouvez séparer ce que vous allez valider et ce que vous n'avez pas besoin de valider.

Il est logique que ce que vous codez pour la communauté soit sous une forme générale, car un morceau de code trop spécifique ne profitera à personne (et pourrait même ne pas arriver à la branche principale).

Maintenant que vous savez ce que vous allez engager pour la communauté, vous pouvez faire la plupart des travaux de «redistribution» dans le référentiel qui lui est dédié. Ensuite, vous fourrez simplement ce dépôt à votre dépôt basé sur le travail et effectuez tout travail spécifique au travail en plus.

Je soupçonne que vous passerez beaucoup plus de temps dans le repo "redonner", alors n'oubliez pas de fournir des commentaires précieux, etc. (peut-être même de la documentation) pour les personnes qui utiliseraient ce projet à l'avenir.

Je pense aussi que git peut faire bien plus que vous ne le pensez. J'ai regardé cette vidéo sur Vimeo: http://vimeo.com/46010208 et elle a fait un excellent travail pour expliquer beaucoup de choses loufoques que Git peut faire.

Ma stratégie n'est pas la seule sur le marché, mais elle peut certainement être un point de départ pour vous de penser à 1 qui vous convient spécifiquement.

Selon la nature de la base de code open-source et ce que vous devez accomplir en y apportant des modifications, vous pourriez gagner beaucoup de temps en séparant vos préoccupations. Dans votre fork du projet, ajoutez uniquement les choses que vous avez l'intention de contribuer à l'original. Ajoutez des crochets ou des points d'extension pour vous permettre de faire votre travail d'entreprise qui ne sera pas partagé.

De cette façon, vous n'aurez jamais à vous soucier de diviser ou de décider à l'avance quoi partager et quoi ne pas partager. Parce que vous avez ajouté de la flexibilité au projet d'origine, vous pouvez toujours choisir de partager certaines parties du travail de votre entreprise plus tard.