>The reason people find git hard is that concepts of distributed version control are hard. Maybe. For me it was because the documentation is written like a co

>The reason people find git hard is that concepts of distributed version control are hard. Maybe. For me it was because the documentation is written like a comp sci whitepaper. I've ranted about this elsewhere on HN but the man pages are filled with stuff like "update remote refs" as if a person would have a fucking clue what a ref is and why you'd want to update a remote one. Branching, merging, tagging, all of that sounds great. I've been using git for years, but the problem is that I don't use it every day, and so I still get a little wary when I want to run a merge. I can't tell you right now off the top of my head how to merge if there is a conflict. I always have to google around for "how to undo a commit". Etc. etc. etc. Where the fuck do my files go when I switch to a different branch? Do they actually change in the working directory? Checkout vs fetch? Where exactly in the file system is this alleged "staging area"? I have no idea about any of these, mostly because the documentation is just so poorly written that it takes me too long to find out the answers and I have more important things to do than Greco-Roman wrestling matches with my software tooling, but I'm afraid that if I just try things at random I'll do something I can't undo because none of the options seem particularly intuitive. It's just not a very good piece of software.