There are a lot of comments here such as "Git has a horrible UI/UX", "I don't want to have to learn the inner workings of a tool", "Certain systems are designed

There are a lot of comments here such as "Git has a horrible UI/UX", "I don't want to have to learn the inner workings of a tool", "Certain systems are designed so well that they can be understood as black boxes", and a lot of other complaining about Git and it's idiosyncrasies. I think this needs to be dissected a bit. First, Git operates in a manner (internally) that is foreign to most users of other SCM systems. Second, Git has a bit of a "tacked-on" nature to it's CLI that can make use cumbersome for newcomers especially when they have been taught the shortcuts before the fundamentals. For the first problem, I think this is where the black-box comments apply. And honestly, I think treating SCMs as black boxes is what got us into the situation we were in before Git. Version control, branching, merging, change management, and change deconfliction are hard problems, IMO. Personally, I think the base level functions that Git provides, combined with Git workflows from Atlassian (and others) really helps provide a daily routine to handle these situations. After cloning: branch -> change -> index (or update) -> commit -> pull -> fix conflicts -> commit -> push -> merge (or pull request) -> repeat. There are some variations depending on your branching model, but by-in-large this is what prevents regressions and forces people doing the committing to resolve the changes and not to break master. I think you need to understand the "internals" of any SCM to really be able to conquer the challenges of distributed version control and the complexities of modern software development. I've worked in Rational ClearCase shops, and we needed a ClearCase guru on site too. Every team should have a Git guru. For the second problem, yes, the CLI is a bit clunky at times. This, combined with a misunderstanding of Git fundamentals can lead you down some bad paths. Cleaning up the CLI is an independent problem from Git internals - and I'll admit some taxonomy/hierarchy/ontology/whatever of commands is probably needed to refine the day to day workflows. However, if you mess up the repo because you don't understand the branching and merging model, you are going to have to use the more "specialized" commands which, let's face it are going to be a bit more cryptic. This is the same for any system that has some maintenance or repair type functionality. This is why I say, learning how Git works, allows you to learn the branching model better, which will hopefully allow you to avoid those particularly thorny paths. Sure, you can choose some other SCM system that seems less cryptic or easier to use, but you will likely find yourself in a bind someday in those systems that you will need it's cryptic commands to get out of. Or more likely, doing a lot of work that Git would have allowed you to do in a fraction of the time.