You must use your Global Git Ignore!
The project git ignore is NOT enough. Customise your own workspace to avoid BIG mistakes.
You can create a “.gitignore” file in the root of your repository's (repo) to tell git which files and directories to ignore when you use git commands and make a git commit. This allows us to share the git ignore rules with other developers on the project who clone the repo. That is why the “.gitignore” file itself is committed to the repo.
I think most people are aware of the repo’s git ignore file, particularly when they clone a repo or create a new project with a framework like NextJS, as the git ignore file in the root of the git repo will be there and work its magic 🪄.
Using the git ignore feature is great but it has limitations, which is why I think this file is overused and often incorrectly.
Problem
Most projects in the repo’s git ignore will include almost every possible IDE and dev tools. I believe this is wrong, because:
Everyone uses different operating systems, IDEs and dev tools.
This list will only keep growing, it will never end
Is the “.gitignore” file competing with the “README.md” for the most updated file in the git repo? I hope not 😰
This is for the project specific git ignore file only
Examples of folders included in the git ignore file are generated files like “.next” from NextJS or “test-results” from Playwright. These will be generated for every developer on the project regardless of their OS, IDE etc.
Yes I am saying this is wrong… (let me know if you agree/disagree below)
# .gitignore
.DS_Store
.vscode
.idea
Solution
Global git ignore to the rescue! Adding this file to your system might sound like extra work. However it is actually quite straightforward and will save you from making mistakes that will cause a lot of extra work down the road.
The global git ignore is the same type of file and format as the repo’s git ignore you are familiar with. It is just in a special place on your computer that will affect all your local repos, yes ALL. This means that adding this file just once will benefit all your repos - that sounds great, right? So if you are on a Mac and it generates “.DS_Store” files, there is no need to add this to every git repo you work on and you can remove the risk of accidentally committing this file.
How
I know you are excited to get started, so let’s jump straight in, it will only take a few minutes:
In your home directory, create the file “.gitignore”:
touch ~/.gitignore
Add the contents you would need, for example:
.DS_Store
.vscode
Then tell your git about the new global git ignore file:
git config --global core.excludesfile ~/.gitignore
Then that’s it. Yes, that’s it! 🥳
Maintainers
For those maintainers out there reading this, I know what you are thinking: “But people don’t set this up properly so if I don’t have this in my repo’s git ignore all the Pull Requests come in with these files. So I add them to the repo’s git ignore to make contributors and maintainers lives easier.”
I understand this and I have done this before myself. What I noticed though was that this led to some people taking advantage of this project strategy by making it become a “green square game”. This resulted in Pull Requests containing new items being added to the git ignore file, just to cover every possibility - making the git ignore file many pages long 🤦.
Conclusion
The contents of the repo’s git ignore is for the project only files and folders. Developers can customise their own global git ignore with extra exclusions they need.
As a maintainer, don’t fall into the trap of putting every possible exclusion into the repo’s git ignore. This really is a “sticky plaster” approach in my view. What we should try to do is up-skill and educate the community, so it benefits everyone in the long run.
What do you think/do?
Good one, Eddie
Counter-argument 1: Different projects need different project-specific gitignores: Rust should ignore target/ and Node should ignore node_modules/. Any tool extension that your project's build pipeline depends on that produces artifacts extends this list. The list is finite and well-defined.
Imagine a Node project starts using Yarn, and Yarn produces some lockfile we don't want committed, now every individual contributor must realize this and extend their system-global gitignore, but only for the correct projects.
Counter-argument 2: A project-specific .gitignore is a tool to lower garbage content in commits by decreasing the effort for inexperienced or lazy collaborators. The .gitignore only needs to contain things actually encountered. For very active Open Source projects, you may want to just put the extra effort into code reviews.
A system-global .gitignore solves a problem for you.
A project-specific .gitignore solves a problem for many people.