Все твои кейсы делает, очевидно, `git reset`

git reset --hard HEAD~1

Опция --hard восстанавливает состояние ветки и дерева на указанный коммит, в частности ** удалит все локальные изменения ** в индексе. Здесь нужно понимать как git адресует относительные коммиты, HEAD - текущий, HEAD~N - N коммитов назад. Если нужно удалить файл из коммита с другими изменениями, то

git reset --soft HEAD~1

Отказывает состояние ветки на указанный коммит, а отброшенные изменения из ветки загружает в текущий stage не трогая дерево. Далее его можно редактировать как обычный stage. В частности, чтобы вынуть файл из stage, т.е. твой кейс 2, опять помогает reset

git reset path/to/my/file

Если туго с памятью и вообще с головой, то можно сделать алиасы с различаемыми для тебя лично именами. Какая бы у тебя не была VCS, всё равно нужно знать как она адресует коммиты и что запускать. Не работаешь с Git 2012 года, а работаешь с каким-то другим инструментом совсем иногда что-то делая c Git. В таком случае всегда приходится подгружать кеш, для любого минорного инструмента, чтобы вспомнить с чего начать. Хорошо если инструмент сам умеет давать подсказку, например, если запустить его без аргументов. Git и svn показывают какие команды у них есть и если этого мало, то нет ничего страшного в своей шпаргалке. Справка Git не везде хороша, но не настолько чтобы устраивать на этот счёт истерики и делать этот фактор решающим в выборе VCS.

Не нужно возводить личные проблемы до объективных технических, истеричкам нет места в инженерии.

UPD: Прочитал выше как в своём варианте предоагаешь адресовать коммиты, т.е. [N], это ничем не лучше и никак не понятнее по сравнению с адресацией в Git.

UPD: Если нужно squash-нуть последние N коммитов и посмотреть что получилось перед коммитом, то кроме rebase тоже можно воспользоваться второй формой reset-a, т.е.

git reset --soft HEAD~N