Git

I initially found git a bit confusing because I was familiar with mercurial first, where a "branch" is basically an attribute of a commit and every commit exists on exactly one branch. It got easier when I eventually realized that git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space.

That other people would care as much for a clean history like I do. Specifically, opening branches and leaving them open forever without merging them back into main, many useless commits rather than squashing or amending, or making branches-of-branches-of-branches. Drives me nuts

I think a common misconception is that there's a "right way to do git" - for example: "we must use Gitflow, that's the way to do it".

There are no strict rules for how you should use git, it's just a tool, with some guidelines what would probably work best in certain scenarios. And it's fine diverge from those guidelines, add or remove some extra steps depending on what kinda project or team-structure you're working in.

If you're new to Git, you probably shouldn't just lookup Gitflow, structure your branches like that, and stick strictly to it. It's gonna be a bit of trial-and-error and altering the flow to create a setup that works best

That given its popularity it would be more user friendly. Every good dev tool will have its internals or more advanced features. Git is no different. But it sure feels like it never took the idea of a polished user experience seriously. Which is fine. It’s a dev tool after all. But the UI conversation around git has been going on long enough (here included) that there has to have been a significant global productivity cost due to the lack of a better UI.

Git's internals are very easy to understand and once you know more about them, you'll have a much better idea of how it works (especially when it comes to tags and branches). They're so simple, you could even easily write your own scripts to parse git's internal data directory if you wanted to.

I would highly recommend reading about them: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#

All I will need is push, pull, and commit.

I expected any operation involving origin/foobar to be an online operation and work against the latest server-side version of the branch.

I didn’t expect it to keep a local copy of the remote branch instead.

Coming from SVN and Mercurial where commits are increasing integers, I thought the SHA-1 stuff would be a PITA. It’s not and no one cares about numbers anymore.

That it’s just like subversion but distributed. Both of those assumptions are wrong. It uses a lot of the same terminology as subversion, but most of the terms are conceptually different in sometimes major ways. It’s not really distributed unless you go out of your way to make it so. Most implementations use a single remote to sync back to on a regular basis. It is, however, really good about keeping changes in sequence locally until it can sync, something you can’t really do in subversion.

I thought it would be hard to use and confusing all the time.

I don’t actually remember when I first learned Git. Maybe it was in a university lecture. I think my biggest struggles was learning how to resolve merge conflicts properly and efficient use of branching, but I never found any of the commands difficult to understand.