hg 的 merge 和 update 的区别

1.理解一

The need to merge vs. update isn't about whether or not the changes conflict, it's about whether you have a split in your commit history. If you have a history like this:

[A]--[B]--[C]--UNCOMMITTEDCHANGESHERE

and you pull down --[D] your uncomitted changes will be combined with D when you update.

If, however you have committed so that you have:

[A]--[B]--[C]--[E]

and you pull you'll have:

[A]--[B]--[C]--[E]             \              -[D]

and you'll need to merge to get down to a single head.

For the record, that's a better idea. Updating with uncommitted changes is a non-reversible action, which is always a little scary. If you've committed, you can always undo/redo a merge until you're happy with the combination.

P.S. Someone is probably going to suggest the fetch extension, and they're dead wrong.

If you have local commits: merge. If you have uncommitted local modifications: update (which will merge).

Usually when you make a commit locally, it forks the tree when you pull. In this case you always have to merge (or rebase with the rebase extension). If you have uncommitted local modifications, then when you pull, you can update and merge the changes into your workspace.

hg book:http://hgbook.red-bean.com/

2.理解二

up vote13down vote

• hg update is about making your working directory the same than a given revision
• hg merge won't reset your working directory to a given revision (it still refers the same), but will merge changes from another revision into your current working directory.

So after a pull, an hg update will change your working directory to reflect what you have pulled into your repository.
But hg merge will not reset your working directory, only merge the changes between your working directory and what you have pulled.

hg pull -u will pull and update, refusing to merge or overwrite local changes.

• If the pull add a new HEAD in your repo, you will need to merge

added 1 changesets with 1 changes to 1 files (+1 heads)(run 'hg heads' to see heads, 'hg merge' to merge)

• If the pull add no new HEAD in your repo, a simple update is enough

3.理解三

问题：

We started using Mercurial a several weeks ago. Most developers follow this workflow:

• work on a feature
• commit -m "Worked on feature ABC"
• pull -u
• If branch
  • merge
  • commit -m "Merge"
  • push

Today, one of our developer suggested that we do:

• work on a feature
• pull -u
• if branch
  • merge
• commit -m "Worked on feature ABC"
• push

That way, we have a lot less "Merge" changesets in the log.

Some of us think it's just a matter preference. Some of us think one is better than the other. We don't have much experience and don't want to live the downsides of misusing the tool. So if one approach is more advisable then the other, please let me know why.

解答：

16down voteaccepted

I like your original procedure more, but reasonable people can certainly disagree. I consider merging an actual piece of software development work and like having it be a first class citizen in our process.

In your second/suggested procedure the risk is that the pull does some stuff you really don't want and then you have a very hard time separating it from the work you've already done.

For people who just can't stand branchy history the usual preferred workflow is:

• work on a feature
• commit
• pull --rebase
• push

where the --rebase option appears on pull after you enable the rebase extension. I'm not a fan of rebase because it's technically rewriting history which is antithetical to how mercurial is supposed to work, but I'm in a rapidly shrinking minority on that point.

Bottom line, if you really don't want a branchy history use rebase -- don't update into uncommitted changes as it's hard to undo.