Git Ignore File: How and When to Use It
Artifacts are produced throughout the development process. These large binary assets can be completed builds, precompiled headers, object code, library files, etc.
During the build process, you may need to use artifacts. But what if you are not making any changes? Can you still add it to a repo? Do you need to version it?
Git Ignore File –– When to Use It
What many don’t realize is that it’s possible to add an artifact file to a repository. Then you can use the git ignore file feature to intentionally untrack the file. It may seem a little counterintuitive to add files to the version control that are chosen to be ignored, but there’s a method to the madness.
Including a git ignore file in your repository allows developers on the project to use the file. It also:
- Improves the “signal to noise ratio” for any Git command.
- Allows builds to come from one source.
- Avoids potentially costly commits of files that shouldn’t be versioned.
In short, it’s a good practice to develop a git ignore folder for every project. Then you can custom-tailor it depending on the types of files or artifacts that need to be included.
Git Ignore File –– How to Use It
So what should you ignore? To help decide what files to add to your .gitignore folder start by asking:
- Is the file used by your project?
- Are the files used by other people on your team?
- Is the file generated by another process?
If the files are not used by your project or other team members, it can be ignored. If the file is generated by another process, like a build runner, then it can be put into the .gitignore file. Some common file types to ignore include:
- OS files.
- Application files.
- Language files.
- Package managers.
Sample Git Ignore File
# This is an example of a comment, # whereas blank lines are ignored. *.obj *.lib !MySpecialCode.obj
Any file that ends with the *.obj and *.lib extensions –– except a file named MySpecialCode.obj –– will be ignored. For individual files, Git processes the contents of the file one line at a time. This makes it possible to develop quite precise matching rules with a little effort. And because all your artifacts are in one folder, they do not get lost.
Version Everything With Perforce + Git
Having all your assets in a repo –– even if some are ignored –– has several benefits. It is less for admins and developers to maintain. It can create a single source of truth. But with Git, this severely impacts performance. Even using tools like Git LFS for artifacts can slow you down.
You can more easily version artifacts using Helix Core –– version control by Perforce. Then you can combine these artifacts with the Git repos stored in Helix4Git. Using the power of the Perforce server, you get 80% faster builds. This accelerates development and your releases.
Want to learn more? Explore Git best practices.