I just did a git init
on the root of my new project.
Then I created a .gitignore
file.
Now, when I type git status
, .gitignore file appears in the list of untracked files. Why is that?
git add self && git commit -m "-1 for reverting existential depression" && git remote rm HEAD
how to gitignore .gitinore file
and the question and accepted answer aren't really related to title. Title could be improve.
The .gitignore
file should be in your repository, so it should indeed be added and committed in, as git status
suggests. It has to be a part of the repository tree, so that changes to it can be merged and so on.
So, add it to your repository, it should not be gitignored.
If you really want you can add .gitignore
to the .gitignore
file if you don't want it to be committed. However, in that case it's probably better to add the ignores to .git/info/exclude
, a special checkout-local file that works just like .gitignore but does not show up in "git status" since it's in the .git
folder.
See also https://help.github.com/articles/ignoring-files
If you want to store the list of ignored files outside of your Git tree, you can use the .git/info/exclude file. It is applied only to your checkout of the repo.
~/.gitignore
so they're ignored for any repository I work on.
git update-index --assume-unchanged <file>
to stop tracking changes without changing your repo. This is very useful on large shared projects where you need to make local changes, but nobody else wants to see your stuff committed to the repo. See blog.pagebakers.nl
You could actually put a line .gitignore
into your .gitignore
file. This would cause the .gitignore
file to be ignored by git. I do not actually think this is a good idea. I think the ignore file should be version controlled and tracked. I'm just putting this out there for completeness.
git rm --cached .gitignore
You can also have a global user git .gitignore
file that will apply automatically to all your repos. This is useful for IDE and editor files (e.g. swp
and *~
files for Vim). Change directory locations to suit your OS.
Add to your ~/.gitconfig file: [core] excludesfile = /home/username/.gitignore Create a ~/.gitignore file with file patterns to be ignored. Save your dot files in another repo so you have a backup (optional).
Any time you copy, init or clone a repo, your global gitignore file will be used as well.
If someone has already added a .gitignore
to your repo, but you want to make some changes to it and have those changes ignored do the following:
git update-index --assume-unchanged .gitignore
.git/info/excludes
exists.
--assume-unchanged
exists too. Why is one better than the other?
.git/info/excludes
does not work if the file is already tracked.
After you add the .gitignore
file and commit it, it will no longer show up in the "untracked files" list.
git add .gitignore
git commit -m "add .gitignore file"
git status
Just incase someone else has the same pain we had. We wanted to exclude a file that had already been committed.
This post was way more useful: working with .git/info/exclude too late
Specifically what you need to ignore a file is actually use the command git remove See git rm (http://www.kernel.org/pub/software/scm/git/docs/git-rm.html)
you test it by going
git rm --dry-run *.log
(if you say wanted to exclude all the log files)
this will output what would be excluded if you ran it.
then
you run it by going
git rm *.log
(or whatever filename path / expression you want to)
Then add a *.log
line to your .gitignore
file.
git status
if they show up in the future.
Of course the .gitignore file is showing up on the status, because it's untracked, and git sees it as a tasty new file to eat!
Since .gitignore is an untracked file however, it is a candidate to be ignored by git when you put it in .gitignore!
So, the answer is simple: just add the line:
.gitignore # Ignore the hand that feeds!
to your .gitignore file!
And, contrary to August's response, I should say that it's not that the .gitignore file should be in your repository. It just happens that it can be, which is often convenient. And it's probably true that this is the reason .gitignore was created as an alternative to .git/info/exclude, which doesn't have the option to be tracked by the repository. At any rate, how you use your .gitignore file is totally up to you.
For reference, check out the gitignore(5) manpage on kernel.org.
First of all, as many others already said, your .gitignore
should be tracked by Git (and should therefore not be ignored). Let me explain why.
(TL;DR: commit the .gitignore
file, and use a global .gitignore
to ignore files that are created by your IDE or operating system)
Git is, as you probably already know, a distributed version control system. This means that it allows you to switch back and forth between different versions (even if development has diverged into different branches) and it also allows multiple developers to work on the same project.
Although tracking your .gitignore
also has benefits when you switch between snapshots, the most important reason for committing it is that you'll want to share the file with other developers who are working on the same project. By committing the file into Git, other contributers will automatically get the .gitignore
file when they clone the repository, so they won't have to worry about accidentally committing a file that shouldn't be committed (such as log files, cache directories, database credentials, etc.). And if at some point the project's .gitignore
is updated, they can simply pull in those changes instead of having to edit the file manually.
Of course, there will be some files and folders that you'll want to ignore, but that are specific for you, and don't apply to other developers. However, those should not be in the project's .gitignore
. There are two other places where you can ignore files and folders:
Files and folders that are created by your operating system or IDE should be placed in a global .gitignore. The benefit is that this .gitignore is applied to all repositories on your computer, so you don't have to repeat this for every repository. And it's not shared with other developers, since they might be using a different operating system and/or IDE.
Files that don't belong in the project's .gitignore, nor in the global .gitignore, can be ignored using explicit repository excludes in your_project_directory/.git/info/exclude. This file will not be shared with other developers, and is specific for that single repository
.gitignore
.gitignore
only works for ignoring files that are not being tracked by Git yet. Adding an already tracked file to .gitignore
will not prevent you from commiting changes to that file. Even if this were possible, how would you commit the changed .gitignore
when it instructs Git to ignore itself?
The idea is to put files that are specific to your project into the .gitignore
file and (as already mentioned) add it to the repository. For example .pyc
and .o
files, logs that the testsuite creates, some fixtures etc.
For files that your own setup creates but which will not necessarily appear for every user (like .swp
files if you use vim, hidden ecplise directories and the like), you should use .git/info/exclude
(as already mentioned).
Watch out for the following "problem" Sometimes you want to add directories but no files within those directories. The simple solution is to create a .gitignore with the following content:
*
This seams to work fine until you realize that the directory was not added (as expected to your repository. The reason for that is that the .gitignore will also be ignored, and thereby the directory is empty. Thus, you should do something like this:
*
!.gitignore
This seems to only work for your current directory to get Git
to ignore all files from the repository.
update this file
.git/info/exclude
with your wild card or filename
*pyc *swp *~
If you've already checked in .gitignore and you want to ignore modifications to it, check out this answer:
Try using this command: git update-index --assume-unchanged FILENAME_TO_IGNORE To reverse it (if you ever want to commit changes to it), use: git update-index --no-assume-unchanged UPDATE: Here's how to list 'assume unchanged' files under current directory: git ls-files -v | grep -E "^[a-z]" As the -v option will use lowercase letters for 'assume unchanged' files.
In my case, I want to exclude an existing file. Only modifying .gitignore not work. I followed these steps:
git rm --cached dirToFile/file.php
vim .gitignore
git commit -a
In this way, I cleaned from cache the file that I wanted to exclude and after I added it to .gitignore.
Navigate to the base directory of your git repo and execute the following command:
echo '\\.*' >> .gitignore
All dot files will be ignored, including that pesky .DS_Store if you're on a mac.
It is quite possible that an end user wants to have Git ignore the ".gitignore" file simply because the IDE specific folders created by Eclipse are probably not the same as NetBeans or another IDE. So to keep the source code IDE antagonistic it makes life easy to have a custom git ignore that isn't shared with the entire team as individual developers might be using different IDE's.
I found that the best place to set up an ignore to the pesky .DS_Store
files is in the .git/info/exclude
file.
IntelliJ seems to do this automatically when you set up a git repository in it.
.gitignore
is about ignoring other files. git is about files so this is about ignoring files. However as git works off files this file needs to be there as the mechanism to list the other file names.
If it were called .the_list_of_ignored_files
it might be a little more obvious.
An analogy is a list of to-do items that you do NOT want to do. Unless you list them somewhere is some sort of 'to-do' list you won't know about them.
I think that there are situations where ignoring the .gitignore is very useful. For instance, when you have multiple teams or a large team working on the same codebase. In that case, you need to have certain conventions, one of those convention is regarding what is ignored at the git repo. It is usually about ignoring files and directories created by IDE or OS, some generated logs, etc.
However, there is a force which is tending to introduce non-conventional changes to .gitignore
file. The .gitignore
file can be further changed by irresponsible person, by mistake, by a tool that is used, or in some other case.
To have a counter force to this, we can do as followed:
The initial .gitignore should reflect convention in team(s), After it is pushed, the .gitignore should be secured by adding .gitignore entry and push that change again.The .gitignore file is "sealed" in this way.
The "sealed" .gitignore
file can be changed, just locally, without propagating that changers to other members of team(s). However, if a change is widely agreed throughout the whole team(s) than it is possible to "unseal" it, change it and than "seal" it again. That can't be done by mistake, only intentionally.
Sadly, you cannot be 100% protected from the stupidity, but this way you have done everything you can to prevent stupid things to happen.
If you have relatively small team with very good professionals, than this wouldn't be important, but even those guys would appreciate to have one thing less to worry about.
Using .git/info/exclude
is cool when you cannot do anything about infrastructure settings, just covering your own a** not to make a mistake.
From a standing point of what is right and what is wrong I am voting for having .gitignore entry inside .gitignore
file, giving everybody the freedom to do locally whatever they want, but not invading others.
Success story sharing