1. © 2010 Shivercube

2. © 2010 Shivercube
 Clone an existing repository to create a new
local repository for development
 Each developer must have their own local copy
before making any changes
 Makes a copy of a repository at a point in
time
 Checks out the tip of the default branch

3. © 2010 Shivercube
 Atomic collection of changes to files in a
repository
 Uniquely identified with a changeset ID
 In a single repository identified by a revision
number

4. © 2010 Shivercube
 The creation of a new changeset
 Each commit should have a description
 Each commit should have a single specific
purpose
 Bulk amount of work should be separated into
individual commits
 Don’t do too much in a single commit

5. © 2010 Shivercube
 Diverged line of development
 Linear sequence of consecutive changesets
 Default branch name is “default”
 Supports naming

6. © 2010 Shivercube
 Symbolic identifier for a changeset
 Use to mark different versions of the system
 Most recent changeset called “tip”

7. © 2010 Shivercube
 Push changes to another repository
 Adds changes in local repository to the
remote repository
 Only adds changes which are missing in the
remote repository

8. © 2010 Shivercube
 Pull changes from another repository
 Retrieves changesets from a remote
repository and merges them into the local
repository
 Only transfers changesets which are missing
in the local repository

9. © 2010 Shivercube

10. © 2010 Shivercube
 Allows two different strands of development
at the same time
 Quick and easy to switch between branches
 “default” branch should always contain
production code
 Always contains the latest workable version of the
system
 Code being developed should be under separate
branches

11. © 2010 Shivercube
 Create two copies of a repository
 Transfer changesets between them as often as
you want
 Safe way to create branches
 Repositories are completely isolated until you
push or pull
 Can’t break something in one branch while working in
another
 Easy to delete branch
 Good for single developer testing features, but
not good for developers working as a team

12. © 2010 Shivercube

13. © 2010 Shivercube
 Create new branches for new features
 Able to merge changes between branches
 Permanently adds changeset metadata
 Close branches after finished

14. © 2010 Shivercube

15. © 2010 Shivercube
 Fastest and easiest way to implement small
changes
 Update to any revision and commit
 Use changeset IDs to switch back and forth
 Won’t be any descriptive name for a branch
 Best for simple changes or experiments by a
single developer

16. © 2010 Shivercube

17. © 2010 Shivercube
 Combines two separate changesets into a
merge changeset
 Joins points of two branches into one
 Usually collisions can be automatically
handled
 Can use KDiff3 to intelligently merge changes into
a single file