Git 在将发布分支合并回dev之前，将dev合并到发布分支是一种错误吗？

我们在我家用的是一种亲缘关系。很快就要将我们的发布分支合并回dev了。我的计划是创建一个pull请求，将我们的发布分支合并回dev，以便我们的开发团队的其他成员有机会查看bitbucket中的更改

为了在创建PR之前解决发布分支中的任何潜在冲突，我将dev重新合并到发布分支中。但现在有人告诉我这可能是个坏主意。简而言之：将开发人员合并回发布分支是一种不好的做法还是“危险的”？

在创建PR之前，我被告知要对我的功能分支执行此操作，我认为这也应该适用于此发布分支

注意，我也通过首先合并到一个正在进行的错误修复分支中来进行合并。所以流程是这样的：

我从我们正在进行的发布分支创建了分支bugfixes-1（当然，这是从dev创建的，早就开始了）

我提交了一些修复，然后将dev合并到我的bug修复分支中

然后，我还将发布分支合并到我的bug修复分支中，以防我的其他同事做出任何更改

然后我创建了一个pull请求，将我的bug修复分支（包括从dev合并的所有内容）合并到我们的发布分支中

公关被接受了。但现在有人告诉我，也许这不是个好主意

请注意，我还没有将任何内容合并回dev。因此，如果我需要解决或恢复发布分支中的某些内容，我仍然可以这样做，而不会搞乱dev

这是不是会把历史搞得一团糟？为什么这是个坏主意？在我们最终将发布分支合并回dev之后，我们可能会遇到什么问题

非常感谢你的帮助。我很抱歉，如果这已经回答了其他地方，但我只是找不到任何好的答案

编辑：

---

值得一提的是，我们的存储库分为两个文件夹：“Product1，Product2”。我们在发布分支中所做的更改几乎完全在Product1中进行，而团队其他成员（开发人员）在中所做的更改几乎完全在Product2文件夹中进行。因此，如果我们必须手动将更改移动到dev或其他地方，这应该相当容易，但我们会丢失历史记录，这将是不幸的。

分支名称不属于历史记录。它是分布式VCS，所以您只关心本地分支机构的名称。你可以做任何对你方便的事

---

唯一需要关注的是，您应该了解自己在做什么，不要被错误的命名选择所迷惑，这样在创建拉请求或直接推送到公共存储库时就不会犯错误。

您到底是如何使用分支的？假设

release

是一个分支，可以用于在一瞬间部署到生产环境中，我不会在没有首先验证组合的情况下将

dev

中的任何内容合并到

release

。将

release

合并到

dev

中是验证两者结合是否有效的良好第一步。感谢您的回复！你提出了一个很好的观点，但这不是我们的问题。我们从dev添加的东西不会影响我们的产品，除非在某些情况下它会影响更改的配置文件，在这种情况下需要更改。而且，现在看起来我们不会直接从这个“发布”分支发布，我知道这很愚蠢。但它将被合并回dev。我要补充的是，我不太关心从这个发布分支发布。我真正关心的是，通过先将更改合并到我的发布分支中，然后再将发布分支合并回dev中，可能会以某种方式弄乱历史记录，就像它会覆盖那些合并提交的历史记录一样。不用说，我是新手。