Having the repo makes it a snap to deploy code from your computer to a production server, because you just "clone" the repository to that server. That means that you can make a bunch of changes to the code on your computer, then tell the production server to pull all of those changes from the master repo.
GitHub is a hosting service for your code. It understands the language of git, and lets you store a clone of your repo in the cloud. That lets you 1) deploy from the GitHub server to your production server, 2) enable other folks to view the code and clone it to their own environments, 3) use some additional functionality around the repo, like getting a pretty UI to view all your commits, an easy way to zip your code to send to others, etc.
Apparently git can do a lot of stuff, but I've used it mostly for a very simple deployment workflow. After I cloned the repository first on GitHub and then from GitHub to my production server, deployment for me is now just three steps: 1) commit any changes to the code on my computer ("git commit -a -m 'Description of the snapshot'"), 2) push the new code snapshot from my computer to GitHub (git push), 3) pull the new code snapshot from GitHub to my production server (ssh into production server, then "git pull"). It takes about a minute each time. If it ever got much more complicated, I'd probably investigate using a deployment library like Fabric to manage these tasks.