Moyen-sol entre les branches et sous-modules?

Question

Je viens de créer autour des branches de sujet pour les fonctionnalités inachevées de mon projet, géré par Git. Ils sont tous très autonome de telle sorte, que l'on branche le sujet ne se rapporte pas directement à une autre branche de sujet. Toutes les branches ont cependant un terrain d'entente, la branche principale, qui est le cœur du système, les branches thématiques apparaissent juste les fonctions dans la branche principale.

Si je comprends bien, si je fais quelque chose dans la branche principale qui affecte (m) toutes les branches de sujet (par exemple, changer l'API utilisée pour communiquer entre le noyau et les caractéristiques individuelles) que le changement ne se propage pas les branches de sujet automatiquement, de sorte que les branches puissent être fixés en conséquence. Les changements devraient être fusionnés manuellement ou cerise dans cueillies les autres branches.

Je comprends que l'utilisation des sous-modules y parviendrait. Les sous-modules conduisent cependant à une trop grande séparation entre le projet principal et les prétendus projets de longs métrages, principalement parce que les caractéristiques ne sont pas autonomes. Ils comptent sur le noyau.

Alors, ce que je suis à la recherche est une sorte de méthode pour dire que certains fichiers / répertoires sont uniques à une branche, tout le reste vient d'une branche principale. Manquant une meilleure analogie, parlant en termes Photoshop, je veux maître pour être l'arrière-plan de la couche, et chaque branche de sujet serait une couche d'image partiellement transparente sur le dessus de celui-ci, avec des contenus uniques.

Answer 1

Cette notion de "composition" ou "l'héritage de configuration" est pas prise en charge dans Git, comme cela est expliqué dans la question " flexible vs ramification statique". Seulement se confond vous permettent de « composer » l'ensemble exact des fichiers que vous voulez.

La fonction sous-module vous aider à identifier un ensemble cohérent de fichier qui doit avoir son propre cycle de vie et être étiquetée à son propre rythme. Ce n'est pas le cas de vos fonctions.

Votre approche doit rester un « système basé sur href="https://stackoverflow.com/questions/769786/vendor-branches-in-git/769941#769941"> » un, où vous développez, étiquette et fusionner le tout système. Si quelque chose évolue sur la branche principale, il doit être fusionner les branches de fonction.
Si les caractéristiques impliquent un ensemble différent de fichiers que ceux modifiés dans la branche principale, que la fusion sera trivial. Sinon, vous pouvez suivre suggestion Mateusza , au moyen d'un intermédiaire branche pour résoudre les conflits et d'évaluer le résultat d'une telle fusion, tout en gardant la branche de fonction intacte.

Answer 2

Disons que vous avez maître de branche et bouquet de branches: feature1, fonction2, Caractéristique3 ...

$ git checkout feature1
$ git branch master-with-feature1
$ git checkout master-with-feature1
$ git merge master

Chaque fois que vous apportez des modifications à maître ou feature1 vous pouvez checkout maître-avec-feature1 et les fusionner.