Explore core concepts and commands for safely undoing mistakes in git, including how to reset, revert, and recover lost changes. This quiz is designed to help you understand effective, secure ways to fix errors in your version control workflow.
Suppose you just committed some changes but realize you need to edit them before sharing. Which git command allows you to undo the last commit while keeping your changes staged?
Explanation: The correct answer is git reset --soft HEAD~1, which undoes the last commit but keeps your changes in the staging area, letting you modify them easily. git revert HEAD creates a new commit to undo the changes but does not let you edit them directly. git rm --cached HEAD is not valid and would not affect your commit history. git checkout --amend HEAD is not a correct command; --amend is used with commit, not checkout.
If you have pushed an incorrect commit to a shared branch, what is the safest way to undo its effect without rewriting history?
Explanation: Using git revert <commit> is safest for shared branches because it creates a new commit that undoes the changes, preserving the project history and avoiding conflicts for others. git reset --hard <commit> rewrites history, which is unsafe if others have fetched the branch. git cherry-pick applies changes from another commit and does not undo mistakes. git squash is not a git command; the correct action is called 'squash' in some contexts but not as a standalone command.
After accidentally deleting an uncommitted file you were editing, which git command can help you restore the latest committed version of that file?
Explanation: git checkout -- <filename> recovers the file back to the state of the last commit, which is useful when you have deleted or changed it before committing. git reset HEAD~1 <filename> is incorrect, as reset with a file acts differently and HEAD~1 refers to a previous commit globally. git fetch retrieves changes from a remote repository and doesn't restore files. git branch <filename> is not a valid operation for restoring files.
Imagine you start a merge and encounter many conflicts, so you decide not to merge after all. Which git command will safely abort the merge process and return you to your pre-merge state?
Explanation: git merge --abort safely stops the merge process and restores your working directory to how it was before the merge started. git revert --merge is not a standard option and does not abort merges. git reject --abort and git discard merge are not recognized git commands. Only git merge --abort provides the intended recovery.
If you accidentally delete a branch and lose its unmerged commits, how can you find the reference to these lost commits using the git ecosystem?
Explanation: git reflog maintains a record of movements to HEAD and branch tips, allowing you to find references to lost commits and recover them even after branch deletion. git status shows the working tree and staged changes but does not list unreachable commits. git merge-base is used to find common ancestors for merging. git prune permanently deletes unreachable objects and does not help with recovery.