问题描述
我们在我住的地方使用了类似的东西。现在是时候将我们的发行版分支合并回dev中了。我的计划是创建一个拉取请求,将我们的发布分支重新合并到开发人员中,以便我们其余的开发团队有机会查看位桶中的更改。
为了在创建PR之前解决发行分支中的任何潜在冲突,我将dev合并回了发行分支。但是现在我被告知这可能不是一个好主意。简而言之:将开发人员重新合并到发布分支中是不明智的做法还是“危险”的行为?
在创建PR之前,我被告知要在功能分支上执行此操作,而且我认为这也应适用于此发行版分支。
注意,我还通过首先合并到正在进行的Bugfix分支中来完成了此合并。所以流程是这样的:
- 我从进行中的 release-branch (当然是从dev开发而来的)创建了分支 bugfixes-1
- 我进行了一些修复,然后将 dev 合并到了 bugfix-branch
- 然后我还将 release分支合并到我的 bugfix分支中,以防其他同事进行任何更改
- 然后我创建了一个拉取请求,将我的 bugfix-branch (包括从dev合并的所有内容)合并到我们的 release-branch 中。
- 公关被接受了。但是现在有人告诉我,也许这不是一个好主意。
请注意,我尚未将任何内容合并回dev。因此,如果我需要在发布分支中解决或还原某些内容,我仍然可以做到这一点而不会弄乱dev。
这是可能会破坏历史的东西吗?为什么这是个坏主意?最终将发布分支合并回开发人员之后,我们可能会遇到任何问题吗?
非常感谢您的帮助。很抱歉,如果在其他地方都回答过此问题,但我只是在任何地方都找不到任何好的答案。
编辑: 值得一提的是,我们的存储库分为两个文件夹:“ Product1,Product2”。我们在release分支中所做的更改几乎完全在Product1中进行,而团队其他成员(dev)所做的更改几乎仅在Product2文件夹中进行。因此,如果我们必须手动将更改转移到dev或其他地方,那应该很容易,但是我们会失去历史,这是不幸的。
解决方法
分支名称不属于历史记录。它是分布式的VCS,因此您本地的分支名称仅是您的问题。您可以做任何方便的事。
唯一的担心是,您应该了解自己在做什么,不要因命名错误而感到困惑,因此在创建请求请求或直接推送到公共存储库时,您的错误更少。