Moving to git from Clearcase

Git is distributed version control system (DVCS) where as Clearcase is
centralized source control system. Clearcase provides access to data in the
repository via a virtual file system called MVFS(Multiversion File System).
Conceptually Git and Clearcase are very different in the way they manage
data and maintain different versions.

Here are some of the points about git which are different from Clearcase and
took some time for me to sink in. The list is limited to operational differences
I notice while using git for day to today work. Gaining a good understanding
of Git object model and its internals would provide a good insight to how
git works and help one to use git better.

• Each git clone is a replica of the central repository
  There is no central repository that is sitting and holding all the code
  and all the related metadata. When a repository is cloned all the data that
  is available at the server is available at user machine as well. To
  put it Clearcase terminology each clone is a replica. Most of the
  operations that a user does on his machine updates the local replica
  and these changes need to be explicitly pushed to the server (say for
  sharing changes with other users, data protection in case of user
  machine crash etc.)
• Git has no checkin command and checkout command is
  not what it means in Clearcase
  In Clearcase to make a file (say) version controlled the user has to
  use mkelem and checkin commands. Once a file is version
  controlled it will be owned by Clearcase and for any further
  modifications to a version controlled file user has to check it out
  (using checkout) make the modifications and check it in
  (using checkin command).

In git a file (say) can be version controlled by using add
and commit commands. The user need not do anything similar to
Clearcase checkout to modify the file. Once the file is modified it
needs to be added (using add) and committed
(using commit) to create a newer version of the file.

A warning to Clearcase user working with git is that doing
a checkout file in git would get the version of file that was
part of the previous commit thus overwriting any local changes made to
the file.

• There are no view and no config specs
  In Clearcase what is visible in a working directory is ruled by the
  configuration specification (cspec) the user’s view has. The cspec
  rules determine which version of a file needs to be made visible, from
  which branch a file needs to be picked etc. If the user needs to view
  a file (element) in a different branch he needs to edit his cspec or
  use the version extended path name of the element to access the
  version of the element in a different branch. This at its best is
  cumbersome.

In git there is no such thing as config spec or a view.Any directory
to which a git repository has been cloned or repository has been created is the
location where the repository contents are available.A user can
switch branches by just checking out the appropriate branch.

Some useful git links

• 1.A very good introductory book on git
• 2.Everyday git with 20 Commands or So
• 3.Excellent SO post about git and Clearcase