I like the in-progress `git checkout` split to `git switch` and `git restore`. (switch and restore are still marked "experimental" in the official documentation in case their arguments change again, but in my experience they are already pretty dependable.) It's much less likely to accidentally do the wrong thing with either of the two replacements. That's one of the things that I think if that split had been done years ago there would be a lot fewer complaints about git being confusing in the base commands; `git checkout` was always an odd duck sadly (it makes sense why it was a single command from a technical sense but it probably shouldn't have ever been from a UX/DX sense).

Although I understand all these commands and can use them, it's a typical Linux tool. Sure, if you understand the internals you can use the tools and the horrendous GUIs that are nothing more than a thin layer of paint.

But a truly user-centric tool would actually help you with something like

"I want to work on a new Feature A" "I want to continue working on Feature B" "I want my changes in the software/product" "I want to review a pull request (haha!) locally, in order to have IDE support." "I did an oopsie and need to go back."

Imagine navigating to a website by specifing its hash, or seeing changes to a PowerPoint file using "git status" and seeing "++slide1.pp". It would be terrible.

> you should also shy away from features if you do not really need them

>Learn those and you'll mostly good to go.

I wasn't really talking about "fancy" features of git, like rebasing history to try to make your history pretty or using things like git bisect. You need to develop basic understanding of git internals, even in the most basic workflow.

I would argue that your list of commands is not in any way complete for being "mostly good to go". At the minimum, you also need to know `git clone`, `git push`, `git pull`, `git fetch`, `git diff`, `git log`, `git blame`, and `git reset` as well. You need to save progress on your current feature branch to context switch to review some PR or analyze some production bug, well add `git stash` to the list. Your boss asked you to hotfix your recent commits onto the release branch? Better not forget `git cherry-pick`.

That brings us to 17 commands (up from the 7 you listed). Fine, it is still a finite number. Can you at least use them as a black box without bothering about the internals? NOPE. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches.

Besides, so many commands come with their own gotchas (git checkout will happily overwrite your local changes - without any warning). Some have bad defaults, so you need to figure out which of the hundreds of options that command supports to make it do what you actually want (e.g. git log --oneline and git diff -w -b). Still others have overloaded semantics and do two completely different things (git checkout switches branches but also restores files).

I find it interesting how many tutorials praise the simplicity of git while simultaneously assume nothing goes ever wrong. It's when you have to pull the main branch into the feature branch you're working on (because you sure don't want to do the big merge in a few weeks when you're done, not the least, because you don't even know whether you're still there to do it), but aren't ready to commit all changes made yet, when Murphy assures that there are conflicts. Then you have to do the stash/pop dance and since you manage to not fix all conflicts, the stash wasn't dropped, which you do manually and you just lost some changes. Then you wished you'd done a back-up before the pull ...

Sure, if you always commit your changes before pulling, then you won't need the stash and (even old CVS documentation reminded us that a VCS tool cannot replace communication) if there are no unrelated changes in the files you're working on, there won't be conflicts, but that just aren't realistic assumptions.