What's the difference between git reflog and log?

Question 1

git log shows the current HEAD and its ancestry. That is, it prints the commit HEAD points to, then its parent, its parent, and so on. It traverses back through the repo's ancestry, by recursively looking up each commit's parent.

(In practice, some commits have more than one parent. To see a more representative log, use a command like git log --oneline --graph --decorate.)

git reflog doesn't traverse HEAD's ancestry at all. The reflog is an ordered list of the commits that HEAD has pointed to: it's undo history for your repo. The reflog isn't part of the repo itself (it's stored separately to the commits themselves) and isn't included in pushes, fetches or clones; it's purely local.

Aside: understanding the reflog means you can't really lose data from your repo once it's been committed. If you accidentally reset to an older commit, or rebase wrongly, or any other operation that visually "removes" commits, you can use the reflog to see where you were before and git reset --hard back to that ref to restore your previous state. Remember, refs imply not just the commit but the entire history behind it.

Question 2

git log shows the commit log accessible from the refs (heads, tags, remotes)
git reflog is a record of all commits that are or were referenced in your repo at any time.

That is why git reflog (a local recording which is pruned after 90 days by default) is used when you do a "destructive" operation (like deleting a branch), in order to get back the SHA1 that was referenced by that branch.
See git config:

gc.reflogexpire
gc.<pattern>.reflogexpire

git reflog expire removes reflog entries older than this time; defaults to 90 days.
With "<pattern>" (e.g. "refs/stash") in the middle the setting applies only to the refs that match the <pattern>.

safety net

git reflog is often reference as "your safety net"

In case of trouble, the general advice, when git log doesn't show you what you are looking for, is:

"Keep calm and use git reflog"

keep calm

Again, reflog is a local recording of your SHA1.
As opposed to git log: if you push your repo to an upstream repo, you will see the same git log, but not necessarily the same git reflog.

Question 3

Here's the explanation of reflog from the Pro Git book:

One of the things Git does in the background while you’re working away is keep a reflog — a log of where your HEAD and branch references have been for the last few months.

You can see your reflog by using git reflog:
$ git reflog
734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
1c002dd... HEAD@{2}: commit: added some blame and merge stuff
1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
95df984... HEAD@{4}: commit: # This is a combination of two commits.
1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
Every time your branch tip is updated for any reason, Git stores that information for you in this temporary history. And you can specify older commits with this data, as well.

The reflog command can also be used to delete entries or expire entries from the reflog that are too old. From the official Linux Kernel Git documentation for reflog:

The subcommand expire is used to prune older reflog entries.

To delete single entries from the reflog, use the subcommand delete and specify the exact entry (e.g. git reflog delete master@{2}).

Question 4

I was curious about this as well and just want to elaborate and summarize a bit:

git log shows a history of all your commits for the branch you're on. Checkout a different branch and you'll see a different commit history. If you want to see you commit history for all branches, type git log --all.
git reflog shows a record of your references as Cupcake said. There is an entry each time a commit or a checkout it done. Try switching back and forth between two branches a few times using git checkout and run git reflog after each checkout. You'll see the top entry being updated each time as a "checkout" entry. You do not see these types of entries in git log.

References: http://www.lornajane.net/posts/2014/git-log-all-branches

Question 5

I like to think of the difference between git log and reflog as being the difference between a private record and a public record.

Private vs public

With the git reflog, it keeps track of everything you've done locally. Did you commit? Reflog tracks it. Did you do a hard reset? Reflog tracks it. Did you amend a commit? Reflog tracks it. Everything you've done locally, there's an entry for it in the reflog.

This isn't true for the log. If you amend a commit, the log only shows the new commit. If you do a reset and skip back a few commits in your history, those commits you skipped over won't show up in the log. When you push your changes to another developer or to GitHub or something like that, only the content tracked in the log will appear. To another developer, it will look like the resets never happened or the amends never happened.

The log is polished. The reflog is lapidary.

So yeah, I like the 'private vs public' analogy. Or maybe a better log vs reflog analogy is 'polished vs lapidary.' The reflog shows all your trials and errors. The log just shows a clean and polished version of your work history.

Take a look at this image to emphasize the point. A number of amends and resets have occurred since the repository was initialized. The reflog shows all of it. Yet the log command makes it look as though there has only ever been one commit against the repo:

Back to the 'safety net' idea

Also, since the reflog keeps track of things you amended and commits you reset, it allows you to go back and find those commits because it'll give you the commit ids. Assuming your repository hasn't been purged of old commits, that allows you to resurrect items no longer visible in the log. That's how the reflog sometimes ends up saving someone's skin when they need to get back something they thought they inadvertently lost.

Question 6

git log will start from current HEAD, that is point to some branch (like master) or directly to commit object (sha code), and will actually scan the object files inside .git/objects directory commit after commit using the parent field that exist inside each commit object.

Experiment: point the HEAD directly to some commit: git checkout a721d (create new repo and populate it with commits and branches. replace a721d with some of your commit code) and delete the branches rm .git/refs/heads/* Now git log --oneline will show only HEAD and its commits ancestors.

git reflog on the other hand is using direct log that is created inside .git/logs

Experiment: rm -rf .git/logs and git reflog is empty.

Anyway, even if you lose all tags and all branches and all logs inside logs folder, the commits objects are inside .git/objects directory so you can reconstruct the tree if you find all dangling commits: git fsck

Question 7

Actually, reflog is an alias for

 git log -g --abbrev-commit --pretty=oneline

so the answer should be: it is a specific case.