Skip to content

A How-To Guide for Ignoring Files in a Git Project Using .gitignore

Learn to learn code faster, using techniques honed by years of study, neatly packaged into one book: How to Learn Code

In every project you may see a small file and wonder what it is.

Most projects that use Git have it.

Cloning is smooth, excluding and including files for some mysterious reason.

Ignoring files when uploading and downloading a code source is a very important part of using Git.

As a contributor to a source you may wonder how ignoring files works and the use cases for each method.

Let’s talk about how this is done.

What is .gitignore?

When using Git with a code project you have the option to create commits based on file changes.

Often developers create either huge commits or small micro commits each with a varying number of changes.

Within those changes new files & folders will popup.

Some will be inappropriate to place to the public.

Examples of these include credentials, personal notes or executables only you are using.

In these cases you have the option to ignore the file or folder in Git.

This way when you upload the project to say GitHub, GitLab or others you do not upload that specific file or folder.

It remains local to the computer and nowhere else.

This is done inside a .gitignore file.

.gitignore is automatically detected within your Git project by Git once you add it to the current commit or create a new commit.

Like the .git folder, Git considers the contents of .gitignore in all changes to a project.

Here is what it looks like…

All you have to do is ensure your project is a Git project then create the file in either the root directory or subdirectories.

It is simply a file which lists the ignored files and folders line by line.

The patterns within .gitignore reference the current directory it itself is in.

You cannot use full directory paths as it will be different when someone else downloads your Git project.

It only operates on relevant paths like this:

Notice how it works in the directory the .gitignore file is in.

Also, although many tutorials and LLMs state you can ignore files in the parent directory of the .gitignore file it doesn’t seem to work, at least for me.

In this picture a.txt seems unaffected by .gitignore.

But if I ignore a file within the current directory or sub directory .gitignore will work.

So this means you can have multiple .gitignore files as long as you include them in your commit.

.gitignore syntax

Let me give you an example of a .gitignore…

This one is in the highest directory of the Git project.

This means it will work with every directory and subdirectory within that project.

Here we are ignoring the files noted with pattern from top to bottom, line by line.

Patterns that are included in .gitignore syntax are the following:

  • *, *.txt, folder/*: Wild card, all file and folder names within that directory.
  • **, folder/**/file.txt: Double wildcard means all file and folder names and the subdirectories of the folders.
  • folder/: denote difference between folder and file by ending with a slash
  • text.txt: Denote a file by not placing a slash and make sure to include the extension.
  • !folder/, !text.txt: The not sign means do not ignore.
  • #Comment: Hash sign means comment

Git automatically scans the entire project looking for those patterns and discluding them from the project.

How do IDEs work with .gitignore?

IDEs typically use a hook into Git to color their files and folders according to the status of that file according to Git.

There are 8 types of file status in Git.

Each IDE colors and handles these status differently.

Here is a list:

  • Ignored: A file added to .gitignore
  • Unmodified: Nothing happened to that file but it is still in the commit
  • Modified: File changed from commit
  • Untracked: Never added to Git project
  • Staged: Newly added to Git project
  • Deleted: Removed from current commit
  • Renamed: File name changed
  • Copied: A file copied to another folder

I will give you a few examples of an IDE coloring a file according to Git status.

Here are a few in JetBrains:

JetBrains: Red means untracked
JetBrains: White means unmodified
JetBrains: Blue means modified
JetBrains: Green means newly staged or renamed
JetBrains: Dark gold means ignored

In Visual Studio & Visual Studio Code, the colors will be different but the status types will be the same.

By knowing the color of ignored files you will know if .gitignore is working.

Why should you include .gitignore in Git?

The whole purpose of .gitignore is to include it in Git.

Your goal should be to have one code source that works for all developers in the project.

It should be secure and all credentials should be outside the code source.

They should be ignored

.gitignore vs git exclude?

In the case where you are adding files to the Git project but you do not want other to really know, or is irrelevant to them, we can use Git exclude.

Git exclude is meant for you, the individual developer.

Let’s say you want to add a text file to the project to take notes but don’t want to show it in .gitignore.

To ignore a file without placing it in .gitignore you exclude it.

Exclude is different than ignore in that no one but you will know about it when you upload your Git project.

Take a look…

Inside the .git/info/exclude file you can add patterns just like .gitignore.

The difference is it is not included when you upload the Git project and the patterns work in the root directory of the code source.

Notice a.txt above is colored dark gold and is ignored.

The reason it is not visible to others, is .git is considered invisible to the developer by Git.

On GitHub, GitLab and others you will see .gitignore but you will not see .git for the sake of automation.

In all projects .git is hidden as it is where all actions are saved by Git, including commit history and current changes.

Anywho, I hope you learned something…

CTA: Check out my other articles and follow me on medium.

Happy coding!

Resources

Introduction to Git: https://jessenerio.com/what-is-git-an-insightful-answer-to-how-coders-work-in-teams/

Why use Git: https://jessenerio.com/how-version-control-is-the-best-way-to-save-your-code/

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

Search this blog

Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

Newsletter

Subscribe now to get my library of freebies + weekly emails with coding, tips for learning, and resource tips.

Learn to learn code faster, using techniques honed by years of study, neatly packaged into one book: How to Learn Code

Top content