Mercurial工作流程 - 什么时候可以重新定义，何时合并？

Question

We've been using Mercurial at work for a couple of months now. We've modified our workflow a few time and ended up with this:

The initital snapshot was on staging , we then cloned that onto our central repository and everyone cloned that locally .

• When we work on feature/bugfix we always update to the latest default from staging so that we start from the latest production copy.
• We then push the feature branch to a central repository for backup, making it available to team, etc.
• We go on our QA system and pull the feature branch and merge it there.
• If the QA signoff on the feature, we merge it into the stable branch on the same machine.
• We then pull the stable branch onto staging, merge it there and do summary testing.
• If all is well we robocopy everything to the live system.

This has worked for us for a while, but there's still rough spot that make us go: "mmmmh, maybe there's a better way, it doesn't quite feel natural" .

The biggest issue we have is when we have a feature branch that grows old on our local machine.

Example:

• I have branch 62_EpicNewFeature on my system.
• Priorities got re-organized, work on EpicNewFeature stops :(
• 6 months after, I finally resume work on EpicNewFeature

At this point, that branch is way behind the current default. If I finish it and try to merge it on QA I'll get so many conflicts (for which you pretty much always keep what's on QA now.)

What we sometime do to mitigate this problem is we merge default back into EpicNewFeature so as to bring it "up-to-speed". This simplifies our merge on QA but it's still usually one heck of a local merge.

I've read about rebasing which is suppose to help making the next merge a fast-forward since you (from what I understand) inject the history in the middle, altering your own history.

Most place I've read about rebase warn you not to do it if you've already pushed your branches though, and definitely not if someone might have pulled your changes already. How can you make sure of that? we push often to the central repository for backup and we usually just hg pull everything.

Do you see something that would help us improve our current workflow? Would rebasing more often help us?

Answer 1

I think you've misunderstood what rebasing does. It works by simply merging to the tip of your repository and then cutting away the original links. It's pretty much the same action as taking a "diff" and applying that to the tip.

You'll still get all the same merge conflicts you're trying to avoid.

Usually the easiest way to deal with these conflicts is piecemeal. Don't try to to merge up to the tip all in one go.