将分支头留在 Mercurial 中?

发布于 2024-12-01 06:26:19 字数 1059 浏览 0 评论 0原文

我有一个仅供我使用的本地存储库(没有遥控器),用于跟踪网站的更改。该网站有一个登台服务器和一个实时服务器,我想使用的分支方法是有一个命名的“实时”分支,它是实时服务器状态的字面表示(实时服务器可以克隆该分支不应有任何更改)。当前的开发随着“live”(为长项目命名,为短项目未命名(技术上也是“live”))的侧分支而变化,并且“live”在它们准备好从登台服务器上移出时将它们合并回来。因此,我想要的理想分支是这样的:

--A---------E------------L----------O-- live
   \       / \          / \        /
    B--C--D   F--I--J--K   \      /     minor features
               \            \    /
                G--H---------M--N       major feature

但是,如果我将工作目录更新为修订版 A(在分支“实时”上),并且我想开始一个新的小项目,如何分支到 B?

我可以创建一个新的分支名称,然后在 A 之上提交(这将“live”的头部留在 A 处,并在 B 处创建一个新的分支/头部),完成我的工作,然后合并两个分支以创建我想要的 AE,但现在有一个我需要关闭的命名分支。如果我要创建许多较小的功能,我需要为它们提供唯一的名称,因为“关闭”分支仍然存在并声称它们的名称,只是标记为不活动。

如果我只是在 A 之上提交 B 而没有新的分支名称,则“tip”和“live”标签会向上移动到修订版 B,并且 A 不再是头(意味着创建 C 和 D 后,它不能与 D 合并得到 E)。另外,如果我克隆“live”的头部,它并不代表实时服务器(位于A)。

--A--B--C--D   live

创建 B 后,我可以将工作目录更新到 A 并进行无更改提交,这将创建一个新头,但这意味着每次启动新功能时我都必须在实时分支上进行无用的提交。

--A--A' live
   \
    B--C

那么有没有办法在 Mercurial 中以新的、未命名的头提交提交呢?

I have a local repository just for me (no remotes) for tracking changes to a website. The website has a staging server and a live server, and the branching methodology I'd like to use is to have a named "live" branch that is the literal representation of the state of the live server (live server could clone the head of that branch and should have no changes). Current development changes as side branches off of 'live' (named for long projects, unnamed (technically also 'live') for short projects), and 'live' merges them back in when they're ready to move off the staging server. So the ideal branching I'd like is something like:

--A---------E------------L----------O-- live
   \       / \          / \        /
    B--C--D   F--I--J--K   \      /     minor features
               \            \    /
                G--H---------M--N       major feature

However, If I have my working directory updated to revision A (on branch 'live'), and I want to start a new minor project, how do I branch to B?

I can create a new branch name, and then commit on top of A (which leaves the head of 'live' at A, and creates a new branch/head at B), do my work, and then merge the two branches to create the A-E that I want, but now there's a named branch that I need to close. And if I'm creating many smaller features, I need unique names for them all, since "closed" branches are still really there and claiming their name, just marked inactive.

If I just commit B on top of A without a new branch name, the "tip" and "live" tags move up to revision B, and A is no longer a head (meaning after C and D are created, it can't merge with D to make E). Plus, if I clone the head of 'live', it's not representing the live server (which is back at A).

--A--B--C--D   live

After creating B, I could update my working directory to A and do a no-changes commit, which would create a new head, but that means I'd have to do a useless commit on my live branch every time I started a new feature.

--A--A' live
   \
    B--C

So is there a way to submit a commit as a new, unnamed, head in Mercurial?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

|煩躁 2024-12-08 06:26:19

您面临的问题是您不想为短暂的事情执行命名分支,但由于您正在执行 live 分支,因此没有太多可看的live 分支上的哪个头实际上是 live 的正确表示。

我认为这可以通过两个主要分支来解决:一个代表开发,一个代表发布的代码。在您的情况下,而不是分支 defaultstable,您可能会使用defaultlive

您的所有主要功能都将根据 default 命名为分支,而您的次要功能将只是 default 上的匿名分支。您可以在 default 上进行任意数量的开发,并且当您从 livetip 克隆时,它不会改变任何内容> 更新实时服务器。

  • 当您的主要功能之一完成后,您可以将其合并到 default 上的主分支。
  • default 上有准备发布的内容时,您可以根据需要将其合并到 live 中。

由于您不想对次要功能使用命名分支,因此您可能需要跟踪 default 的哪些变更集/头代表正在进行的次要功能,以及哪些变更集/头代表已完成的开发。为此,我推荐书签

另一种可能性

书签还允许您在 A 处创建一个名为 livetip 的书签,然后同时创建一个书签 myMinorFeature 并进行更改并提交B、C 和 D。默认行为是 livetipmyMinorFeature 将移动到 B,然后是 C,然后是 D,​​但您可以更改它,以便仅当前书签后面添加将此内容添加到您的 .hgrc/Mercurial.ini 中:

[bookmarks]
track.current = True

正如您所指出的,hg 不会合并 D 和 A,而是给出“无需合并”消息,即使使用书签。一旦 myMinorFeature 准备好用于实时服务器,您需要将 livetip 书签自行移动到 myMinorFeature 所在的位置。

您还可以标记要为实时服务器克隆的任何变更集,尽管您每次都必须手动移动它。

The problem you're facing is that you don't want to do named branches for short-lived things, but since you're doing the off of the live branch, there isn't much to see which head on the live branch is actually the correct representation of live.

I think this would be solved by having 2 main branches: one represents development, and one represents released code. In your case, instead of branches default and stable, you'd probably have default and live.

All your major features would be named branches based on default, and your minor features would just be anonymous branches on default. You can have however much development in-progress as you want on default, and it won't change anything when you clone from the tip of live to update the live server.

  • When one of your major feature is done, you merge that to your main branch on default.
  • When there is stuff on default that is ready to be released, you merge it over to live, as selectively as you want to.

Because you don't want to use named branches for minor features, you may want to keep track of which changesets/heads of default represent minor features in-progress and which changeset/head represents development that's finished. For that, I recommend bookmarks.

Another possibility

Bookmarks would also allow you to have a bookmark called livetip at A, then create a bookmark myMinorFeature at the same and do changes and commit B, C, and D. The default behavior would be such that livetip and myMinorFeature would move to B, then C, then D, but you can change it so that only the current bookmark follows by adding this to your .hgrc/Mercurial.ini:

[bookmarks]
track.current = True

As you pointed out, hg will not merge D and A, but give a "nothing to merge" message, even with the bookmarks. Once myMinorFeature were ready for the live server, you would need to move the livetip bookmark yourself up to where myMinorFeature is.

You could also tag whichever changeset you wanted to be cloned for the live server, though you have to manually move that every time.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文