Git is a rather beefy tool, boasting up to 150 subcommands, with the exact figure varying depending on the git version. Using the method from the thread on my machine:
$ git help -a | grep "^ " | wc -l
144
The 144 subcommands currently, however skewed the above metric might be, is still impressive. But I cannot say I like git. Sure, I use it almost every single day, even for tasks that are probably better handled by another tool, but still, it's a giant.
Subcommands are not the whole picture
You read that right and if you used git for just a little bit, you are
probably aware of the fact, that basically all these subcommands have their
own arguments and here's where all the chaos begins. I am not going to name
them all, but you know I am talking about git add -A, git commit -a,
git commit -m, git branch -r or git branch -m to name just a few.
So what's up with reset? Git reset is another such subcommands, that offer
multiple arguments that are used really often. Specifically it is
git reset --hard, that I think about as a kind of time machine for
traveling back in time (in a commit history sort of time) and
git reset --soft that I found myself using usually after some bad amend.
Your mileage may vary.
Anyway, both these commands stem from their parent, the mighty git reset.
How come I never used this command without arguments before? It is such a
basic command, tied to the very core of the git itself. Well I finally
crossed this line too. I successfully used (and understood) git reset to
split previous commit into two separate ones! It really feels as ticking
just another box in the programmers lifelong TODO list.