Recovering lost commits with reflog in Git - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of git reflog after a commit reset?

You ran git reset --hard HEAD~1 to undo the last commit. What will git reflog show as the latest entry?

Git

git reset --hard HEAD~1
git reflog

A HEAD@{0}: merge: moving to HEAD~1

B HEAD@{0}: commit: Undo last commit

C HEAD@{0}: checkout: moving to HEAD~1

D HEAD@{0}: reset: moving to HEAD~1

💡 Hint

Think about what git reset --hard does to the HEAD pointer.

After git reset --hard HEAD~1, the HEAD moves to the previous commit. The reflog records this as a reset action, so the latest entry is reset: moving to HEAD~1.

🧠 Conceptual

intermediate

Which command recovers a lost commit using reflog?

You accidentally lost a commit after a reset. Which command correctly restores the lost commit using reflog?

A git revert HEAD@{1}

B git checkout HEAD@{1}

C git reset --hard HEAD@{1}

D git merge HEAD@{1}

💡 Hint

You want to move HEAD back to the lost commit forcibly.

git reset --hard HEAD@{1} moves the HEAD pointer back to the previous state recorded in reflog, restoring the lost commit.

❓ Troubleshoot

advanced

Why does git reset HEAD@{2} fail to restore a lost commit?

You tried git reset HEAD@{2} to recover a lost commit but it did not work as expected. What is the most likely reason?

A HEAD@{2} is not a valid reflog entry

B It does not use the <code>--hard</code> flag, so working directory and index are not updated

C You need to use <code>git revert</code> instead of reset

D The reflog only tracks branches, not commits

💡 Hint

Consider what git reset does by default without flags.

By default, git reset without --hard only moves HEAD and updates the index but does not change the working directory. To fully restore a lost commit state, --hard is needed.

🔀 Workflow

advanced

Order the steps to recover a lost commit using reflog

Arrange the steps in the correct order to recover a lost commit using reflog.

A 1,2,3,4

B 2,1,3,4

C 3,1,2,4

D 1,3,2,4

💡 Hint

Think about finding the commit first, then restoring it, then verifying.

First, find the lost commit in reflog. Then reset hard to that commit. Next, verify with git log. Finally, check your files.

✅ Best Practice

expert

What is the safest way to recover a lost commit without risking current work?

You want to recover a lost commit using reflog but keep your current changes safe. Which approach is best?

A Create a new branch at the lost commit using 'git branch recover HEAD@{1}'

B Run 'git reset --hard HEAD@{1}' directly to restore the commit

C Use 'git checkout HEAD@{1}' to switch to the lost commit detached HEAD

D Run 'git revert HEAD@{1}' to undo changes

💡 Hint

Think about preserving your current work and avoiding forced resets.

Creating a new branch at the lost commit preserves your current work and allows you to inspect or merge changes safely without resetting your current branch.

Practice

1. What is the primary purpose of git reflog in Git?

easy

A. To show a log of where HEAD and branch references have been recently

B. To permanently delete commits from the repository

C. To merge two branches automatically

D. To push commits to a remote repository

Solution

1. Step 1: Understand what reflog tracks

   Git reflog records changes to HEAD and branch tips, showing recent commit movements.

2. Step 2: Identify reflog's main use

   It helps find lost commits by listing recent HEAD positions, not deleting or merging.

3. Final Answer:

   To show a log of where HEAD and branch references have been recently -> Option A

4. Quick Check:

   Reflog = recent HEAD changes [OK]

Hint: Reflog shows recent HEAD moves, not branch merges or deletions [OK]

Common Mistakes:

• Confusing reflog with git log
• Thinking reflog deletes commits
• Assuming reflog pushes commits

2. Which command correctly recovers a lost commit using its reflog hash abc1234 by creating a new branch named recovered?

easy

A. git branch recovered && git checkout abc1234

B. git reset --hard recovered abc1234

C. git reflog checkout abc1234 recovered

D. git checkout -b recovered abc1234

Solution

1. Step 1: Understand how to create a branch from a commit hash

   The command git checkout -b <branch> <commit> creates and switches to a new branch at that commit.

2. Step 2: Check each option's correctness

   git checkout -b recovered abc1234 uses correct syntax. git branch recovered && git checkout abc1234 creates branch but checks out commit separately (detached HEAD). git reflog checkout abc1234 recovered is invalid syntax. git reset --hard recovered abc1234 misuses reset.

3. Final Answer:

   git checkout -b recovered abc1234 -> Option D

4. Quick Check:

   Create branch from commit: checkout -b [OK]

Hint: Use 'git checkout -b branch commit' to recover lost commit [OK]

Common Mistakes:

• Using git reflog checkout (invalid command)
• Creating branch and checkout separately causing detached HEAD
• Misusing git reset syntax

3. Given the following reflog output snippet:

abc1234 HEAD@{0}: commit: Fix typo
def5678 HEAD@{1}: commit: Add feature
789abcd HEAD@{2}: commit: Initial commit

What command will restore the commit with message 'Add feature'?

medium

A. git checkout HEAD@{2}

B. git checkout 789abcd

C. git checkout def5678

D. git checkout abc1234

Solution

1. Step 1: Identify the commit hash for 'Add feature'

   From reflog, 'Add feature' commit hash is def5678 at HEAD@{1}.

2. Step 2: Use git checkout with the correct hash

   Checking out def5678 restores that commit state.

3. Final Answer:

   git checkout def5678 -> Option C

4. Quick Check:

   Checkout commit by hash = def5678 [OK]

Hint: Match commit message to hash, then checkout that hash [OK]

Common Mistakes:

• Choosing wrong commit hash
• Using HEAD@{2} which is 'Initial commit'
• Confusing latest commit with target commit

4. You ran git reflog and found a lost commit hash abc1234. You tried git checkout abc1234 but got a detached HEAD warning. How do you fix this to recover the commit safely?

medium

A. Create a new branch at that commit using git checkout -b recovered abc1234

B. Run git reset --hard abc1234 immediately

C. Delete the reflog entry and try again

D. Push the commit hash to remote

Solution

1. Step 1: Understand detached HEAD state

   Checking out a commit hash puts you in detached HEAD, which is risky for new work.

2. Step 2: Create a branch to save the commit safely

   Use git checkout -b recovered abc1234 to create a branch and avoid losing commits.

3. Final Answer:

   Create a new branch at that commit using git checkout -b recovered abc1234 -> Option A

4. Quick Check:

   Fix detached HEAD by creating branch [OK]

Hint: Always create a branch from lost commit to avoid detached HEAD [OK]

Common Mistakes:

• Ignoring detached HEAD and continuing work
• Deleting reflog entries mistakenly
• Trying to push without branch

5. You accidentally reset your branch to an older commit, losing recent commits. You run git reflog and see:

abc1234 HEAD@{0}: reset: moving to abc1234
def5678 HEAD@{1}: commit: Add new feature
789abcd HEAD@{2}: commit: Fix bug

How do you restore your branch to include the lost 'Add new feature' commit?

hard

A. Delete reflog entries before abc1234

B. Run git reset --hard def5678 to move branch back to lost commit

C. Run git checkout abc1234 to stay at reset point

D. Run git merge def5678 from abc1234

Solution

1. Step 1: Identify lost commit hash from reflog

   The lost commit 'Add new feature' is at def5678 (HEAD@{1}).

2. Step 2: Use git reset to move branch pointer back

   Running git reset --hard def5678 restores branch to that commit, recovering lost work.

3. Final Answer:

   Run git reset --hard def5678 to move branch back to lost commit -> Option B

4. Quick Check:

   Reset branch to lost commit hash [OK]

Hint: Use git reset --hard with reflog hash to recover lost commits [OK]

Common Mistakes:

• Checking out reset commit instead of resetting branch
• Deleting reflog entries unnecessarily
• Trying to merge without branch pointer