What I do is, on dev machines I make all of my Drupal files owned by my user account (e.g. developer1), and I make the group www-data. I use chmod g+w to give write access to the web server on the directories that need it (see article quoted above in question comments, http://drupal.org/node/244924).
On production and staging machines, I make all of my Drupal files owned by a special www-admin user, and give sudo access to www-admin to any user account (e.g. developer1) that might need it. I then can do, for example,
sudo -u www-admin git pull if I want to operate on the Drupal files. (Aside: I usually store my git root at /var/www/drupalsite.com, and point the webserver document root at /var/www/drupalsite.com/htdocs. This puts the .git directory outside the web root, and also gives me another place to put file and directories that belong with the site, but should not be served by the webserver, e.g. D7 private folder.) If I am hosting on a small shared hosting site, I sometimes keep only the dev site under git revision control, and use
drush rsync @dev @prod to push just the files over. By making the Drush site alias remote-user www-admin and setting the Drush rsync mode to 'rlptz' (e.g.
$command_specific['rsync'] = array('mode' => 'rlptz');), then the filesystem modes will be copied over (so the folders that are g+w on dev will be g+w on prod), but all of the files will still be owned by www-admin on the target site.
I'm supposed to write some docs about this for Drush, but have not yet. :p See: http://drupal.org/node/1343892 and referenced issues.
Update: I'm in-progress on working on a Drush command to fix / set permissions. See http://drupal.org/node/990812. The default values used in that command give some hints on ways to set permissions, although different strategies are possible.