Tell Git to ignore changes to tracked files

This post is a short one and is as much a note to myself as anyone else. I have used this essential command many times in the past, but I use it so infrequently I always have to go and look it up when I come to need it. This post will be much quicker for me to find 🙂

Sometimes you find that you need to make a change to a file (often a config file) that makes sense for your local development environment, but would not be suitable for other development environments. This can easily happen you have team mates with different environments, or you work on multiple machines.

When this happens, you don’t really want your changes to be pushed out to everyone else as they’ll have different needs, and your changes will break the code on their machine. You need to stop the changes going out somehow.

One option is to add the file to the gitignore file, and not track the file at all and have everyone maintain their own copy of the file. But what if that file contains both production and  dev config options? A perfect example of this (for rails devs) is your database.yml file. It has your development database’s password/ports etc in it. Your team mates will invariably have different settings. You don’t want to remove the file from the project as it also contain the database configuration needed on the production server. So what is the solution?

What you want to do is to make the change to the file on your development box, but for Git to ignore that change so that when you commit other changes Git doesn’t commit your ignored file.

As luck would have it GIT provides an easy way to do this. Just run the following command (with <file> being the file you want GIT to ignore) and you are off to the races:

$ git update-index --assume-unchanged <file>

If you find that you need to commit changes to that file in the future, then you can tell Git to start watching for changes with the following:

$ git update-index --no-assume-unchanged <file>

Handy Hint: If you run this command make sure you tell your team mates that a change is coming down the line for that file because all sorts of fun starts to happen when you make a change like that 🙂

And now I can get back to development.