Understanding Git Reset, Revert, and Checkout Operations Quiz

Explore the key differences and practical uses of the git reset, revert, and checkout commands. This quiz helps you identify the correct scenarios for each command, deepening your skills with version control workflow and error recovery techniques.

  1. Distinguishing Between Undo Methods

    Which git command should you use to safely undo a committed change in a shared branch while preserving project history?

    1. git revert
    2. git reset --hard
    3. git checkout file.txt
    4. git remove

    Explanation: git revert is the safest choice for undoing committed changes in a shared branch, as it creates a new commit that reverses the impact of the specified commit without rewriting the repository’s history. git reset --hard alters commit history and can cause issues for collaborators. git checkout file.txt only affects working directory files, not commits. git remove is not a valid git command, making it unrelated to this scenario.

  2. Effect on Commit History

    What happens to the commit history when you use git reset --hard HEAD~1 on your local branch?

    1. The most recent commit is erased from history
    2. A new commit is created to undo changes
    3. The branch is merged with another branch
    4. Nothing happens to your repository

    Explanation: git reset --hard HEAD~1 erases the most recent commit from the current branch’s history, and resets the working directory and staged files to match. In contrast, git revert would create a new commit to undo changes, not erase history. Merging branches or doing nothing are not results of git reset --hard. Only the correct option reflects git reset’s actual effect on the commit sequence.

  3. Restoring Files from a Previous Commit

    If you want to restore a single file, file.txt, from a previous commit without affecting the rest of your working directory, which command should you use?

    1. git checkout <commit_hash> -- file.txt
    2. git reset --soft <commit_hash>
    3. git revert HEAD
    4. git revert file.txt

    Explanation: Using git checkout <commit_hash> -- file.txt allows you to extract a specific version of file.txt from a past commit without changing any other files or the commit history. git reset --soft alters the branch pointer, affecting staging but not individual files. git revert HEAD creates a new commit reversing the latest changes, not just one file. git revert file.txt is not a valid command.

  4. Permanent Data Loss Risks

    Which git operation can permanently delete uncommitted changes from both the working directory and staging area without the possibility of recovery?

    1. git reset --hard
    2. git revert
    3. git fetch
    4. git commit --amend

    Explanation: git reset --hard removes all unstaged and staged changes by resetting the working directory and index to match the specified commit, leading to permanent loss of uncommitted work. git revert is used to undo committed changes by creating a new commit and does not affect uncommitted files. git fetch updates remote tracking branches but does not touch local changes. git commit --amend changes the last commit message or content but does not erase local changes.

  5. Scenario-Based Command Selection

    After committing the wrong file in a feature branch, which command allows you to move your branch pointer back and redo the commit as if it never happened (assuming no one else has pulled your branch yet)?

    1. git reset --soft HEAD~1
    2. git revert HEAD
    3. git add file.txt
    4. git push --force

    Explanation: git reset --soft HEAD~1 moves the branch pointer back one commit and returns the changes to the staging area, letting you recommit with corrections without affecting the working directory. git revert HEAD would create a new commit undoing the previous changes but would not erase the commit itself. git add file.txt only stages a file for commit and does not affect commit history. git push --force updates the remote branch but does not modify local commits—often this is used after git reset or rebase, but on its own, it doesn't correct mistakes.