627

Do you think it is a good practice to commit .gitignore into a Git repo?

Some people don't like it, but I think it is good as you can track the file's history. Isn't it?

Penny Liu
  • 15,447
  • 5
  • 79
  • 98
Howard
  • 19,215
  • 35
  • 112
  • 184

6 Answers6

606

Normally yes, .gitignore is useful for everyone who wants to work with the repository. On occasion you'll want to ignore more private things (maybe you often create LOG or something. In those cases you probably don't want to force that on anyone else.

Bruce Stephens
  • 7,225
  • 1
  • 17
  • 7
  • 162
    +1 The "private things" can be mentioned in the `$GIT_DIR/info/exclude` or `~/.gitconfig` files as appropriate. – WReach Apr 23 '11 at 17:16
  • 14
    If you already have a file checked in, and you want to ignore it, Git will not ignore the file if you add a rule later. In those cases, you must untrack the file first, by running the following command in your terminal: `git rm --cached FILENAME` – eli-bd Apr 11 '18 at 01:28
167

You typically do commit .gitignore. In fact, I personally go as far as making sure my index is always clean when I'm not working on something. (git status should show nothing.)

There are cases where you want to ignore stuff that really isn't project specific. For example, your text editor may create automatic *~ backup files, or another example would be the .DS_Store files created by OS X.

I'd say, if others are complaining about those rules cluttering up your .gitignore, leave them out and instead put them in a global excludes file.

By default this file resides in $XDG_CONFIG_HOME/git/ignore (defaults to ~/.config/git/ignore), but this location can be changed by setting the core.excludesfile option. For example:

git config --global core.excludesfile ~/.gitignore

Simply create and edit the global excludesfile to your heart's content; it'll apply to every git repository you work on on that machine.

Remco Haszing
  • 7,178
  • 4
  • 40
  • 83
Stéphan Kochen
  • 19,513
  • 9
  • 61
  • 50
  • 17
    You can always add `# some comment` lines to the `.gitignore` file to explain _why_ you are ignoring something. Commenting every line is a bit of overkill, but I have have sections labeled `# IDE (Eclipse)`, `# OS (Mac OS X)`, and `# Generated (Perl)`. That way if someone wants to use a different OS or IDE they can add a section and we can all share. – Stuart R. Jefferys Aug 29 '12 at 22:07
  • 14
    thumbs up for "I personally go as far as making sure my index is always clean when I'm not working on something. (git status should show nothing.)" – SGhosh Jul 10 '13 at 17:45
  • 4
    Nb. with modern Git the default value for `core.excludesfile` is `~/.config/git/ignore`, conforming to XDG Base Directory Specification – Jakub Narębski Aug 26 '14 at 18:12
  • 1
    +1 for global `.gitignore` - Hugely beneficial when people you work with disagree about the contents of pushed `.gitignore` files or whether they should be pushed, and we all use ton of different dev environments that generate different types of noise. – Krease Apr 07 '17 at 21:40
  • 1
    https://davidwalsh.name/global-gitignore some more information about the global ignore – Frode Akselsen May 25 '17 at 23:51
13

I put commit .gitignore, which is a courtesy to other who may build my project that the following files are derived and should be ignored.

I usually do a hybrid. I like to make makefile generate the .gitignore file since the makefile will know all the files associated with the project -derived or otherwise. Then have a top level project .gitignore that you check in, which would ignore the generated .gitignore files created by the makefile for the various sub directories.

So in my project, I might have a bin sub directory with all the built executables. Then, I'll have my makefile generate a .gitignore for that bin directory. And in the top directory .gitignore that lists bin/.gitignore. The top one is the one I check in.

Bitdiot
  • 1,506
  • 2
  • 16
  • 30
2

Committing .gitignore can be very useful but you want to make sure you don't modify it too much thereafter especially if you regularly switch between branches. If you do you might get cases where files are ignored in a branch and not in the other, forcing you to go manually delete or rename files in your work directory because a checkout failed as it would overwrite a non-tracked file.

Therefore yes, do commit your .gitignore, but not before you are reasonably sure it won't change that much thereafter.

Patrick Perdu
  • 21
  • 3
  • 1
    That is an unreasonable expectation. I am never sure that it will not change much in the future because I have no way of knowing the future. Actually unless a project is dead things are bound to be added and removed a lot because such is the nature of development. – gargoylebident May 21 '21 at 14:44
  • The key words are "that much". – Patrick Perdu Sep 28 '21 at 16:01
  • "That much" is a useless measure because it means a different thing to everyone. – gargoylebident Sep 28 '21 at 17:47
1

For me I think it is a good idea to commit .gitignore file to the repository. When someone clones your repository and build project, or run some tests that does generate some junk data may not needed to push it.. .gitignore file just ignore files that are configured in it..

Uday
  • 149
  • 6
-9

It is a good practice to .gitignore at least your build products (programs, *.o, etc.).

Jakub Narębski
  • 309,089
  • 65
  • 217
  • 230
  • 12
    That didn't answer the question: should `.gitignore` _itself_ be "`.gitignore`'d"? – Charles Wood Jul 31 '13 at 19:00
  • 6
    Pay attention, _that_ wasn't the question, and this **does** answer what was asked: "is [it] a good practice to commit .gitignore into a Git repo?". – papercowboy Aug 03 '13 at 10:22
  • 7
    @cayuu i believe the answer says "it is a good practice to .gitignore" xyz, I don't see how it answers the question. the question is if .gitignore should be version controlled or not. – nightograph Mar 09 '15 at 22:07