This is a fairly common question, and there isn't a One True Answer.

These are the most common techniques:

1. Modify your app such that, before loading its config from e.g. config.ini, it first looks for e.g. config.mine.ini, and loads it instead if it exists. Track a standard config.ini in your repo, but if you need to override the values in it, copy it to config.mine.ini and modify. Then configure git to ignore config.mine.ini.
2. Modify your app such that it first loads e.g. config.ini, but then attempts to load e.g. config.mine.ini, and if it exists, uses keys from config.mine.ini to override those obtained from config.ini. This is similar to the first approach, but means that config.mine.ini needs to specify only options that you don't want to override. Thanks to shrugger for this one.
3. Have your app look at environmental variables for its config, before using the values from its config file. Then set those variables as approapriate (e.g. in your .bashrc for shell scripts, or somewhere in your webserver's config for web apps). Only works if your app doesn't need much config, but can be a useful behaviour for simple apps.

1. Have your app just look for e.g. config.ini, but don't track this file. Instead create and track e.g. config.sample.ini. Everyone who clones the repo has to copy config.sample.ini to config.ini, but they can modify config.ini as much as they want.
2. Use some gitattributes clean/smudge magic as suggested by SethRobertson, see the other file in this gist.
3. Use a local configuration branch. This is a more complex setup, but allows the config files to be stored within, and tracked by, git.
4. Not recommended: If all of the previous suggestions won't work for some reason, look at the "assume unchanged" section in man git-update-index. Anyone who's tried this normally ends up hating it.

This approach was presented by SethRobertson on #git. I haven't had a chance to play with it, and it has some caveats (see below), but it's a nice idea.

First, read up on gitattributes. One Two. Pay attention to the smudge/clean filters.

Create a local branch called "private", which contains your personal config.

The following script sets up the the smudge/clean filters for all files in SUBDIR

#!/bin/sh
#
#
SUBDIR=z
x=0
find $SUBDIR -type f | while read f
do
  echo "/$f     filter=private_$x" >> .gitattributes
  git config filter.private_$x.clean "/tmp/clean $f"
  git config filter.private_$x.smudge "/tmp/dirty $f"
  x=$(($x+1))
done

The smudge filter is executed on git checkout, and replaces the contents of every file identified by the setup script with the corresponding file from the "private" branch.

#!/bin/sh
git show "private:$1"

The clean filter is executed on git add, and replaces the contents of the (locally modified) files identified by the setup script with their tracked versions from the current branch.

#!/bin/sh
git show "HEAD:$1"

Note that there's no way to tell which branch is being checked out. Therefore, before checking out out the "private" branch, you have to disable the filters. Renaming .gitattributes is one way of doing this.

Also, SethRobertson alluded to the presence of an undocumented "%f", which would remove the need to create a separate smudge/clean filter pair for every file.