时间戳

首页 > 解决方案 > 在将发布分支合并回开发之前将开发合并到发布分支中吗？

git - 在将发布分支合并回开发之前将开发合并到发布分支中吗？

问题描述

我们在我的地方使用类似的东西来 git flow。现在是时候将我们的发布分支合并回 dev。我的计划是创建一个拉取请求，将我们的发布分支合并回 dev 中，以便我们开发团队的其他成员有机会查看 bitbucket 中的更改。

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

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

请注意，我还通过首先合并到我拥有的正在进行的错误修复分支来进行此合并。所以流程是这样的：

  1. 我从我们正在进行的发布分支创建了我的分支bugfixes-1（当然，这又是从 dev 创建的，回溯）
  2. 我提交了一些修复，然后我将开发合并到我的错误修复分支中
  3. 然后我还将发布分支合并到我的错误修复分支中，以防我的其他同事进行任何更改
  4. 然后我创建了一个拉取请求，将我的bugfix-branch（包括从 dev 合并的所有内容）合并到我们的release-branch中。
  5. PR被接受了。但现在有人告诉我，也许这不是一个好主意。

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

这是可能会破坏历史的事情吗？为什么这是一个坏主意？既然我们最终将发布分支合并回开发，我们可能会遇到任何问题吗？

非常感谢你的帮助。如果这已在其他地方得到回答，我很抱歉，但我根本无法在任何地方找到任何好的答案。

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

标签： gitmergegit-branchbranching-and-merginggit-flow

解决方案

分支名称不是历史的一部分。它是分布式 VCS，因此您只关心本地分支名称。你可以做任何你方便的事。

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

推荐阅读