A submodule is a standalone Git repo - what makes it a submodule is how it is referenced by the "super project", or rather, the Git repo that the submodule repo is sitting inside of.
When you make a change to a repo that is being utilized as a submodule, you'll be working as you normally do with a Git repo - you'll make your changes, add them, commit them, and push them. But after you make those changes in the submodule repo, you'll notice in the "super project" repo that there will be uncommitted changes, and those changes will reference the submodule repo.
So what has changed? Well, a "super project" repo keeps tabs on the submodule repo - its location, name, and (this is important) its current commit. Why the commit? Because it allows you to specify in the "super project" what is the proper commit to reference in the submodule. This has many advantages - picture using a third-party lib (as a submodule) that has recently been recently updated with backwards-breaking changes that you have not yet updated your project to accommodate for. By keeping the reference to an older commit, you can ensure that anyone who starts working on the project will be using the correctly-supported version of the submodule.
If you want to update the "super project" to reference the latest commit of the submodule, simply add, commit, and push as you would any other changed file.