This happens from time to time, but generally it gets fixed down the line in a block or two. the blocks in the chain get passed around like a 'hot - new mp3 of your favorite group" and eventually get handed to a mining rig to work on.
This is where I am still a little fuzzy on how the mining rigs find out about both transactions - but they do, and in most cases, the early bird get the worm, so to speak, and the looser becomes an orphan - if you have done any mining - you have undoubtedly ran into these.
On rare occasions, pool A sticks with it's fork, and pool B sticks with it's fork, and they just keep going until a transfer fails and all heck breaks loose.
-----------------------------------
The is another instance in which a blockchain becomes forked, and that's referred to as a 51% attack (although I don't think it always happens on purpose)
if pool A has 49% of the total hashing power, and pool B has 51%, pool B will, on average find more blocks - hence create more blocks, and pool A will simply fall behind.
I'm sure there are other circumstances that can cause a fork in the road, but once you have a punctured tire - who cares about the cause at the moment ? that's for the dev team to work on so it doesn't happen again
now it's time for questions and corrections, feel free to add both!
edit: forgot to say that yes, I have heard that when the 'code' is handed over to a new dev it can be called a fork. The background in this I think is how the github works. A developer can have a master project, and if someone wants to work on it, they 'fork' it (or duplicate it) to their own work space. then they can work on their own copy and submit there changes to the master developer. In that way - when we get a new dev , they will fork the repository, and if they don't do anything substantial to the way the blockchain works, we will have an updated wallet, without having to re-sync the chain.
