Git Reset and Reflog

Introduction

Welcome, Git time traveler! Today, we're going to explore two powerful Git features that will give you unprecedented control over your repository's history: git reset and git reflog. These tools are like the advanced controls of your Git time machine, allowing you to move between different states of your project and even recover "lost" work.

The git reset command is a versatile tool that can help you undo changes, unstage files, and even rewrite your commit history. However, with great power comes great responsibility, and git reset can be a bit daunting for newcomers. That's where git reflog comes in - it's like a safety net, keeping track of all the changes you make to your repository's refs (like branch tips), allowing you to recover from even the most drastic resets.

In this lab, we'll cover:

1. Soft Reset: Moving the HEAD without changing the working directory or staging area
2. Mixed Reset: Unstaging changes while keeping modifications in the working directory
3. Hard Reset: Discarding changes completely
4. Using Reflog to recover from "destructive" operations
5. Time-based Resets: Moving your repository to a state from a specific point in time

By the end of this lab, you'll have a solid understanding of how to use these powerful Git features safely and effectively. You'll be able to manipulate your repository's history with confidence, knowing that you can always find your way back if needed.

Let's dive in and start mastering git reset and reflog!

Skills Graph

Setting Up Your Workspace

Before we start resetting and reflogging, let's set up a workspace with some commits to experiment on. We'll create a new directory, initialize a Git repository, and add some files with multiple commits.

Open your terminal and type these commands:

cd ~/project
mkdir git-reset-lab
cd git-reset-lab
git init

Now, let's create some files and make a series of commits, copying and pasting the following commands into your terminal:

echo "## Git Reset and Reflog Lab" > README.md
git add README.md
git commit -m "Initial commit"

echo "function add(a, b) { return a + b; }" > math.js
git add math.js
git commit -m "Add addition function"

echo "function subtract(a, b) { return a - b; }" >> math.js
git add math.js
git commit -m "Add subtraction function"

echo "function multiply(a, b) { return a * b; }" >> math.js
git add math.js
git commit -m "Add multiplication function"

Let's break down what we just did:

1. We created a README file and made our initial commit.
2. We created a JavaScript file with an addition function and committed it.
3. We added a subtraction function to the same file and committed it.
4. Finally, we added a multiplication function and committed it.

Now we have a repository with some history to experiment on!

Soft Reset: Moving HEAD

The first type of reset we'll explore is the "soft" reset. A soft reset moves the HEAD (and the current branch) to a different commit, but it doesn't change the staging area or the working directory. This is useful when you want to "undo" some commits but keep all the changes for a new commit.

Let's try a soft reset:

git reset --soft HEAD~1

This command moves HEAD back one commit. The ~1 means "one commit before the current one". You can use ~2, ~3, etc., to go back multiple commits.

Now, if you run git status, you'll see that the changes from the last commit are staged and ready to be committed again. The files in your working directory haven't changed.

This is useful in scenarios where you want to "squash" your last few commits into one. You can soft reset back a few commits, and then make a new commit with all those changes.

Let's commit these changes again with a new message:

git commit -m "Add subtraction and multiplication functions"

Remember, while soft reset is generally safe (as it doesn't discard any changes), it does rewrite history. If you've already pushed the original commits, you'll need to force push to update the remote branch, which can cause problems for collaborators. Always communicate with your team before rewriting shared history!

Mixed Reset: Unstaging Changes

The next type of reset we'll look at is the "mixed" reset. This is actually the default mode for git reset if you don't specify a flag. A mixed reset moves the HEAD and updates the staging area to match, but it doesn't touch the working directory.

Let's make some changes and stage them:

echo "function divide(a, b) { return a / b; }" >> math.js
git add math.js

Now, let's say we've changed our mind and don't want to stage this change yet. We can use a mixed reset:

git reset HEAD

This unstages our changes but keeps them in the working directory. If you run git status now, you'll see that math.js is modified but not staged.

The mixed reset is useful when you've staged some changes but then decide you're not ready to commit them yet. Maybe you want to review the changes again or make further modifications before staging.

Remember, unlike soft reset, mixed reset does change the staging area. However, it's still safe in the sense that it doesn't discard any of your work - everything is still in your working directory.

Hard Reset: Discarding Changes

The third and most drastic type of reset is the "hard" reset. A hard reset moves the HEAD, updates the staging area, AND updates the working directory to match. This means it discards all changes since the commit you're resetting to.

Let's try a hard reset:

git add math.js
git commit -m "Add division function"
git status

git reset --hard HEAD~1

This stages and commits our division function, then performs a hard reset to the previous commit, effectively "undoing" our last commit and discarding the changes.

If you look at math.js now, you'll see that the division function is gone. It's as if we never wrote it.

Hard reset is powerful but dangerous. It's useful when you want to completely discard some work and start fresh from a previous commit. However, be very careful with it, as it can permanently discard changes.

Always double-check that you're resetting to the right commit before doing a hard reset. If you're unsure, it's safer to use a soft or mixed reset, or to create a new branch before experimenting.

Using Reflog to Recover Lost Commits

Now, what if you realize you didn't mean to discard that division function? This is where git reflog comes to the rescue. The reflog is a log of all the places HEAD has been in your local repository. It's like a super-history that even records history-rewriting commands like reset.

Let's look at the reflog:

git reflog

You should see a list of all the recent actions you've taken, including your resets. Each entry has a HEAD@{n} identifier.

To recover your lost commit, you can reset to the state before your hard reset:

git reset --hard HEAD@{1}

This resets to the state of HEAD before your last action (which was the hard reset).

Check math.js now, and you should see that your division function is back!

cat math.js

function add(a, b) { return a + b; }
function subtract(a, b) { return a - b; }
function multiply(a, b) { return a * b; }
function divide(a, b) { return a / b; }

The reflog is a powerful safety net, allowing you to recover from almost any Git accident. However, remember that it's local to your machine and temporary (entries are typically kept for 30 to 90 days). It's not a substitute for regular backups or for pushing your work to a remote repository.

Time-based Resets

Git also allows you to reset your repository to its state at a specific point in time. This can be useful if you remember approximately when your repository was in the state you want to return to.

Let's try a time-based reset:

git reset --hard master@{"1 hour ago"}

This resets your repository to its state from 1 hour ago. You can use various time descriptors like "yesterday", "2 days ago", "3 minutes ago", etc.

Be careful with time-based resets, as they can be less precise than resetting to a specific commit. Always check the state of your repository after a time-based reset to make sure you've arrived where you intended.

Remember, you can always use the reflog to undo a time-based reset if it doesn't give you the result you expected.

Summary

Congratulations, Git time lord! You've just mastered some of Git's most powerful and potentially dangerous commands. Let's recap the key concepts we've covered:

1. Soft Reset: Moves HEAD without changing the staging area or working directory. Useful for squashing commits.
2. Mixed Reset: Moves HEAD and updates the staging area, but doesn't touch the working directory. Great for unstaging changes.
3. Hard Reset: Moves HEAD, updates the staging area, and updates the working directory. Powerful but potentially destructive.
4. Reflog: A safety net that records all changes to HEAD, allowing you to recover from almost any Git accident.
5. Time-based Resets: Allow you to reset your repository to its state at a specific point in time.

Remember, with great power comes great responsibility. While these commands give you incredible control over your repository's history, they can also be dangerous if used carelessly. Always double-check before performing a reset, especially a hard reset, and remember that the reflog is your friend if things go wrong.

As you continue your Git journey, practice these commands in a safe environment until you're comfortable with them. They're powerful tools that can greatly enhance your Git workflow when used correctly.

Happy resetting, and may your Git history always be clean and meaningful!