Most developers assume a Git commit has a single timestamp.
That's not true.
Every commit actually contains two different dates:
- Author Date
- Commit Date
Most of the time they are identical, which is why many developers never notice the distinction.
But once you start rebasing, cherry-picking, or rewriting history, the difference becomes important.
Understanding these two timestamps can explain some very confusing Git and GitHub behavior.
Every Commit Contains More Metadata Than You Think
Let's inspect a commit:
git show --pretty=fuller HEAD
Example output:
commit 7fd2f85...
Author: John Doe
AuthorDate: Mon Jul 1 10:00:00 2026 +0000
Commit: John Doe
CommitDate: Thu Jul 10 18:42:00 2026 +0000
Notice that Git stores two separate timestamps.
Why?
Because they represent different events.
What Is Author Date?
The Author Date represents when the change was originally created.
Imagine this workflow:
July 1 Create commit
July 5 Open pull request
July 10 Rebase branch
The code was written on July 1.
That's the Author Date.
It answers the question:
When was this work originally authored?
What Is Commit Date?
The Commit Date represents when the current commit object was created.
This is where many developers get surprised.
When Git rewrites history, it creates completely new commit objects.
For example:
git commit --amend
or
git rebase -i
Both operations generate new commits.
As a result, the Commit Date changes.
It answers the question:
When was this version of the commit created?
Why The Dates Become Different
Let's take a simple example.
You create a commit:
July 1
A week later you perform an interactive rebase:
July 8
Result:
AuthorDate = July 1
CommitDate = July 8
Nothing is wrong.
Git is preserving the original creation time while also recording when the rewritten commit object appeared.
Why GitHub Sometimes Looks Wrong
Many developers first encounter this distinction on GitHub.
You've probably seen something like:
Commit created: July 1
Displayed on GitHub: July 8
and wondered:
Why did GitHub change my commit date?
Usually GitHub isn't wrong.
It's simply displaying metadata that changed after a rebase, cherry-pick, or amend operation.
Understanding Author Date and Commit Date immediately explains this behavior.
Changing Commit Dates
Changing the latest commit date is relatively straightforward.
GIT_COMMITTER_DATE="$(date)" \
git commit --amend --no-edit --date "$(date)"
Changing older commits is significantly more annoying.
You typically need:
git rebase -i
followed by manual date editing and history rewriting.
This becomes painful when multiple commits are involved.
Why Commit Hashes Change
Another common surprise:
Changing only the timestamp changes the commit hash.
Many developers expect the hash to stay the same because the code didn't change.
But Git hashes the entire commit object, including metadata.
That means:
Same code
Same files
Same message
Different timestamp
results in:
Different commit hash
This is expected behavior.
When Would You Change Commit Dates?
There are legitimate reasons:
- Fixing incorrect system clocks
- Repository migrations
- Cleaning imported history
- Reconstructing chronological order
- Educational demonstrations
- Privacy reasons
In most cases you should avoid rewriting public history, but for personal branches and local repositories it can be useful.
Final Thoughts
Git stores two timestamps because they answer two different questions:
Author Date
When was this work originally created?
Commit Date
When was this commit object created?
Once you understand the distinction, many confusing Git and GitHub behaviors suddenly make sense.
While researching Git timestamps, I ended up building a small tool called GitEditDate that makes editing commit dates easier without manually wrestling with complex rebase commands.
Until then, I had no idea how much metadata was hiding inside a simple Git commit.
SOCIAL SHARE CARD GENERATOR