When Bitcoin was created in 2008 there was no limit to how big the blocks of transactions were allowed to be. Satoshi introduced a limit in 2010 without explaning the reason in detail, but it had to with stopping potential DoS attacks. For example, there is a possibility for a miner with great resources to create blocks so big that other nodes have problems handling them. There are also other aspects of allowing unlimited block size. If all transactions can always fit in the next block there is no incentive for anyone ta pay a fee, and if the total amount of fees is too low the security model breaks down. Here's why:
This limitation makes it so that Bitcoin currently only handles around 7 transactions per second and compared to payment networks like VISA that handle thousands of transactions per second it is obvious that this won't work if the world would use bitcoin for purchases, small and large. This problem gave rise to two different groups that wanted to take Bitcoin in different directions. One group wanted to increase the block size as soon as possible and the other group wanted to focus on optimizations and avoid a hard fork for as long as possible.
The first initiative to a block size increase that got some traction was in 2015 when Gavin Andresen and Mike Hearn introduced Bitcoin XT. Originally Bitcoin XT included an immediate increase of the block size from 1 MB to 8 MB and then subsequent increases every other year. This was an alternative Bitcoin client, based on the code of Bitcoin Core, and their hope was that the majority of users would start using this alternative implementation, making it the "new bitcoin".
Bitcoin XT was not able to get users to switch from Bitcoin Core but pretty soon after people stopped talking about Bitcoin XT another alternative, Bitcoin Classic, showed up. Bitcoin Classic was a bit more conservative and suggested a doubling of the block size to 2 MB, hoping to get more support this way. At first it looked like they might succeed, getting support from Coinbase, Bitstamp and Circle, among others. Still, in the end, users could not be convinced that an immediate hard fork was necessary and the best way forward.
Segwit is a technical improvement of the Bitcoin protocol, whose primary purpose was to get rid of transaction malleability. The solution to this also introduced the possibility of getting a practical block size increase (or, an increase of the number of transactions by calculating block size differently).
When it was realized that SegWit could be implemented as a soft fork this became Bitcoin Core's answer to everyone trying to push a hard fork solution. With SegWit a blocksize increase could be had promptly without the need for a hard fork. During Consensus 2017 in New York a compromise was agreed on between a number of exchanges, miners and others, which consisted of the release of SegWit first, and then a block size increase through a hard fork 6 months later. This became known as the New York Agreement and the implementation of it as SegWit2x.
After SegWit was implemented it still turned out that the hard fork did not have consensus among Bitcoin users and SegWit2x was therefore cancelled in the last minute, before causing a blockchain split.
During the controversy around the New York Agreement another alternative implementation, called Bitcoin Cash, surfaced. Bitcoin Cash raised the block size to 8 MB and was in a way a third incarnation of Bitcoin XT / Bitcoin Classic. The difference this time was that a deployment was actually pushed through, leading to a split, and two different coins, Bitcoin Cash and the original Bitcoin. Bitcoin Cash lives on as an alternative version of Bitcoin and is currently the 4th largest cryptocurrency.
While Bitcoin Cash supporters claim that Bitcoin can function as a payment system simply by increasing the block size, Bitcoin Core supporters work on solutions in a second layer, on top of Bitcoin. The most promising project that has recently been deployed on the main network and is gaining some traction is called Lightning Network. Read more below.