子模块和分支之间的中间地带？ [英] Middle-ground between submodules and branches?

问题描述

我刚刚为我的项目未完成的功能创建了主题分支，由Git管理。它们都以这种方式非常独立，一个主题分支不直接与另一主题分支相关。但是，所有分支都有一些共同点，即主分支，这是系统的核心，主题分支只是扩展了主分支中的功能。

如果我已经正确理解了，如果我在影响（m）任何主题分支的主分支中执行某些操作（例如，更改用于在核心和单个功能之间进行通信的API），那么更改不会自动传播到主题分支，以便可以相应地修复分支。这些更改需要手动合并或樱桃采摘到其他分支。

我明白使用子模块可以实现此目的。然而，子模块导致主项目和潜在特征项目之间的分离太大，主要是因为这些特征不是自我维持的。他们依赖核心。

所以，我在寻找的是某种方法来说某些文件/目录对某个分支是独一无二的，来自主要分支。缺乏一个更好的比喻，用Photoshop术语来讲，我希望 master 成为背景层，每个主题分支都是一个部分透明的图像层，并带有一些独特的内容。 / p>

解决方案

在Git中不支持组合或配置继承的概念，正如问题灵活vs静态分支。只有合并才能让您编写所需的确切文件集。

子模块功能可帮助您识别一组连贯的文件，该文件必须具有其自己的生命周期并按自己的步调进行标记。这不是你的功能的情况。

您的方法应该保持为基于系统的一个，您开发，标记和合并所有系统的地方。如果在主分支上发生某些事情，则需要在功能分支上进行合并。

如果功能涉及与主分支中修改的文件不同的一组文件，则该合并将很简单。如果没有，您可以按照 mateusza的建议，使用中级分支来解决冲突并评估这种合并的结果，同时保持特性分支不变。

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.

解决方案

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.

这篇关于子模块和分支之间的中间地带？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！