First, I detailed general equivalences between Git and ClearCase in "What are the basic ClearCase concepts every developer should know?" (2009)
Second, there is no direct equivalent for git clone
, since a clone would get (with default settings) the full history of a remote repository, which is never done with ClearCase: you don't get the full copy of a VOB (Versioned Object Base). Said Vob can be as large as many terabyte!
In ClearCase:
- you create a view (snapshot, dynamic or web view)
- you configure its config spec in order to select the versions of each file/folder you want to see in this view.
- automatic configuration through UCM views, which derives their selection rules from the stream foundation baselines of each UCM components, meaning of each VOB root component folder,
- or manual configuration for non-UCM view, where you specify whatever path and rules you want through config spec.
Note: the term checkout is a loaded one.
- in Git, it has been judged too confusing, and replaced with:
git restore
, to restore files at a certain version
git switch
(to switch branches, which is done in ClearCase by modifying the config spec of an existing view, or by creating another view alltogether)
- in ClearCase,
cleartool checkout
is used to mark a file for modification, and lock its state, before releasing the lock with a cleartool checkin
.
There is no need for such a pessimist lock with Git: you modify and commit locally whatever you want, and push later to the remote repository.