Anatomy of a .gitignore
When we work on a software project, we use Git as version control — or at least, I hope y’all do! Having a version control system (VCS from now on) allows us to have a history of the changes we can later audit, to mix our work with others’, and to have an authoritative copy of the project’s codebase.
But not everything should be stored into version control! Compilation artifacts, temporary files, and sensitive information such as API keys and keystores should all be kept out of Git. How does this work? As most folks know, Git uses .gitignore files to list out what should be kept out of version control.
What many folks don’t know is what’s in a .gitignore file, how to create one easily, what advanced features are available, and how they interact with other systems in Git and with each other. This post expands on a very old post of mine about how to manage the .idea folder in version control for the benefit of the whole team. You can go read that immediately if you wish, but I will provide a tl;dr and some more up-to-date recommendations here, so you don't really need to.
What do .gitignore files do?
The basic concept is simple, and you can read the comprehensive documentation… or you can just think of them this way: .gitignore files tell Git what files and folders it should pretend don't exist. Git will not track changes in those files and folders anymore, from the second you add them to the ignored list.
⚠️ NOTE!
From now on, we’ll also call
.gitignorefiles ignore files, and use the terms exclusions and excludes as synonyms to (collections of) ignored items.
Confusingly, there are other mechanisms in Git that achieve similar results:
- Global excludes — this is a global file in the same format as an ignore file, whose path is set in the
core.excludesFileGit configuration) - Repo-wide excludes — an ignore file at the special path
.git/info/exclude
You can have different .gitignore files in different folders around your repo, each taking effect for that directory and its children:
The closer an ignore statement is to a file it matches, the higher priority it has. This means that, for a file in the app/src folder in the example image above, the red .gitignore takes precedence over the blue one, which in turn takes precedence over any repo-wide, and then global, exclusions. If there are no conflicts between different sources, the effects of all ignores are cumulative as you get to narrower scopes.
Curious? Want to continue reading this article? You can find the full post over on my blog:
I’m trying to gain more control over what I publish and where, so you can only find full versions of my posts on my Ghost-hosted blog. I’ll keep cross-posting teasers here on Medium to get visibility, but the full articles are going to only appear over there. All the previous articles from Medium have been migrated over — don’t worry, they’re still available here, and as always, they’re free and ad-free. Bonus: articles look better over there, as I have fewer limitations than I do here on Medium.
