首页 > 解决方案 > 如果存储库包含超过 10 个应用程序/解决方案,如何在 Git 中管理功能和主分支的合并

问题描述

我们有超过 7 个 git 存储库。每个 repo 包含 10 个 dot net 应用程序/解决方案,它们彼此完全独立。

我们遵循 Feature -> DEV -> Master 分支方法。

在这里,我们将 Feature 分支合并到 DEV 中,它工作正常。当我们合并我们的 DEV 和 master 分支时,Dev 上有其他解决方案的提交,由于该功能尚未发布到生产环境,因此不应该进入 master。

现在我们正在本地复制一个解决方案(已投入生产),并创建一个从主粘贴解决方案到该分支的分支,并将 PR 创建到主控。

有没有一种有效的方法来处理这个问题?

我们可以为每个解决方案创建单独的 git repo,以便在上述情况下易于合并吗?

请建议处理上述情况的最佳方法。

提前致谢。

标签: gitazure-devops

解决方案


当我们合并我们的 DEV 和 master 分支时,Dev 上有其他解决方案的提交,由于该功能尚未发布到生产环境,因此不应该进入 master。

这就是为什么,理想情况下,您会将 Feature 合并到 master,而不是 DEV。

这就是gitworkflow(一个词)的意义所在:

gitworflow

想法是:避免此处描述的 Git Flow ()的紧张feature->dev->master

在 GitFlow 中,在保持开发工作干净和隔离在主题分支上的愿望与通过合并主题分支以开发以使其可见和可测试并检查冲突来将主题分支与其他工作集成之间总是存在无法解决的紧张关系。

如果您在 Dev 中合并多个功能并将其合并到 master,您会合并所有内容,包括尚未准备好的功能。

如果你直接将特性合并到主控,你只会合并那些在 Dev 中被认为准备好的,这将成为一个临时分支,在每次新的开发迭代时重置。


推荐阅读