How do I set up default.settings.php to use it for development, testing and production sites? I use dev, tst and prd environments for my Drupal 7 site set up. 
I use git for version control.

I would like to eliminate one manual step I need to do when moving site from dev to tst and from tst to prd. 

Now I have to update settings.php separately for dev, tst and prd sites.

I would like to set up default.settings.php file so all the settings for dev, tst and prd are stored in one default.settings.php and. after copying to settings.php, Drupal will pick right settings depending on the environment.

I am looking for something like the pseudo code below:

common.settings 

if environment = dev then
   ...
   dev.settings
   ...
else if environment = tst then
   ...
   tst.settings
   ...
else if environment = prd then
   ...
   prd.settings
   ...
end if


Do you know how to do this for Drupal 7, exactly?
Don't use the same settings file like you are suggesting with your pseudocode. Instead, use three different settings files in three different folders, each folder corresponding to the domain name of each of your instances.

As a minimum, generally each environment is going to use a separate database host. Other settings that can differ from environment to environment can include the Apache Solr host, memcached settings, temporary folder and files folder, to name a few. You can place all of those there. When you migrate your database from PROD to TEST to DEV, it will automatically pick up the settings you specified.

Imagine that my site is called myfoobarsite.com. This is how my settings structure would look like:

/htdocs
../sites
..../default
....../default.settings.php
..../dev.myfoobarsite.com (DEV)
....../settings.php
..../qa.myfoobarsite.com (TEST)
....../settings.php
..../myfoobarsite.com (PROD)
....../settings.php


I also generally have two local instances of the site, one with the latest database snapshot from PROD and another where I keep all my changes. This is very useful when working with Features, and it allows you to test your features against the production database (locally) before committing. Here's the modified structure:

/htdocs
../sites
..../default
..../dev.myfoobarsite.com (DEV)
..../qa.myfoobarsite.com (TEST)
..../myfoobarsite.com (PROD)
..../mfbs.local (LOCAL ONE)
....../settings.php
..../mfbs2.local (LOCAL TWO)
....../settings.php


As for your local instances remember to make the appropriate entries in the /etc/hosts file and to modify your Apache host settings.

Just in case, I also placed a snippet from the settings.php for guidance:

&lt;?php
$databases['default']['default'] = array(
    'database' =&gt; 'myfoobarsite',
    'username' =&gt; 'foo',
    'password' =&gt; 'bar',
    'host' =&gt; '127.0.0.1',
    'port' =&gt; '3306',
    'driver' =&gt; 'mysql',
    'prefix' =&gt; '',
);

/**
 * Apache Solr settings.
 * Use the acquia_identifier/acquia_key when hosting w/ Acquia.
 * Specify only the apachesolr_path key for your local instance
 * or instances that do not use Acquia.
 */
//$conf["acquia_identifier"] = "ABCD-12345";
//$conf["acquia_key"] = "1234f05ab12345dc1234a1234bbc1c12";
$conf["apachesolr_path"] = "http://localhost:8983/solr";

/**
 * Filesystem settings (MAC OS X, LOCAL)
 */
$conf["file_public_path"] = "sites/default/files";
$conf["file_temporary_path"] = "/Users/amateurbarista/tmp";
$conf["file_private_path"] = "/Users/amateurbarista/Sites/tfk/private";


Finally, if you're hosting with Acquia, you'll need to go to http://myfoobarsite.com/admin/config/system/acquia-agent and click on "clear keys" every time you migrate the database. That will cause Drupal to drop the keys that came w/ the imported database and pick up the ones specified in the settings file.