What were your misconceptions about Git when you first started?

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.

git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space

Yeah, once you realize that everything falls into place.
- Permanently Deleted
It got easier when I eventually realized that git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space.

Wow, thanks. I finally understand!
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.

To be fair, Mercurial has some poor design choices which leads to a very different mental model of how things are expected to operate in Git. For starters, basic features such as stashing local changes were an afterthought that you had to install a plugin to serve as a stopgap solution.

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

Omg so this. Also merging main branches into feature branches instead of rebasing.
- What is the advantage of rebasing?
In many providers it’s possible to set up an automatic squash policy when merging to main. At our company the git history is just linear with well defined commits.
- I don't think this is necessarily better. Some branches/projects are big enough that there are meaningful commits that should be made inside the project.
I'm glad I was able to establish a very mindful and structured approach to Git history in my team and project.

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

git add . git commit -a git push
- At that point you might as well add an alias that does all these three things.
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”.

I don't think this is a valid take. Conventions or standardizations are adopted voluntarily by each team, and they are certainly not a trait of a tool. Complaining about gitflow as if it's a trait of Git is like complaining that Java is hard because you need to use camelCase.

Also, there is nothing particularly complex or hard with gitflow. You branch out, and you merge.
- Well to be clear, this was not supposed to be a jab at gitflow, or me complaining specifically about gitflow. I merely used "gitflow" as an example of a set of conventions and standardizations that comes nicely packaged as one big set of conventions.
  
  But there's nothing wrong with gitflow. I was just saying - it are not set in stone rules you must follow religiously. If you're using it and it seems more practical to adapt the flow for your own use-case, don't worry it'd be considered wrong to not stick strictly to it

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.

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.

I don't think this is true.

Git is ugly and functional.

People love to complain about it being ugly, but it does what it's meant to. If there was actually a persistent productivity hit from its interface, one of the weird wrappers would have taken off, and replaced it.

But the truth is, those wrappers all seem to be written by people learning to use git in the first place, and just get abandoned once they get used to it.
- Git is ugly and functional.
  
  I don't even think it's ugly. It just works and is intuitive if you bother to understand what you're doing.
  
  I think some vocal critics are just expressing frustration they don't "get" a tool they never bothered to learn, particularly when it implements concepts they are completely unfamiliar with. At the first "why" they come across, they start to blame the tool.
- If there was actually a persistent productivity hit from its interface, one of the weird wrappers would have taken off, and replaced it.
  
  How many use a GUI or text editor plugin (eg magit) for git? AFAICT, such things, as a category, are rather popular.
there has to have been a significant global productivity cost due to the lack of a better UI.

I'm not so sure about this to be honest. If it were really that big of a problem, someone would have made an effort to resolve it. The fact that people still use it anyway suggests to me that it's a bit of an overblown issue.
- If it were really that big of a problem, someone would have made an effort to resolve it. The fact that people still use it anyway suggests to me that it’s a bit of an overblown issue.
  
  As I said in another reply ... how many GUIs and text editor plugins are there for git and how many use them?
  
  What other CLI tool has as much work put into GUIs, wrappers and plugins that do not try to replace the underlying tool/CLI, even accounting for popularity?
Probably important to remember that Git was designed by Linus Torvalds, the same dude who developed the Linux kernel, and who is infamous for going off on big rage-fueled rants when questioned about his methods. So yeah, it’s going to be clunky and obtuse.
- Ha yea ... who's also been using his own customised emacs from an ancient 90s version for ages.
Git is no different. But it sure feels like it never took the idea of a polished user experience seriously.

I've seen this sort of opinion surface often,but it never comes with specific examples. This takes away from the credibility of any of these claims.

Can you provide a single example that you feel illustrates the roughest aspect of Git's user experience?
- Yeah sure. git push says "did you mean git push -u branchname origin". Yes obviously I meant that. I always mean that.
  
  I'd been copying and pasting that for about 5 years before I discovered there's a feature (auto branch setup or something) which means it will automatically do that. But it's not mentioned in the error message! Why?
  
  Git has a load of --fixed-behaviour flags like that that are just not on by default and never mentioned.
  
  The terminology is very poorly chosen in a lot of cases. "The index"? Wtf is that? "Staging area" is at least slightly better but would "draft commit" have been too much to ask? Ours/theirs is also a stonkingly bad choice of words. How does Git know which code is mine? It doesn't. Hell it isn't even consistent about which way around they are.
  
  Someone has force pushed a branch and I want to update my local ref (without typing the whole branch name again). git pull gives a wall of text without the answer, which is.... git reset --hard @{u}. Catchy!
  
  Or maybe I've got a branch that is tracking my fork but I want to pull from upstream. Can I do git pull upstream? Nope. I have to repeat the branch name git pull upstream branch-i-am-on. (Please don't say "but git doesn't know which branch you want to pull.)
  
  Then there's the error messages... Make a branch called foo/bar. Now try to check out a remote branch foo. See that nice explanation about how git branches are actually files and directories, not just strings? Nope? Huh.
  
  This is just a few I can remember off the top of my head but it's the tip of the iceberg.
- I mean sure. I personally haven't researched and become an expert on this ... it is an early-user's misconceptions thread after all. And a dev can justifiably reflect on all of their tooling and consider their general usability against their popularity.
  
  However, by the same token, your lack of any counter examples isn't exactly highly credible either.
  
  Nonetheless:
  
  Whenever I've seen an opinion from someone who's used both mercurial and git, their opinion is always that the mercurial interface and model "actually makes sense"
  
  AFAICT, the git CLI (at least up until the more recent changes) has widely been recognised as being unnecessarily janky and confusing especially for common and basic tasks
  
  Apart from that, many devs have shared that they always struggle to remember git commands and always need to rely on some reference/cheat-sheet (obligatory XKCD), which IMO is a product of it both having a poor CLI in need of polish and being a program/tool that isn't naturally constrained to CLI usage but rather naturally implemented with a graphical of some sort.

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

Sure if you never branch, which is a severely limited way of using git.
- Network engineer doing netdevops. branches don't work like software, always commit to main.
- Sure if you never branch, which is a severely limited way of using git.
  
  It's quite possible to use Git without creating branches. Services like GitHub can automatically create feature branches for you as part of their ticket-management workflow. With those tools, you start to work on a ticket, you fetch the repo, and a fancy branch is already there for you to use.
  
  You also don't merge branches because that happens when you click on a button on a PR.

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#

They're not that simple because of packfiles. But yeah loose files are very simple. Also the documentation for packfiles is pretty bad. You end up reading other people's random notes and the Git source code. (I actually have written a Git client from scratch.)

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.

It’s not and no one cares about numbers anymore.

The only people who ever cared about svn's numbering scheme were those who abused it as a proxy to release/build versions, which was blaming the tools for the problems they created for themselves.

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.

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 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.

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

I tried to follow tutorials that use the command line. In hindsight that is terrible way to teach Git, which is fundamentally quite a visual thing.

It's like trying to teach people about filesystems only using cd, ls and pwd instead of just showing them a file tree.

Actually it's even worse because Git's CLI is so notoriously awful.

Eventually I tried Sourcetree which made it all make sense. Though Sourcetree isn't a very good GUI, mainly due to being hella slow. I eventually switched to GitX which is probably the best GUI I've used so far and makes everything extremely clear and easy. Unfortunately Mac only.

I now mostly use the Git Graph VSCode extension which is excellent and integrates pretty well with VSCode. Unfortunately it has been abandoned by its author and they frustratingly included a license clause saying only they could release versions of it, so it's basically abandonware. But it still works so I'll figure out a replacement when I have to.

Oh dang, I use that extension too and I didn't know it was abandoned. Let me know if you find a good replacement
If you use the git command line (and I do) you should spam git log --graph (usualy with --oneline).

And for your filesystem example I sure do hope you use tree!
- you should spam git log --graph
  
  Yeah... but that's just a poor man's GUI. Why use that when you can use a proper GUI? The only reason I can think of is if you happen to be in a situation where using a GUI is a bit of a pain (e.g. SSH).

Wft isn't there just a nice clean git UI that tells you in human terms what you are doing.

Command line interfaces suck ass.

Learn git with the command line with examples and visual aids.

https://learngitbranching.js.org/
- Thank you for sharing this.
  
  I found this long time ago then lost the link.
I think the lack of UI is the main reason for all the jokes about git being horrible to learn. Fork is a pretty good client, and there are also some pretty good VSCode plugins to show you how all the commits and branches fit together.
- think the lack of UI
  
  Even git ships with git-ui. It's not great, but just goes to show how well informed and valid your criticism is.
  
  https://git-scm.com/docs/git-gui/
Sublime Merge is the best. Not easy but I’ve tried them all.
- I've tried them all. Didn't get on with Sublime Merge.
  
  My recommendations:
  
  GitX (sadly Mac only, and a confusing array of forks).
  
  Git Extensions (which I avoided for ages because the terrible name makes it sound like it's just explorer shell extensions but it's actually a full GUI).
  
  Git Graph VSCode extension
  
  Most of the others are kind of crap IMO.
Git Fork is amazing
I mean gitlab is pretty sweet