If you’re using a Git-based source control, you might be familiar with the use of a .gitignore
file to list files which Git is supposed to ignore when tracking files and making commits. This can be particularly useful when using Git (if you’re using GitHub Desktop, you’re also using Git) as a source control tool for projects that generate temporary or user-specific files at every run, such as Unity, as these files cannot be shared across different users of the project.
Sometimes, when setting up the repository, because of a .gitignore
that is not properly set up, files that you intend to be ignored can actually get committed into the repository. If that happens, retroactively applying the .gitignore
list will not help.
1. Why it happens
If you’re only interested in the fix, feel free to move on to the next section. If you’re looking to avoid setting up a .gitignore
list that doesn’t work again, then read on.
Essentially, a .gitignore
list does not work to ignore files that are already committed into the Git repository. This means that if you:
- Make a commit to your Git repository, and then;
- Set up your
.gitignore
list
Then the .gitignore
list will NOT ignore files that are already tracked by your repository. Hence, to avoid this, you’ll want to ensure .gitignore
is set up before you make any commits.
If you are creating your repository from GitHub or GitHub Desktop, you can also choose a .gitignore
template that will be automatically set up for you. Since .gitignore
is always set up before the commit in this way, you will never run into this issue.
Article continues after the advertisement:
2. Fixing the issue
If the files in .gitignore
are already being tracked by Git, what can you do about it?
a. Remove the files to be ignored from the repository
The most straightforward way to rectify this issue will be to delete all the files that are supposed to be ignored from your repository and make a commit. This will cause the files to become untracked by Git.
After the files are deleted, if they are properly listed in .gitignore
, they should no longer be tracked.
b. Revert the commit, and re-commit
If you:
- Haven’t had too many commits for your project;
- Have an initial commit without your project files (i.e. if you’ve initialised your repository in GitHub or GitHub Desktop);
- And are using a interface that allows you to revert to an older commit (such as Git Bash)
You can also consider reverting your project to the initial commit, then re-stage your files and commit again.
First, you’ll want to run git log
, and find the hash (highlighted below) of your initial commit.
$ git log
commit aaeb1de3f39a77af223f55bcabba1c649d3f097f (HEAD -> main)
Author: Terence <terresquall@hotmail.com>
Date: Sat Jun 11 16:31:53 2022 +0800
Initial commit
Then, run git reset
to revert your project back to the older version.
$ git reset aaeb1de3f39a77af223f55bcabba1c649d3f097f
Finally, re-stage your files with git add *
and check that the ignored files are no longer staged with git status
.
$ git add * $ git status
If all goes well, run git commit
after to re-commit your files.
$ git commit -m "Commit with ignored files properly ignored."
3. Conclusion
If the above fixes did not work for you, leave a comment below and we will respond with a solution if we have one. Otherwise, if you have a fix that isn’t listed here, feel free to share it with us in the comments as well!
Article continues after the advertisement: