Git’s Pull and Push Approach vs. Clearcase’s Locking and Hijacking

clearcasegitversion controlworkflows

I'm trying to convince colleagues about using Git, and somehow it's hard to explain the advantage of doing a pull before a push, because just before pushing, some other developer has pushed his changes to the server and by the time I pull his changes and merge it, some other developer would've pushed his changes and I'm supposed to merge those too before I can push my changes. Loop infinitely.

In Clearcase, you can lock a file you're working on, so that nobody else can modify it. If they want to modify it, they have to 'hijack' it on their local machine and later merge it. Somehow, this seems to be a safer (but annoying) way of working with the files.

So how exactly is Git's approach an advantage?

Best Answer

First of all, Git is a decentralized VCS (as opposed to ClearCase, which is very centralized: see "What are the basic clearcase concepts every developer should know?")

That means, there is no central server to keep track of a "locked" file.

Secondly, you generally don't just pull, but you pull --rebase with autostash in order to replay your local (not yet pushed) modification on top of whatever concurrent modifications were published (pushed).

This is the natural workflow to allow concurrent collaboration.
Note that ClearCase allows for concurrent modifications as well, at least in snapshot views (but you cannot easily tell which hijacked file was modified).

Finally, there isn't much going for the old (1985) ClearCase model (See "ClearCase advantages/disadvantages"). Using it in 2015 is an anachronism, as it doesn't scale well with large number of files, unless you are using dynamic views, and even then, any merge is dreadfully slow.
If you have to go on using an IBM tool, consider at least RTC (Rational Team Concert). It does have a locking mechanism.

Related Topic