Reputation: 5966
I think title should be good enough.
Upvotes: 5
Views: 228
Reputation: 39094
Tags
Think of it as a snapshot in time. I want to be able to go back to that exact point. However, it will never change. You do not do a checkin on a tagged element.
Things that can get tagged:
Branches
The branch will have development performed on it (i.e. checkins).
You might create a branch from a tag (to do a bug fix for example).
You might create a branch to develop a feature and then merge it back to the main trunk.
You might create a branch for a release (minor or major).
The key point is that branches could be modified, and tags should not be.
Upvotes: 3
Reputation: 6865
Apropos other replies,
We use tags for minor point releases and branches for releases. So for example,
v1.0 <-- Branch
v1.0.1 <-- Tag
v1.0.2 <-- Tag
v1.1 <-- Branch
v1.1.1 <-- Tag
v1.1.2 <-- Tag
v1.2 <-- Branch
v1.2.1 <-- Tag
v1.2.2 <-- Tag
v1.3 <-- Branch
v1.3.1 <-- Tag
v1.3.2 <-- Tag
v1.4 <-- Branch
v1.4.1 <-- Tag
v1.4.2 <-- Tag
v1.5 <-- Branch
v1.5.1 <-- Tag
v1.5.2 <-- Tag
To use a Microsoft analogy, a Branch is a release of Windows (95, XP, Vista, etc) and a tag is a service pack.
Upvotes: 0
Reputation: 15451
Branching should also be used for major milestones, such as a releases. This depends on your branching strategy though.
Upvotes: 0
Reputation: 340436
Tags should be used when you want to mark a milestone. The milestone could be as small as a daily build.
Branches should be used when you want to make changes independently from another branch/trunk.
Upvotes: 5