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). - 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 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.
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