将分支头留在 Mercurial 中?
我有一个仅供我使用的本地存储库(没有遥控器),用于跟踪网站的更改。该网站有一个登台服务器和一个实时服务器,我想使用的分支方法是有一个命名的“实时”分支,它是实时服务器状态的字面表示(实时服务器可以克隆该分支不应有任何更改)。当前的开发随着“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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您面临的问题是您不想为短暂的事情执行命名分支,但由于您正在执行
live
分支,因此没有太多可看的live
分支上的哪个头实际上是live
的正确表示。我认为这可以通过两个主要分支来解决:一个代表开发,一个代表发布的代码。在您的情况下,而不是分支
default
和stable
,您可能会使用default
和live
。您的所有主要功能都将根据
default
命名为分支,而您的次要功能将只是default
上的匿名分支。您可以在default
上进行任意数量的开发,并且当您从live
的tip
克隆时,它不会改变任何内容> 更新实时服务器。default
上的主分支。default
上有准备发布的内容时,您可以根据需要将其合并到live
中。由于您不想对次要功能使用命名分支,因此您可能需要跟踪
default
的哪些变更集/头代表正在进行的次要功能,以及哪些变更集/头代表已完成的开发。为此,我推荐书签。另一种可能性
书签还允许您在 A 处创建一个名为
livetip
的书签,然后同时创建一个书签myMinorFeature
并进行更改并提交B、C 和 D。默认行为是livetip
和myMinorFeature
将移动到 B,然后是 C,然后是 D,但您可以更改它,以便仅当前书签后面添加将此内容添加到您的.hgrc
/Mercurial.ini
中:正如您所指出的,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 thelive
branch is actually the correct representation oflive
.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
andstable
, you'd probably havedefault
andlive
.All your major features would be named branches based on
default
, and your minor features would just be anonymous branches ondefault
. You can have however much development in-progress as you want ondefault
, and it won't change anything when you clone from thetip
oflive
to update the live server.default
.default
that is ready to be released, you merge it over tolive
, 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 bookmarkmyMinorFeature
at the same and do changes and commit B, C, and D. The default behavior would be such thatlivetip
andmyMinorFeature
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
: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 thelivetip
bookmark yourself up to wheremyMinorFeature
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.