There has never been a hard fork of Bitcoin, as most would define it, where the entire network needs to coordinate a protocol update at the same time. The closest Bitcoin came was in 2013, due to an unexpected software error and it caused significant disruption, and in 2012 where the protocol made a backwards incompatible change but it only affected clients over 2 years old which as far as developers could tell were not in use.
It's been really tough to get solid information on this, but I don't think the statement about lack of a hard fork is correct.
The two examples that I've been able to find:
0.8.1 introduced a:
"new block-acceptance rule that will be enforced from 21 March 2013 until 15 May 2013 to prevent accepting blocks that fail to validate on pre-0.8 peers."
The imposition of this rule was a soft fork. Its automatic expiration was a hard fork. This was an emergency attempt to fix the March 2013 chain split:
https://bitcoinmagazine.com/articles/bitcoin-network-shaken-by-blockchain-fork-1363144448
0.8.1 also appears to set a block size limit of 0.5 MB. It's not clear if this was a soft or hard fork, but this question about it remains unanswered after a month:
The second hard fork was when the inflation schedule was changed. You read that right. Read more in BIP42:
https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki
This second example is interesting in that it made a change that wouldn't affect the network for another 130 years or so.
As far as I can tell, these are the only two incidents of a "hard fork," defined as an update that changes the protocol in a backward-incompatible way. I'd be happy to be proven wrong, though, either in categorizing these as hard forks or in other updates qualifying.