So "tags" for versions and "branches" for new features?

I'm a little bit new to the distributed version control systems, so I was reading Mercurial manual and wha开发者_如何学Got I understood is the tag feature can be used to mark release numbers, example a tag called v1.0 and another v1.1, etc.

As for branches they are to be used to add new features without disturbing other developers then merge it with the default branch after everything is OK.

Is that right?

Please advise. Thanks.

Sounds like you're mostly getting answers from git folks, who almost understand Mercurial too.

The core difference is that in git the branch name isn't an integral part of a changeset -- it's just where the changeset happens to be now. In mercurial a Named Branch's name is part of it forever. This leads folks who know git more than they know Mercurial to say one of two not-quite correct things:

• Named branches should be used on a per-feature basis -- There's nothing wrong with using a named branch per feature in Mercurial, but since those branch names never go away your hg branches output can grow quite large.
• Branching in Mercurial isn't as lightweight as in git -- Named Branching in Mercurial isn't quite as lightweight (they're permanent) but that's why it's not the norm for features. Anonymous branching in Mercurial is more lightweight than git's named branches, and Bookmark branching in Mercurial is exactly the same as git branching.

All of this is spelled out beautifully in Steve Losh's Guide to Branching in Mercurial, as originally answered by OJ (which I upvoted).

In summary:

• git
  • releases: tags
  • features: branches
  • lines of development (stable, etc.): separate repositories
• mercurial:
  • releases: tags
  • features: bookmarks or anonymous branches
  • lines of development (stable, etc.): named branches

Of course, either tool can be used in either fashion -- it's more about norms than it is about "correct".

Have a read of the following to help clarify your understanding (Mercurial related):

• A guide to branching in Mercurial
• Mercurial Workflows: Branch as Needed
• Mercurial Workflows: Stable and Default
• Mercurial Workflows: Translation Branches

Well that's a question that depends on your point of view. In git, branches are used for a lot of purposes ( i.e. one is development). In fact, everything in git is branch. And there may be different tags in each branch.

I've would recommended to read this gread tutorial, as it explains a lot of things about branches and releases:

http://nvie.com/posts/a-successful-git-branching-model/

The two answers about git correctly agree with you that tags are good for releases, and branches are good for new features, but don't really explain why.

A git tag permanently points to a given commit. This means that it's really only good for marking a milestone like a release.

A branch, on the other hand, can be checked out and committed to, meaning the branch will advance to point to that new commit. This makes branches the way to work in git; any time you make a commit you want to have an appropriate branch checked out, so that it will record your progress. This includes new features, as you say, but also any other work.

The situation in Mercurial is mostly similar, though branching is not quite so lightweight, so you won't be branching as frequently as you would in git. And tags are handled a bit differently, but are still good for marking releases.

I'm not a Mercurial user (I use Git), but as far as the Git work flow goes you've got it dead on. Branches are used, often by one developer, to work on their own bugfixes/features before merging with the main branch.

Tags are normally used on the main branch to tag milestones, often releases. This lets you revert to that state easily, without having to use commit numbers (which in Git are long strings of hexadecimal digits, not sure how Mercurial works).

Gary