Git Commands equivalent fo Clearcase commands?

Question

Can anyone help me to know the Git commands equivalent of clearcase commands?

Answer 1

I have documented extensively the differences between Git and ClearCase by the past (file-based vs repo-based, centralized vs. distributed)

This is not about dynamic view and MVFS, since Git is (slowly) incorporating the equivalent, VFS for Git (formely known as GVFS).

This is about:

• what is checked out or committed (selection of files in ClearCase from one or several Vobs), vs. a full repository in Git (even though you now have partial or narrow clone in Git)
• the unit of storage.
  That is the more important criteria to consider when migrating ClearCase Vobs to Git repositories: a possible multiple Terabytes Vobs, vs a Git repository whose size should remain "reasonable".
  Even the Microsoft Windows "largest repository in the planet" is less than 0.5 TB.

If you were using ClearCase UCM, then the relevant unit of work is an UCM component, which is akin to a Git repository:

ct mkview/co <==> git clone/checkout 
ct mkbl      <==> git tag
ct ci        <==> git commit+git push
ct deliver   <==> git merge
ct rebase    <==> git rebase (to an extent)

Answer 2

There is no one-to-one mapping here. ClearCase commands, like ClearCase itself, are file-oriented: one checks in or out an individual file at a time. Git's storage is commit-oriented: a new commit is a new snapshot of every file, not just some changed one(s).

Another fundamental difference is that ClearCase is centralized, while Git is distributed. That is, for each ClearCase VOB, there is a single master VOB (even though it may be replicated). That VOB holds the database of file versions (technically elements). If some duplicate VOB disagrees with the master version, the duplicate is wrong. With Git, however, no one Git repository is any more correct than any other Git repository. If two Git repositories disagree as to the set of commits, both repositories are right.

Besides this, ClearCase offers abilities that Git just doesn't have. Using cspecs, you can construct ClearCase dynamic views that have no parallel in Git. ClearCase also lets administrators lock particular elements, grant limited access rights to specific users, and so on. ClearCase stores directories (and directory modifications); Git stores only files.¹

The two systems are so different that I recommend stepping back from all of this and just learning Git directly. Attempting to map ClearCase concepts onto Git will leave you extremely frustrated.

See also What are the basic clearcase concepts every developer should know? and How to bridge git to ClearCase?

---

¹Sales and marketing types would have you believe that this proves ClearCase superior to Git. I would ask you to consider whether you would like your pocketknife to have hundreds of specialized blades, or just a few really good ones. (Use some other favorite tool analogy here, if you have one.)

Answer 3

It's all about the tool that best fits your needs,and development model. GIT repositories share some issues, from a policy management standpoint, with newly created Multisite repositories. (Policies not applied globally)

An admittedly biased comparison is here: http://www.cccqcommunity.com/blogs/why-use-clearcase-when-git-is-free

Last I checked, GITs vfs is Windows-only, and didn't support the extremely fine grained build auditing the MVFS, combined with clearmake/clearaudit/Omake supports. Whether that's important is your decision.