It's easy to let your your Drupal core slip behind a point release or two if your workflow doesn't support making quick, painless code replacements. I update core using a patch, which allows me to retain customisations I've made to robots.txt, .htaccess or anything else without messy and dangerous file shuffling.

I much prefer this method of updating Drupal to downloading a new core to a directory alongside, then moving over my sites/*/* directories, various changed files,  messing with permissions etc.

The same approach can work for contrib modules too, but normally 'drush upc foo' works just fine for me there, unless the modules have been patched in some way.

First off, make sure you have drush and git ready to go.

Check your starting point

To find what version of Drupal we're running now, use a drush alias or change directory into your Drupal docroot and use drush status:

This returns me the following:

Download clean 'before' and 'after' Drupals

Using your /tmp directory, download the version of Drupal you're running now, plus the one you intend to update to:

$ drush dl drupal-7.28 --destination=/tmp

$ drush dl drupal-7.29 --destination=/tmp

Create a patch file

You can do this with plain old 'diff' but I prefer 'git diff' because it nicely takes care of the  most appropriate formatting without me having to remember various options.

$ git diff /tmp/drupal-7.28/ /tmp/drupal-7.29/ > /tmp/drupal-7.28_to_drupal-7.29.patch

If you are curious, now might be a good time to inspect the patch in your favourite editor or via 'less', to see what the heck changed between these versions (aside from a lot of .info files having their versions bumped).

Now you have this one patch file between two versions, you can re-use it across as many sites as you have that need that exact update.

Apply the patch to your local working copy

Making sure you're in the root of your Drupal working copy (e.g. /var/www/mydrupalsite), issue a patch command, with a '-p3':

$ patch -p3 < /tmp/drupal-7.28_to_drupal-7.29.patch

Sometimes you might need to play with the -p number a little depending on where you're running the patch from and how you created it.

If things are good you should see something like:

... and so on.

If you are unlucky the patch might complain if it couldn't apply cleanly due to modifications you have made to parts of the code affected by the patch. If this occurs you need to sort conflicts out one way or another; at least this way you know about them :)

One last thing

Don't forget to run 'drush updb' once you're done to catch any schema changes the new code might require. That will also trigger a cache clear too, which is always smart after changing any code.

You should be now right to start testing that nothing about your site became broken by the update. With any luck you'll have the new code committed to your Git repository and deployed soon thereafter!