Q:

Why exactly is Git's pull and push approach better than Clearcase's locking and hijacking approach? 

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? 

A:

Pick your choice - do you prefer always getting a warning when there might be a potential conflict in the near future since two people are going to edit the same file (Clearcase)?  Or do you prefer to get a warning when the VCS detects there is an actual conflict since the two people edited the same source code lines, or lines very near to each other (Git)?  
The first model produces some false positives from time to time, which can be annoying.  At a first glance, the second model seems to have a higher risk to introduce bugs.  That is because when a merge is formally successful and you get no warning, there is a certain risk of having a "semantic" conflict, only revealed by tests.  However, to my experience, in reality the latter is neglectable - I cannot remember ever to have encountered such a situation in the last 10 years.  Moreover, the first model has indeed the same risk, since just because you get a warning about a simultaneous edit beforehand does not automatically ensure the two developers will inspect their merge results afterwards more carefully. 

A:

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.