This is a non-trivial problem that almost everyone has a different answer for: there isn't a canonical Drupal way to handle staging to production pushes. Dries Buytaert, the guy who runs the Drupal show, made it one of the key initiatives of Drupal 8. Of course, Drupal 7 was just released, so it'll be a while before that bears any fruit.
The problem can be broken out into two separate issues:
- Staging configuration (variables, content types, fields, views, etc.)
- Staging content (nodes, users, etc.)
The former can be mostly handled by the Features module, which will take your site configuration and turn it into a module you can add to your Drupal installation: this way, you can add it to your version control system and not having to worry about it being blown away when you migrate your content.
The latter is really tricky, because on an active site, it's likely the content will change on production even after you've made the initial sync to your development environment. This prevents wholesale replacement of content during staging like you can do with configuration.
Additionally, Drupal doesn't use universally unique identifiers (UUIDs) for content: every time a node or a user is added, the ID increases by one. So what might be node 45 on your development site might be node 90 on your production site.
Unfortunately, I don't have a great solution for this: staging content is a real weakness of Drupal. What I personally do is add content on the production site only. If a client wants to see how the content looks prior to it going live, I'll set up a clone of the production site that's only accessible to the client. Then, once approved, the same changes are then made directly to production.
There's another alternative that gets tossed around: the Deploy module. It's supposed to leverage Services to make staging content relatively painless. But I can't vouch for its effectiveness and it doesn't have a Drupal 7 version.