我正在一个带有奇怪分支计划的项目中工作。假设这是一个共享的项目存储库，其中包含一些网站（仅以下示例）：
在Web1，Web2，Web3上方的站点中，共享相同的功能，Web4与另一个共享相同的功能以及一些更改。先前的团队结束了为web1，web2，web3和web4的web4_master建立主分支的工作。这是一个分支外观的示例：
λ git branch
* web4_master
master
develop
我想在这里使用git-flow，就像在其他项目中一样，使用常规分支方案（仅意味着一个母版），但是在这种情况下，我必须以母版为主分支，有时代码也要交给母版。或访问web4_master或同时访问两者。有什么办法可以使用git-flow来解决这个问题？还是我必须被束缚于旧方法，即将更改手动合并到任何地方？
答案 0 :(得分：0)
由于web4包含了其他站点的所有更改，因此我将按以下方式构造存储库：
master分支正常develop到正常的一个master分支web4_master是master的分支web4_develop是web4_master的分支如果某项功能适用于所有站点，则将在develop的功能分支中完成工作，例如“正常” git-flow。最终，它将可以发布并合并到master中。
如果某个功能仅适用于web4，则该工作在web4_develop的一个功能分支中完成，并最终合并到web4_master中。
本质上，有两种git-flow发生-一种针对所有网站，一种针对web4特定事物。
最后一块：
在所有网站的发布过程中（或在您认为最合适的时候），web4需要获取最新发布的更改。
web4_master重置为master。可能会有冲突，请根据需要解决web4_develop改成web4_master. This will NOT be a standard rebase and will need to make use of the-on`标志，以避免重复提交。有关详细说明，请参见this web4进行中的功能，重复步骤2分支到web4_develop。从本质上讲，这将web4树视为来自master的长期运行的功能分支。
如果“所有站点”功能发生重大变化，或者更改非常普遍，我不建议这样做，因为解决冲突会很烦人。
在这种情况下，我建议您手动将更改合并到两个根分支的解决方案。
使用合并策略也可能使这种方法有意义/更容易，但这并不是我偏爱这样的事情。