Undo a shared change without pretending it never happened

First, build a mental model

Revert adds a new commit that counteracts a selected change. Reset moves the current history reference and, depending on mode, also changes the index or working tree. They solve different recovery problems.

1. On shared history, a revert is often the appropriate starting point because it records the undo as new history rather than removing published commits.
2. reset --soft leaves index and working tree content; mixed reset also resets the index while keeping working files.
3. reset --hard resets index and tracked working content and can discard work. It can also remove untracked paths that obstruct writing tracked paths; do not treat it as harmless cleanup.
4. A revert can conflict with later changes. Verify the intended resulting behavior rather than assuming inversion is always automatic.
5. Reflogs can help locate prior local reference positions, but they are not a guarantee that every uncommitted or untracked file can be recovered.

# In a controlled recovery branch, inspect before changing history:
git status
git log --oneline -5
git show BUG_COMMIT
# After identifying the intended inverse change:
git revert BUG_COMMIT
# Resolve any conflict carefully and run the relevant regression checks.
# BUG_COMMIT is an educational placeholder for a reviewed real commit.

1. Published history

   A buggy commit and later useful commits are already shared.

2. Revert

   A new commit records the inverse change where it can be applied.

3. Verify

   The history remains reviewable, but later code dependencies may require a deliberate resolution and tests.