From time to time, you may notice that these two commit views show different
information. That is, the history for a single file may omit commits found
on the repository's commit history.

In essence, Git has several different ways of showing the history of a repository.
When Git shows the history of a single file, it "simplifies" history by omitting
commits that did not change the file. But rather than look at every commit to
decide whether it touched the file, git will omit a whole branch if that branch,
when merged, did not impact the final contents of the file. Any commits on that
branch that touched the file will not be shown.

For a file's commit history, GitHub explicitly follows this simple strategy, for
two reasons:

It makes the history simpler by removing commits that did not actually
contribute to the final result ( e.g., if a side branch made a change and then
reverted it, or if a side branch contains a messy version of some changes that
were cherry-picked and cleaned up)

It's significantly more efficient to compute, as we can avoid looking at whole
side-branches of the history that did not impact the file

Of course, this truncated view might not always contain the information you're
after. Sometimes, you do want to know about failed experiments, or messy history,
or even be finding out what went wrong in a questionable merge. As mentioned above,
Git does have many ways of viewing history, and GitHub provides a view with more
information on a repository's commits page.

For more information on how Git considers commit history, you can
read up on the "History Simplification" section of the git loghelp article.