.gitignore not ignore tfvars and .terraform directory

Question

It appears that my .gitignore is not correct as expected.

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   .gitignore
        new file:   win_2016_datacentre_vm/.terraform/plugins/linux_amd64/lock.json
        new file:   win_2016_datacentre_vm/.terraform/plugins/linux_amd64/terraform-provider-azurerm_v1.16.0_x4
        new file:   win_2016_datacentre_vm/aos-1.tfvars
        new file:   win_2016_datacentre_vm/aos-1.v1/.terraform/plugins/linux_amd64/lock.json
        new file:   win_2016_datacentre_vm/aos-1.v1/.terraform/plugins/linux_amd64/terraform-provider-azurerm_v1.16.0_x4
        new file:   win_2016_datacentre_vm/aos-1.v1/aos-1.plan
        new file:   win_2016_datacentre_vm/aos-1.v1/aos-1.tf
        new file:   win_2016_datacentre_vm/aos-1.v1/aos-1.tfvars
        new file:   win_2016_datacentre_vm/aos-1.v1/terraform.tfstate
        new file:   win_2016_datacentre_vm/aos-1.v1/terraform.tfstate.backup


Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   .gitignore

$ cat .gitignore
# Local terraform directories
docker/*
terraform-getting-started/*
terraform-getting-started.zip
**/.terraform/**
*/**/.tfvars
*.tfstate

What makes me wonder is even though I have added .terraform, *.tfvars and *.tfstate why is reporting them in git status?

Also should I be committing tfstate to repository?

Your assistance will be much appreciated.

Thank you

Answer 1

To expand zerkms's comment a bit, this line:

Changes to be committed:

tells you (and us) that you've already told Git: please include these files.

The file name .gitignore is rather misleading. It seems like it's a list of files, or patterns for file names, that Git shouldn't include, but it's not: instead, it's a list of file names that Git shouldn't add automatically if they're not already there (but they are already there), and shouldn't suggest that you should add.

Longer, but good to know

Git's model for this is that Git builds new commits from what Git calls, variously, the index, or the staging area, or the cache, depending on who / which part of Git is doing the calling. The best short description of the index that I know if is that it's where Git builds the next commit to make (or in this case, the first commit to make).

When you first check out some existing commit—which you can't yet, as there aren't any, but some time in the future when you use git checkout or git clone runs git checkout for you—Git will fill in the index from that commit, and then use the index's contents, as extracted from the commit, to fill in the work-tree as well. Now the index copy and the work-tree copy both match, and both of them match the file taken out of the commit.

When you have a work-tree full of files and have changed some of them, you run git add to re-copy the existing work-tree files back into the index, to make them ready for the next commit. Now the index copy and the work-tree copy match again, and both are different from the file still in the commit. (Or, if the file is all-new, it's now in the index when it was not before.)

When you make a new commit, Git freezes the copies that are in the index, and puts those into the commit. Whatever was in the index is now in the new commit, which is now the current commit. So now the index matches the commit, as if you'd just checked out that commit. If you had all the index files matching all the work-tree files, all three copies of every file all match, just like when you first checked out a commit.

To remove a file from the index, use git rm: this will remove it from both the index and the work-tree. To remove it only from the index, keeping it in the work-tree, use git rm --cached instead. Be careful: if the file is in some existing commit(s), and you remove it from the index, it won't be in the new commit you make, but it will still be the existing commits. Checking one of those out will—or at least can—overwrite the work-tree file you left behind on purpose with git rm --cached.