Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Like this? Share it with your network

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • regarrding slide 10, when it says 'default branch should always contain ...'
    Are you sure about this?
    That seems quite in contrast with respect to the official Hg/Mercurial suggested way, here:



    3. The default branch

    This is where development of new features occurs [...].
    (!) It is strongly recommended to do your primary development on the so-called 'default' branch, because it is the branch used by default in various commands such as clone.
    Are you sure you want to
    Your message goes here
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1.  
  • 2.
    • 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.
    • 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.
    • 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.
    • Diverged line of development
    • Linear sequence of consecutive changesets
    • Default branch name is “default”
    • Supports naming
  • 6.
    • Symbolic identifier for a changeset
    • Use to mark different versions of the system
    • Most recent changeset called “tip”
  • 7.
    • 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.
    • 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.  
  • 10.
    • 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.
    • 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.  
  • 13.
    • Create new branches for new features
    • Able to merge changes between branches
    • Permanently adds changeset metadata
    • Close branches after finished
  • 14.  
  • 15.
    • 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.  
  • 17.
    • 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