【问题标题】:Mercurial: Adding changes after specific changeset in a branch and merging itMercurial:在分支中的特定更改集之后添加更改并将其合并
【发布时间】:2014-11-05 15:38:19
【问题描述】:

让我先解释一下情况。 不久前,我有 master 和 feature 分支。然后在构建主分支并将其发送到生产环境后,我将功能分支与主分支合并。所以我现在只有 master 分支。很多提交之后,我收到了将修复/功能添加到生产中的代码的请求。因此,我已经找到了与功能分支合并之前的特定变更集,我需要向其中添加某些代码但仍保留在主分支中。

目前情况:

master   --1-------o--P--X----2--o--o--o--*
            \                /
feature      o--o--o--o--o--o

变更集 P 是在生产中的,而 X 是我需要添加修复并再次推送到生产的地方。之后,我需要我的小费来包含所有内容 + X。

所以在主分支中我必须有:

  • 与功能分支合并之前的所有内容
  • 修复

有了这个存储库状态,我们可以将构建推送到生产环境。完成此操作后,我需要添加到今天所做的所有更改并与这些新更改合并,因此我有:

  • 与功能分支合并之前的所有内容
  • 与功能分支合并后的变化
  • 修复

现在我可以继续处理所有更改。

我使用 Mercurial,但我对它不太了解。

我欢迎任何见解或帮助。

最好的问候

【问题讨论】:

    标签: merge mercurial branch


    【解决方案1】:

    为我解决了这个问题的是:

    1. 在功能分支实施(到 P 变更集)并提交之前恢复到修订版
    2. 添加修复并提交
    3. 使用 backout 从步骤 1 中取出 revert
    4. 合并更改并提交

    所以在第 2 步之后,我拥有了所有正在生产中的代码 + 修复。然后我使用第 3 步恢复到我最初的状态,并将变更集与修复合并到它。所以最后我得到了所有带有功能+修复的代码。

    【讨论】:

      【解决方案2】:

      简单来说:

      • 移动到历史上需要的“注入点”
      • 进行必要的更改,提交
      • 测试新的tip(不知何故)
      • (如果需要,添加修复)
      • 将您当前的 tip 与“旧”提示(master 的第二个头)合并

      在 Mercurial 命令中

      • hg up X
      • 在这里编码...
      • hg commit -m "description of change"
      • hg archive PATH/TO/ARCHIVE_FOR_PROD
      • 在这里测试...
      • hg merge(没有-r,因为你在分支中合并了两个头)
      • hg resolve如果需要解决冲突,交互式合并将是更好的选择)
      • hg commit -m "Merge added feature"

      【讨论】:

      • 这个解决方案可以解决眼前的问题。但是,当用户要求将功能 Y 添加到原始生产版本中时会发生什么?那么Z?图表很快就会变得难以理解。对于这种可能性,通常最好将版本分离到自己的分支中,并根据需要使用樱桃挑选技术在它们之间移植功能。
      • @JohnJefferies - 我讨厌...不,讨厌 樱桃采摘。 “每个任务的分支”(命名的分支)和“发布”变更集的标记(仍在master 分支内)将没问题(对我来说)
      • 我说的是每个版本的分支,而不是每个任务的分支。至于樱桃采摘好不好,这完全取决于发布的复杂程度。当我们有数十或数百个变更集要移植到长期存在的版本时,分支对我们来说是一件非常好的事情。 YMMV [而且很明显]。
      • 我也更喜欢分支,但是自动构建的当前状态太复杂而无法更改,所以我不得不在一个分支中完成。不过,感谢您的时间和想法!
      【解决方案3】:

      如果我没看错的话,你想要的第一部分会在这张图中表示:

      release-2 --------F'
                       /
      master  --o--o--P--o--m--o--o--tip
                           /
                          /
      feature --o--F--o--o
      

      其中 P 是用于生产的变更集,F 是您希望移植到生产版本的功能,m 是分支的合并。

      以这种方式移植变更集称为挑选。一种方法是:

      1. hg up P # 为 P 使用变更集
      2. hg branch release-2 # 可选,否则 master 将有 2 个头
      3. hg graft -r F # 为 F 使用变更集

      然后 F' 就是您的新产品版本(当然是在测试之后)。

      我不明白你问题的第二部分,你显然想把东西移植到 F' 上。为什么不从当前的提示继续工作呢?您的下一个版本将在将来的某个变更集中作为 master 的另一个分支。

      我建议您在实际操作之前先尝试测试存储库。 [学习如何使用任何新的 hg 命令也是如此。]

      【讨论】:

      • 1. hg branch release-2 -f (如果是强制性的,由于现有的分支) 2. 2. 在 hg 分支中看不到 any 意义 3. 你有一些假设错误:新孩子必须被添加到master中P的<some parent>
      • 我已经用图表更新了我的问题,也许可以把事情弄清楚。
      • 我做的一个假设是新特性已经被编写并且在特性分支中。这在当时似乎很明显,但现在可能是模棱两可的。
      • 为已发布的产品创建一个分支被认为是一种很好的做法,至少在我的商业世界中是这样。优势明显;您可以根据用户的需要向发布分支添加新的变更集。但这并非在所有环境中都是必需的。
      • 我添加了对我有用的解决方案,但感谢您的时间和想法!
      猜你喜欢
      • 2014-10-15
      • 2012-03-20
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-05-31
      • 1970-01-01
      相关资源
      最近更新 更多