Do you ignore a git submodule in your .gitignore or commit it to your repo?

I've added a submodule to my project in project_dir/vendor/submodule_one now each time I run git status I get modified: vendor/submodule_one (new commits).

My question is whats the best way to deal with this? Do I add the vendor/submodule_one-folder to my .gitignore as my main project shouldn't need to know about the specifics of my submodule?

Or when I'm changing and commiting changes to my submodule do I need to make commits in my main project also?

Just getting started with submodules and couldn't seem to find much info beyond setting them up.

No, you don't need to add your submodule to your .gitignore: what the parent will see from your submodule is a gitlink (a special entry, mode 160000).

That means: any change directly made in a submodule needs to be followed by a commit in the parent directory.
That way, the parent directory will record the right commit for the state of the submodule: That commit is the "gitlink" mentioned above;

You can read more about that policy in "git submodule update (true nature of submodules)".
The main idea behind submodules is a component-based approach, where you reference other repos at specific commits. But if you change anything in those submodules, you need to update those references in the parent repo as well.

---

Note that with Git 2.13 (Q2 2017), while not ignoring the gitlink, you can still ignore the submodule with:

git config submodule.<name>.active false

See more at "Ignore new commits for git submodule".

---

Note: with Git 2.15.x/2.16 (Q1 2018), ignoring a submodule is more precise.
"git status --ignored --untracked" did not stop at a working tree of a separate project that is embedded in an ignored directory and listed files in that other project, instead of just showing the directory itself as ignored.

See commit fadb482 (25 Oct 2017) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit da7996a, 06 Nov 2017)}

> ## status: do not get confused by submodules in excluded directories

> We meticulously pass the exclude flag to the treat_directory() function so that we can indicate that files in it are excluded rather than untracked when recursing.

> But we did not yet treat submodules the same way.

> Because of that, git status --ignored --untracked with a submodule submodule in a gitignored tracked/ would show the submodule in the "Untracked files" section, e.g.

On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	tracked/submodule/

Ignored files:
  (use "git add -f <file>..." to include in what will be committed)

	tracked/submodule/initial.t

> Instead, we would want it to show the submodule in the "Ignored files" section:

On branch master
Ignored files:
  (use "git add -f <file>..." to include in what will be committed)

	tracked/submodule/

For some reason submodule.module-name.active didn't work for me.

That's why I used submodule.module-name.ignore

git config submodule.<your module path>.ignore all

https://git-scm.com/docs/gitmodules - here you can find description of possible values for parameter

Works for me for (new commits) and (modified content) messages.

To add onto the accepted answer, I have found that adding the Git submodule folder to .gitignore actually causes issues - particularly when trying to create a fresh clone of the project. Specifically, running the normal submodule clone commands resulted in the submodule folder being empty:

git submodule init
git submodule update
git pull --recurse-submodules

Only by trying to re-run

git submodule add <Git repo> <submodule folder>

it was clear what the issue was, based on the output:

The following path is ignored by one of your .gitignore files:
<submodule folder>
Use -f if you really want to add it.

Instead of adding -f, I removed the Git submodule folder from .gitignore and re-ran the submodule clone commands - which now successfully created the folder. I think that there may be a bug in that one of the submodule clone commands respects .gitignore but does not warn that it is skipping a submodule accordingly.