Truth be told, it's not that Git in and of itself is so perfect for continuous delivery. It's that branching workflows are great for CD, and Git is great for branching workflows. Aside from being CD's BFF, a branch-and-merge workflow lets you tackle thorny bugs, try out new technologies, or just start coding a new feature from scratch without the risk that your changes will prevent your teammates from forging ahead with their own tasks.
Clearly, Subversion and other traditional version control systems let you branch, too. But let’s side-step for a moment and meet branching’s evil twin: the merge.
Traditional version control systems like Subversion are simply not that great at tracking versions of files that live on different branches, and when it comes time to merge, Subversion has to stop and ask for directions a lot. (You know... that little pop-up asking “Do you want this line or that line in the merged version?”) The fact that so much human interaction is required during merges drives teams to institute code freezes so whoever is performing the merge doesn’t get disrupted by new changes coming in on one of the branches. And code freezes are expensive: it’s pretty unproductive time.
Git, on the other hand, is really good at tracking changes to different versions of files that live on different branches, and it always knows what the common ancestor of that file looked like. So it basically has a built-in GPS that lets it navigate merges without having to stop and ask you for directions all the time.
With Git, you're free to exploit the power of branching in a way that would be impractical with Subversion. The overhead involved with branching and merging is so trivial that branches that live only for a day or two become not only feasible, but beneficial.
Ok, fine. But what exactly makes branching so powerful for continuous delivery, anyway?