A reorg is done only if a block being imported on a side fork leads to a higher total difficulty on that particular fork than the canonical fork. The blocks nonetheless still need to be valid.
As written in the Ethereum blog, Chain reorganisations happen when a node on the Ethereum network realises that what it thought was the canonical chain turned out not to be. When this happens, the transactions in the latter part of its chain (i.e. the most recent transactions) are reverted and rather the transactions in the newer replacement are executed.
With Ethereum having a short target block time of 15s, this actually happens naturally rather often. Because it takes time for the blocks to percolate through the network, it’s easy for different parts of the network to have a different final block (or two, or perhaps even three) in normal operation since the miners often come up with them at roughly the same time. This is what we might call ephemeral forking.
When a re-organisation happens, or put another way, when the network reaches a more global consensus that it had earlier and a fork is resolved, the nodes that had the now out-dated chain “reorganise” their chain, throwing away the recent and no-longer canonical blocks. Transactions are reverted and others executed to get in line with the other path of the fork.
When chain reorg occurs in Ethereum, the common way is first find common block, insert the block with the more total difficuty, and keep the transaction within the old chain but not within the new chain back to txpool. You can read more about Chain Reorganisation issues here as well.
