关闭 Mercurial 中未合并的浪费分支

发布于 2024-11-29 06:45:24 字数 397 浏览 0 评论 0原文

我决定在一个分支开始实验

[default] $ hg branch experiment
[experiment] $ [... some commits ...]

啊啊!不起作用!我想把它扔掉。

[experiment] $ hg commit -m "did not work; closing ..." --close-branch
[experiment] $ hg update default

为了得到真正的提示 -

[default] $ [... some commits ...]
[default] $ hg push

这是销毁实验分支的正确工作流程吗?

I decide to start an experiment in a branch

[default] $ hg branch experiment
[experiment] $ [... some commits ...]

Aargh! does not work! I want to throw it away.

[experiment] $ hg commit -m "did not work; closing ..." --close-branch
[experiment] $ hg update default

To get the real tip back -

[default] $ [... some commits ...]
[default] $ hg push

Is this a correct workflow to destroy an experimental branch?

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

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

发布评论

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

评论(4

眼眸印温柔 2024-12-06 06:45:24

关于如何撤消分支,您有两个很好的答案,但更重要的一点是不要将命名分支用于临时概念。命名分支适用于长期存在的实体,例如“开发”和“稳定”。对于功能、实验等,您需要克隆、书签或匿名分支。这三个分支与 Steve Losh 撰写的这篇优秀文章中的命名分支进行了对比:

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

您可以从 Mercurial 看到类似的建议项目在这里:

https://www.mercurial-scm.org/wiki/StandardBranching

You've got two fine answers on how to undo your branch, but the bigger point is don't use named branches for temporary concepts. Named branches are for long lived entities like 'development' and 'stable'. For features, expiriments, etc. you want either clones, bookmarks, or anonymous branches. All three are contrasted with named branches in this excellent article by Steve Losh:

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

You can see similar advice from the Mercurial project here:

https://www.mercurial-scm.org/wiki/StandardBranching

压抑⊿情绪 2024-12-06 06:45:24

Mercurial wiki 涵盖了修剪死枝的所有选项。简而言之,这些选项包括:

  1. 关闭分支(如原始帖子中所做的那样)
  2. 创建一个不包含死分支的新克隆
  3. 使用无操作合并
  4. 使用 stripmq 扩展捆绑的命令

The Mercurial wiki covers all the options for Pruning Dead Branches. Briefly, these options include:

  1. Closing the branch (as done in your original post)
  2. Create a new clone that does not include the dead branch
  3. Use a no-op merge
  4. Use the strip command that is bundled with the mq extension
回心转意 2024-12-06 06:45:24

关闭分支会将其保留在存储库中,并且下次执行推送时,关闭的分支将与其他变更集一起推送。

如果您不希望发生这种情况,并且您的分支是本地的,只需 strip它。

另一方面,如果您已经推送了实验分支,则剥离它不会有任何帮助,因此您可以关闭它或进行虚拟合并(或两者兼而有之)。

Closing a branch will leave it in the repository, and the closed branch will be pushed with other changesets next time you do a push.

If you don't want this to happen, and your branch is local, just strip it.

On the other hand, if you have already pushed the experimental branch, stripping it won't help, so you can either close it or do a dummy merge (or both).

苏大泽ㄣ 2024-12-06 06:45:24

在我看来,你应该关闭分支并忘记它。

从长远来看,存储库中存在“死亡”分支并没有什么坏处。与存储库的内容相比,任何给定的分支几乎肯定都是很小的,并且由附加变更集创建的任何附加“噪音”将相对较快地消失在过去。

然而,通过不用担心清理分支,您可以实现两件事:

  1. 您不必处理与更改 DVCS 中的历史记录相关的任何潜在问题。
  2. (更重要的是)您拥有您的尝试的永久记录。

第二点是关键——如果分支仍然存在,你实际上可以利用你学到的东西:任何开发人员都可以从中学习;如果你学到了别的东西,你可以回去再试一次;您可以通过查看历史记录中的此分支来防止再次尝试相同的操作。

许多开发人员都很难在 DVCS 中保留不“原始”的历史记录,尤其是当他们最近来自集中式 VCS 时。*随着时间的推移,我逐渐意识到这并没有什么坏处或错误。 “其他”历史,事实上,如果保留下来,它会非常有用。

*我并不一定意味着您属于这两个阵营,只是做一个观察。

In my opinion, you should just close the branch and forget about it.

In the long run, there's no harm in a "dead" branch being present in the repository. Any given branch is almost certainly tiny in comparison to the contents of your repository and any additional "noise" created by the additional changesets is going to fade into the past relatively quickly.

However, by not worrying about cleaning up the branch, you achieve two things:

  1. You don't have to deal with any of the potential issues associated with altering history in a DVCS.
  2. (More importantly) You have a permanent record of your attempt.

That second point is key -- you can actually make use of what you learned if the branch is still around: any fellow developers can learn from it; you can go back and try again if you learn something else; you can prevent trying the same thing again by seeing this branch in history.

A lot of developers have a hard time with keeping history that isn't "pristine" in their DVCS, especially when they recently came from a centralized VCS.* Over time, I've come to realize that there's nothing bad or wrong about that "other" history and in fact it can turn out to be remarkably useful if kept around.

*I'm not necessarily implying that you fall into either of these camps, just making an observation.

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