子模块和分支之间的中间地带？
我刚刚开始为我的项目未完成的功能创建主题分支，由 Git 管理。 它们都非常独立，一个主题分支不直接与另一个主题分支相关。 然而，所有分支都有一些共同点，主分支是系统的核心，主题分支只是扩展主分支中的功能。
如果我理解正确的话，如果我在主分支中做了一些影响（m）任何主题分支的事情（例如，更改用于在核心和各个功能之间通信的 API），则该更改不会传播到主题分支自动，以便相应地固定分支。 这些更改需要手动合并或挑选到其他分支中。
我知道使用子模块可以实现这一点。 然而，子模块导致主项目和未来的功能项目之间存在过多的分离，主要是因为这些功能不能自我维持。 他们依靠的是核心。
所以，我正在寻找的是某种方法来说明某些文件/目录对于某个分支是唯一的，其他所有内容都来自主分支。 缺乏更好的类比，用 Photoshop 术语来说，我希望 master 成为背景层，每个主题分支将是其顶部的部分透明图像层，并具有一些独特的内容。
I just got around creating topic branches for my project's unfinished features, managed by Git. They are all very self-contained in such a way, that one topic branch doesn't directly relate to another topic branch. All branches, however, have some common ground, the master branch, which is the core of the system, the topic branches just extend the features in the master branch.
If I've understood correctly, if I do something in the master branch that affects (m)any topic branches (say, change the API used to communicate between the core and the individual features) that change doesn't propagate to the topic branches automatically, so that the branches could be fixed accordingly. The changes would need to be manually merged or cherry-picked into the other branches.
I understand that using submodules would achieve this. The submodules lead, however, to too much separation between the main project and the would-be feature projects, mainly because the features aren't self-sustaining. They rely on the core.
So, what I'm looking for is some kind of method to say that certain files/directories are unique to a certain branch, everything else comes from a main branch. Lacking a better analogy, speaking in Photoshop terms, I want master to be the Background-layer, and each topic branch would be a partly-transparent image layer on top of it, with some unique contents.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Git 不支持“组合”或“配置继承”的概念，如问题“灵活分支与静态分支”。 只有合并才允许您“组合”您想要的确切文件集。
子模块功能可帮助您识别一组连贯的文件，这些文件必须具有自己的生命周期并按照自己的节奏进行标记。 你的功能不是这样的。
您的方法应该保持“基于系统”的方法，您可以在其中开发，标记并合并所有系统。 如果主分支上发生了某些变化，则需要将其合并到功能分支上。
如果这些功能涉及主分支中修改的一组不同的文件，则合并将是微不足道的。 如果没有，您可以按照 mateusza 的建议，使用中间分支来解决冲突并评估此类合并的结果，同时保持功能分支不变。
That notion of "composition" or "inheritance of configuration" is not supported in Git, as explained in the question "Flexible vs static branching". Only merges allow you to "compose" the exact set of files you want.
The submodule feature help you to identify a coherent set of file which must have its own life cycle and be tagged at its own pace. That is not the case of your features.
Your approach should remain a "system-based" one, where you develop, tag and merge the all system. If something evolves on the master branch, it needs to be merge on the feature branches.
If the features involve a different set of files that the ones modified in the master branch, that merge will be trivial. If not, you can follow mateusza's suggestion, using an intermediate branch to resolve the conflicts and evaluate the result of such a merge, while keeping the feature branch untouched.
假设您有分支 master 和一堆分支：feature1、feature2、feature3...
任何时候您对 master 或 feature1 进行任何更改，您都可以签出到 master-with-feature1 并合并它们。
Lets say you have branch master and bunch of branches: feature1, feature2, feature3...
Any time you make any changes to master or feature1 you can checkout to master-with-feature1 and merge them.