【问题标题】:Mercurial push problemMercurial推送问题
【发布时间】:2011-03-15 15:38:42
【问题描述】:

我刚刚遇到了hg push 命令的问题。我做了什么 - 首先我创建了 2 个分支 hot-fix-1hot-fix-2 在每个分支中进行了一些更改,将其合并回 default 并使用以下命令关闭这些分支:

hg commit --close-branch  

如果我开始 hg branches 我有以下输出:

default      29:e62a2c57b17c

hg branches -c 给我:

default                       29:e62a2c57b17c
hot-fix-2                     27:42f7bf715392 (closed)
hot-fix-1                     26:dd98f50934b0 (closed)

因此hot-fix-* 分支似乎已关闭。但是,如果我尝试推送更改,我会收到下一条错误消息:

pushing to /Users/user1/projects/mercurial/mytag
searching for changes
abort: push creates new remote branches: hot-fix-1, hot-fix-2!
(use 'hg push --new-branch' to create new remote branches)

无论我使用哪个命令hg push -b .hg push -b default
所以问题是我如何在不创建新分支的情况下将这些更改推送到存储库。

P.S 我曾经使用 git,并希望在 Mercurial 中可以使用类似的分支模型。谢谢

【问题讨论】:

  • 只是在首屏明确地说出来:Mercurial 可以做一个类似于 git 的分支模型,它使用未命名的分支而是使用书签。

标签: mercurial push


【解决方案1】:

首先,正如许多其他人指出的那样,不推荐使用命名分支进行短期工作。命名分支主要用于长期存在的功能或发布管理。

鉴于您处于这种情况,有几个选项可用。所有这些都涉及修改历史记录(因为您显然是在尝试更改您所做的事情)。

一个是按原样推动分支,从经验中学习,然后继续前进。如果团队的其他成员对此表示满意,那么可以将 --new-branch 添加到您的推送命令中。

如果团队的其他成员,或者你,真的希望历史是干净的,那么你需要更深入地挖掘。

如果你不推动,那么一定要克隆你当前的 repo。这样您就可以使用原始作品的副本。

我在这里看到了 2 种主要方法。剥离合并并将您的分支重新设置为默认值。这将摆脱命名的分支或移植/移植您的更改。两者的最终结果相同,但实现方式略有不同。

如果您只想使用graft,那么现在这是从 HG 2.0 开始的内置函数。它取代了移植插件,并且使用起来更好,因为如果有冲突,它会使用你常用的合并工具。

要使用它,请更新到默认分支。然后,使用命令:

hg graft -D "2085::2093 and not 2091"

-D 之后的字符串是一个 hg 版本选择查询。在您的情况下,您可能只需要 '{start}::{end}' 其中 start 是分支开始处的变更集,而 end 是分支的结束变更集(忽略合并)。

如果您进行了多次合并,则必须更精确地挑选变更集。

另一个选项是剥离最终的合并,并使用作为 mq 插件一部分的 rebase 命令。

您必须剥离合并变更集以摆脱它们,然后更新到您要保留的分支的尖端。选择第一个命名分支的起点,然后进行变基。这将改变分支的父级(如果你熟悉 Git,那么这很像它的变基)。

然后重复第二个分支。您现在应该有一个名为 default 的长分支。

【讨论】:

  • 有你想要的答案,所以它是定义正确的答案,但我没有添加评论,大多数 Mercurial 工作流假设一个不可变的历史并安排事情以避免需要 @987654323 @ 或 rebase。在这种特定情况下,通过避免短生命周期实体的 named 分支来做到这一点。如果这些修补程序是匿名 分支或书签,您就不需要用striprebase 重写历史记录。在修改历史的工具上构建您的工作流程并没有错,只是通常不被视为 Mercurial 最佳实践。
  • @Ry4an 完全同意。我严格关注这个问题,但应该提到最佳实践,以避免将来出现这种情况(也是第一位的)。感谢您确保完成此操作。
  • 感谢您的补充。我将很快修改问题以纳入 HG 中的更改。从 2.0 开始,有一个比移植插件更好的命令。新命令是graft,并提供通常的合并帮助。移植不会。
【解决方案2】:

只要做:

hg push --new-branch

它会发送这些分支,但它们也会在接收端关闭,所以没有人应该被打扰。

请参阅我对这个问题的评论,了解为什么命名分支最适合保存在“稳定”之类的长期实体中,而匿名分支、书签或克隆更适合短期存在的事物,例如热修复和新功能。

【讨论】:

    【解决方案3】:

    您的hot-fix 更改是在分支上进行的。不管分支是活跃的还是关闭的,它确实存在。

    要将更改推送到服务器(不重写历史记录),您必须使用 --new-branch 选项(例如 hg push --new-branch`)。

    由于您将分支合并为默认分支,因此仍然只有一个头(正如您已经在本地存储库中看到的那样)。

    如果您真的无法忍受将分支推送到服务器,那么您必须按照Mikezx6r's answer 中的建议重写您的本地历史记录。

    除了他提到的方法之外,您还可以将变更集导入补丁队列并将它们应用到您的默认提示。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-08-31
      • 2019-04-05
      • 2019-02-14
      • 1970-01-01
      相关资源
      最近更新 更多