For example, banne.gif,config_mysql.php.
banner.gif is necessary when coding because we need to check css layout,and designer always change it.
config_mysql.php is necessary when coding because we need this file to run mysql,and we cannot use production version.

I am not sure whether git add those files or put those files in .gitignore.

What's the best way to process those kinds of files in git?

Keeping environment specific configuration values outside of the source controlled code repository is generally a good idea since code should be able to run anywhere, only configuration should change.

Solution 1: Sample files

Instead of keeping config_mysql.php inside the reposiotry keep a file called config_mysql.php.sample and add config_mysql.php to .gitignore

People cloning or branching out from master locally can then specify their property values config_mysql.php, which is added to .gitignore and thus not impacting the git tree. A developer only edits the config_mysql.php.sample file if config is added/removed (which is information that needs to be added to the source code repository)

Solution 2: Keep configuration values in environment variables

Instead of specifying the actual values for the keys in config_mysql.php.sample pull them from environment variables.

$db_host = $_SERVER["MYAPP_DB_HOST"];

$db_user = $_SERVER["MYAPP_DB_USER"];

// and so on

This way there is only one configuration file, which is under source control together with the code, and developers set their local values by setting environment variables. Shared enviornments like prodution and staging need to either be prepared with those environment variables or the deployment tool can take care of injecting them.

Summary

I tend to like solution 2 better, since there is no need for sample files and it is easy to override configuration). It can even be extended by providing default values if the environment variable is not set. This is not suitable for all types of configuration values and should be used with care to avoid accidental connections to for example a production database

There's not really one answer that's always right. It can depend on any number of things. Some very general advice follows, and you can find more information from existing questions/answers.

Image Files

If they're small and/or not frequently changing, you can consider just adding them and not worry too much about it. While git isn't as good at handling binary files, the main problem they cause is bloating the repository; and at moderate sizes it's not a big problem.

For the purpose you describe, you might reduce the size (and possibly the frequency of change) by using properly-dimensioned placeholders.

If image files are going to be a problem, you could use a tool like git lfs, which keeps the repo size under control by providing a secondary repo for files like large binaries.

Environment-specific Files

My general advice is to .gitignore these and use your build project to bring in (and/or construct) the correct version for the build's target environment. For example, you could check in a template file from which each environment's version of the file could be constructed, then have your build process fill in the template based on a variable that specifies the environment.

In my opinion, you can have two versions of banner.gif and config_mysql.php.

For example, you can check in to Git these files:
config_mysql.php and config_mysql_dev.php

On production, use config_mysql.php file.

And on your local machine, you can rename the file config_mysql_dev.php to config_mysql.php
to use it.

Similar things can be thought for banner.gif...