To elaborate on dolinsky and the article, if your web server is doing a "git pull", it means it has ssh access into your workstation. If someone breaks into your web server, this means that they have ssh access into your workstation as well by simply using the keys on your web server. This is bad, very bad.
If you push to your web server, only your public key is exposed if your web server is compromised.
Not necessarily. If you run an ssh-agent locally and configure ForwardAgent to 'yes' for connections to your web server you can ssh to your server and use ssh from it without actually putting your private key on it.
I don't know if he meant that he git pulls from his workstation. I git push out to a bare repository on my server, and then I ssh in and git pull from the local bare repository into the project's working directory on my server. This doesn't leave the keys for my workstation on the server, but I still have to log in and git pull in the wd.
Good / bad are relative terms. Neither situation would be recommended for a site with a code base that pulls from multiple resources / pushes to multiple servers on every release, but for a single server environment this could suffice.
As for the difference b/w your method and the OPs, he defines it here :
> This is more convenient than defining your workstation as a remote on the server, and running "git pull" by hand or from a cron job, and it doesn't require your workstation to be accessible by ssh.
One advantage of the article's method is that it works if your workstation doesn't have a public IP address or is behind NAT / a firewall. It also works if you move around. With the article's method, you could have your laptop at home update your website, then go down to the local coffee shop and update your website from there.
If you push to your web server, only your public key is exposed if your web server is compromised.