Time travel
Marie-Hélène Burle
training@westgrid.ca
Time travel
Time travel
Looking at the past without travelling
git log
→ Overview of project history
git show
→ Information about Git objects such as commits
Travelling through history
→ Move the HEAD pointer
Working directory & index get updated to match the snapshot pointed at
→ Your project is back at the state in which it was when you made that commit
Before:
Travelling through history
→ Move the HEAD pointer
Working directory & index get updated to match the snapshot pointed at
→ Your project is back at the state in which it was when you made that commit
After:
Moving HEAD
Identify the commit we want to move to
With git log
With the ~ notation:
HEAD~ or HEAD~1 is the main parent of the commit HEAD is pointing to
HEAD~2 is the main parent before that
HEAD~3 refers to the 3rd commit before the current commit
etc.
Moving HEAD
You move HEAD with git checkout:
git checkout <commit-hash>This is great to look around, then go back to the “present” with:
git checkout mainMoving HEAD
Starting point:
Now, we move HEAD to the commit 31fukv1:
git checkout 31fukv1Detached HEAD
HEAD is not pointing at a branch anymore: it is pointing directly at a commit → detached HEAD state
Your files are back at their state when you created commit 31fukv1
Detached HEAD
You can look at your project at that point in its history, then go back to the “present” with:
git checkout mainAnd that’s that.
Creating commits from a detached HEAD
Now, when you are at commit 31fukv1, maybe you want to try something
But when you come back to “the present”, those experiments will get lost
So what if you want to keep those changes?
Here is what happens if you make a commit:
Creating commits from a detached HEAD
You can make more commits:
The thing is that you are still in this detached HEAD state. HEAD is not pointing to a branch as it normally is.
Is this a problem?
Bad workflow
It becomes a problem if you checkout main from there:
If you don’t care about those commits, all is good.
But if you want to keep them, this is a bad situation because those commits are now left behind: they are not in the history of any branch or tag.
Bad workflow
This is bad for three reasons:
Those commits will not show when you run
git log, so it is easy to forget about themIt is not easy to go back to them because there aren’t any tag or branch that you can switch to
The garbage collection (which runs every 30 days by default) will delete commits which are not on any branch or tag. So you will ultimately loose them
Good workflow
Here is a proper workflow if you have created commits from a detached HEAD state
Good workflow
First, create a new branch:
Good workflow
Only then can you safely checkout main:
The commits 23f481q and rthy7wg are now on a branch. They are part of the project history, they will not get deleted. All is good.
Recovering commits left behind
What if you left commits behind (not on a branch)?
You can retrieve their hash by running:
git reflogThis tracks the position of HEAD over time
You can then checkout the commit you care about (so you are going back to a detached HEAD state):
git checkout <hash-abandonned-commit>This puts you back into a situation where you can rescue the commit(s) by creating a branch
Do this as soon as possible