DEV Community

Cover image for Locally Ignoring Git Files
Scott
Scott

Posted on • Updated on

Locally Ignoring Git Files

Have you ever wanted to maintain some local files in your git repository? Have you had to try juggling not staging those files so as not to effect the project configuration settings? What if you could add those files, have them ignored, but not touch your .gitignore file? Let's take a quick dive into how (and why) we might do that!

Why Exclude Local Files

Let's start with the why? There are a number of reasons you might want to investigate ignoring local files in your repository that are specific to you but not the project as a whole.

My use case is using containers to run my development environments. They simplify dependency management, are easy to setup and even easier to completely remove (completely) and let me take advantage of a Linux based environment on my Windows PC.

The easiest way to do this in VS Code is to add a .devcontainer folder in the project root. You can find the documentation about development containers in the VS Code Documentation if this is something you might be interested in.

Our project however might not be set up for development containerization (for any number of reasons) and we certainly don't need to throw that requirement to the rest of the team if this workflow is something unique to me.

So now I have a .devcontainer folder (and its associated files) in VS Code but don't want to accidentally commit it, now what?

Git Handles Local Ignores

There is already a solution to handle this very problem in git which we can read more about in the Git Documentation.

All you need to do is open /path/to/project/.git/info/exclude. The file will already be there and follows the same syntax as the standard .gitignore, so editing it is a breeze.

Note: Windows users may need to show hidden files and folders if editing this via the Explorer.

This file exists for:

Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow)

For my use-case I have added .devcontainer to this file and now don't worry about having to check this one into the shared team repository. Nice!

Top comments (0)