Difference between reset and revert in Git - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding git reset vs git revert

Which statement correctly describes the difference between git reset and git revert?

A <code>git reset</code> creates a new commit that undoes changes, while <code>git revert</code> deletes commits permanently from the history.

B <code>git reset</code> changes the commit history by moving the HEAD pointer, while <code>git revert</code> creates a new commit that undoes changes without altering history.

C <code>git reset</code> only works on remote branches, while <code>git revert</code> only works on local branches.

D <code>git reset</code> merges two branches, while <code>git revert</code> rebases commits onto another branch.

💡 Hint

Think about whether the command changes history or adds a new commit.

git reset moves the HEAD pointer and can change commit history, which can be dangerous if pushed. git revert safely undoes changes by adding a new commit, preserving history.

💻 Command Output

intermediate

Output of git revert command

What is the output of running git revert HEAD in a repository?

Git

git revert HEAD

A Deletes the last commit permanently and moves HEAD to the previous commit.

B Resets the working directory to the state of the last commit without creating a new commit.

C Shows an error because <code>git revert</code> requires a commit hash, not HEAD.

D Creates a new commit that reverses the changes of the last commit and opens an editor for the commit message.

💡 Hint

Consider what git revert does to the commit history.

git revert HEAD creates a new commit that undoes the changes introduced by the last commit. It does not delete commits.

💻 Command Output

advanced

Effect of git reset --hard on working directory

What happens to your working directory and commit history after running git reset --hard HEAD~2?

Git

git reset --hard HEAD~2

A Shows an error because <code>--hard</code> cannot be used with relative commit references.

B Creates two new commits that undo the last two commits but keeps the working directory unchanged.

C Moves HEAD back two commits and resets the working directory and staging area to match that commit, discarding all changes after it.

D Only moves HEAD back two commits but keeps the working directory and staging area as they were.

💡 Hint

Think about what --hard does to files and commits.

git reset --hard HEAD~2 moves HEAD back two commits and resets the working directory and staging area to match that commit, discarding all changes after it.

🔀 Workflow

advanced

Choosing between reset and revert in a shared repository

You accidentally committed some incorrect changes and pushed them to a shared remote repository. Which approach is safer to undo those changes without disrupting other collaborators?

A Use <code>git revert</code> to create a new commit that undoes the changes, preserving history.

B Use <code>git reset --hard</code> locally and force push to overwrite the remote history.

C Delete the repository and create a new one without those changes.

D Use <code>git reset --soft</code> to undo the commit and push normally.

💡 Hint

Consider the impact on collaborators and history rewriting.

git revert safely undoes changes by adding a new commit, avoiding history rewrite that can confuse collaborators. git reset --hard with force push rewrites history and can cause problems.

❓ Troubleshoot

expert

Troubleshooting unexpected file changes after git reset

After running git reset --mixed HEAD~1, you notice some files in your working directory have unexpected changes. Why does this happen?

A <code>--mixed</code> resets the staging area but leaves the working directory unchanged, so changes remain in files.

B <code>--mixed</code> resets both staging area and working directory, so files should be clean.

C <code>git reset --mixed</code> deletes untracked files causing unexpected changes.

D <code>--mixed</code> only affects remote branches, not local files.

💡 Hint

Recall the difference between --soft, --mixed, and --hard options.

--mixed resets the staging area to the specified commit but does not change the working directory. So, file changes remain visible but unstaged.