It is easier to understand the use of the git commands add and commit if you imagine a log file being maintained in your repository on Github.
A typical project's log file for me may look like:
---------------- Day 1 --------------------
Message: Completed Task A
Index of files changed: File1, File2
Message: Completed Task B
Index of files changed: File2, File3
-------------------------------------------
---------------- Day 2 --------------------
Message: Corrected typos
Index of files changed: File3, File1
-------------------------------------------
...
...
...and so on
I usually start my day with a git pull request and end it with a git push request. So everything inside a day's record corresponds to what occurs between them. During each day, there are one or more logical tasks that I complete which require changing a few files. The files edited during that task are listed in an index.
Each of these sub tasks(Task A and Task B here) are individual commits. The git add command adds files to the 'Index of Files Changed' list. This process is also called staging and in reality records changed files and the changes performed. The git commit command records/finalizes the changes and the corresponding index list along with a custom message which may be used for later reference.
Remember that you're still only changing the local copy of your repository and not the one on Github. After this, only when you do a git push do all these recorded changes, along with your index files for each commit, get logged on the main repository(on Github).
As an example, to obtain the second entry in that imaginary log file, I would have done:
git pull
# Make changes to File3 and File4
git add File3 File4
# Verify changes, run tests etc..
git commit -m 'Corrected typos'
git push
In a nutshell, git add and git commit lets you break down a change to the main repository into systematic logical sub-changes. As other answers and comments have pointed out, there are ofcourse many more uses to them. However, this is one of the most common usages and a driving principle behind Git being a multi-stage revision control system unlike other popular ones like Svn.