Mercurial:使用hg pull --rebase的具体问题示例 [英] Mercurial: Concrete examples of issues using hg pull --rebase

问题描述

我正在努力寻找适合我们工作方式的日常工作流程.

我目前偏爱每个功能的克隆，但这是从Subversion转变的思维定势.我们在设置环境方面的当前费用也将有问题.

使用hg pull --rebase似乎给了我们更多类似于Subversion的工作流程，但是从阅读的内容来看，我很警惕使用它.

我认为我理解这些概念，并且可以看到重写历史记录不是理想的，但是我似乎无法提出我个人认为不可接受的任何方案.

我想知道什么是hg pull --rebase可能在理论上或经验上造成的最差"情况.我想要的是具体示例，而不是您是否应该"重写历史的观点.并不是说我反对人们发表意见，只是互联网上似乎已经表达了很多意见，而没有很多实例来支持他们;)

解决方案

新的Mercurial转换需要学习的第一件事是使提交不完整的代码变得很舒服. Subversion告诉我们，您不应该提交损坏的代码.现在是时候取消这种习惯了.频繁投入可为您的工作流程提供更大的灵活性.

我在hg pull --rebase上看到的主要问题是无法取消合并就可以中断合并的能力. DVCS模型基于显式跟踪历史的想法，通过说我的所有更改都在您的所有更改之后进行，通过重新调整基础来颠覆该想法，即使我们确实同时在进行这些更改也是如此.而且由于我不知道您的更改是什么(因为我的代码是基于较早的变更集)，所以我很难知道我的代码不会破坏您的代码.您还会因重新部署而失去分支功能，这实际上是DVCS背后的全部想法.

我们的工作流程(我们建立了一个整个Mercurial托管系统)基于保持多个克隆，或分支存储库，我们称之为它们.每个开发人员或小型团队都有自己的分支存储库，它只是中央"存储库的一个副本.我所有的新功能和大的错误修复程序都进入了我的个人分支存储库.我可以让该代码同行进行审查，一旦准备就绪，就可以将其合并到中央存储库中.

这给了我一些好处.首先，我不会破坏构建，因为所有更改都在自己的存储库中，直到它们就绪"为止.其次，如果我需要做一个单独的功能，或者如果我有一个运行时间更长的东西，例如下一个主要版本，我可以制作另一个分支仓库.第三，如果有需要快速修复的错误，我可以轻松地更改中央存储库.

也就是说，可以使用两种不同的方法来使用此工作流程.我最简单的方法就是保留单独的克隆.因此，我将使用website-central，website-tghw等.它运行良好，特别是因为您可以在本地之间进行推拉.最近，我开始使用 remotebranches 扩展将其保留在同一个仓库中帮助管理它们，并 hg推动避免立即推送所有内容.

当然，有些人不太喜欢这个工作流程，通常是因为他们的Mercurial服务器很难进行服务器端克隆.在这种情况下，您也可以使用命名分支 .不幸的是，它们不像Git分支那样灵活(这就是为什么我们更喜欢分支存储库)，但是一旦您了解了如何关闭分支，以及为什么一旦启动分支就不能真正摆脱它们，它们就可以很好地发挥作用. /p>

这有点长，所以我将鼓励您接受Mercurial提供的高级分支和合并(超过SVN)，以完成总结.肯定有一个学习曲线，但是一旦掌握了它，它的确会使事情变得更容易.

I'm struggling to find the mercurial workflow that fits the way that we work.

I'm currently favouring a clone per feature but that is quite a change in mindset moving from Subversion. We'll also have issues with the current expense we have in setting up environments.

Using hg pull --rebase seems to give us more of a Subversion-like workflow but from reading around I'm wary of using it.

I think I understand the concepts and I can see that rewriting the history is not ideal but I can't seem to come up with any scenarios which I personally would consider unacceptable.

I'd like to know what are the 'worst' scenarios that hg pull --rebase could create either theoretical or from experience. I'd like concrete examples rather than views on whether you 'should' rewrite history. Not that I'm against people having opinions, just that there already seem to be a lot of them expressed on the internet without many examples to back them up ;)

解决方案

The first thing new Mercurial converts need to learn is to get comfortable committing incomplete code. Subversion taught us that you shouldn't commit broken code. Now it's time to unlearn that habit. Committing frequently gives you a lot more flexibility in your workflow.

The main problem I see with hg pull --rebase is the ability to break a merge without any way to undo. The DVCS model is based on the idea of tracking history explicitly, and rebasing subverts that idea by saying that all of my changes came after all of your changes, even though we were really working on them at the same time. And because I don't know what your changes are (because I was basing my code off of earlier changesets) it's harder for me to know that my code, on top of yours, won't break something. You also lose the branching capabilities by rebasing, which is really the whole idea behind DVCSs.

Our workflow (which we've built an entire Mercurial hosting system around) is based on keeping multiple clones, or branch repositories, as we call them. Each dev or small team has their own branch repository, which is just a clone of the "central" repository. All of my new features and large bug fixes go into my personal branch repo. I can get that code peer reviewed, and once it's deemed ready, I can merge it into the central repo.

This gives me a few nice benefits. First, I won't be breaking the build, as all of my changes are in their own repo until they're "ready". Second, I can make another branch repo if I need to do a separate feature, or if I have something longer-running, like for the next major version. And third, I can easily get a change into the central repo if there's a bug that needs to be fixed quickly.

That said, there are a couple different ways you can use this workflow. The most simple, and the one I started with, is just keeping separate clones. So I'll have website-central, website-tghw, etc. It works well, especially since you can push and pull between them locally. More recently, I've started keeping multiple heads in the same repo, using the remotebranches extension to help manage them and hg nudge to keep from pushing everything at once.

Of course, some people don't like this workflow as much, usually because their Mercurial server makes it hard to make server-side clones. In that case, you can also look at using named branches to help keep your features straight. Unfortunately, they're not quite as flexible as Git branches (which is why we prefer branch repos) but they work well once you understand how to close branches, and why you can't really get rid of them once you start one.

This is getting a bit long, so I'll wrap it up by encouraging you to embrace the superior branching and merging that Mercurial provides (over SVN). There is definitely a learning curve, but once you get the hang of it, it really does make things easier.

这篇关于Mercurial:使用hg pull --rebase的具体问题示例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！